Add an init command to create agents-cli-manifest.yaml for existing ADK projects

[ftnext]

What is your feature suggestion?

I would like agents-cli to provide a lightweight initialization command that writes agents-cli-manifest.yaml into an existing ADK project, without scaffolding a new project or adding deployment files.

For example, the command could be:

agents-cli init

or:

agents-cli scaffold init

Ideally this would feel similar to hatch new --init: when run from an existing project root, it detects reasonable defaults and creates the minimal project metadata needed by agents-cli commands.

A possible generated manifest could be:

name: my-agent
agent_directory: app
region: us-east1
create_params:
  deployment_target: none

It would also be helpful to support flags such as:

agents-cli init --agent-directory app --name my-agent
agents-cli init --dry-run
agents-cli init --yes

The command should avoid overwriting an existing agents-cli-manifest.yaml unless an explicit --force flag is provided.

What will this enable you to do?

This would make it much easier to adopt agents-cli in existing ADK projects.

Right now, after adding eval files to an existing project by skill equiped coding agent, running:

agents-cli eval run --all

fails with:

Error: No agents-cli-manifest.yaml found in the current directory or its parents.
  Run this command from your project root, or create a project first:
    agents-cli create my-agent

For an existing ADK project, I do not necessarily want to create a new project or run a broader scaffold/enhance flow. I only need the minimal manifest so commands like agents-cli eval run, agents-cli info, and other project-aware commands can locate the project root and agent directory.

A lightweight init command would provide a clear migration path:

1. Start with an existing ADK project.
2. Add evalsets/config.
3. Run agents-cli init.
4. Run agents-cli eval run --all.

This would reduce friction for users who already have ADK agents and want to gradually adopt agents-cli workflows.

Additional context

The ideal UX is similar to hatch new --init, where an existing project can be initialized in place.
https://hatch.pypa.io/dev/cli/reference/#hatch-new

Nice-to-have detection behavior:

• infer name from pyproject.toml or the current directory name
• infer agent_directory from common ADK layouts such as app/, a package listed in pyproject.toml, or a directory containing agent.py / root_agent.yaml
• default deployment_target to none so local eval usage works without opting into deployment scaffolding
• print the generated manifest and explain what was detected
• provide flags for explicit values when auto-detection is wrong

This would complement agents-cli create for new projects and agents-cli scaffold enhance for adding broader scaffold/deployment support, while covering the smaller "initialize this existing ADK project for agents-cli" use case.

[sushicw]

Thank you for this!

Just adding some notes:

• We would first need to make sure we are very clear about what parts of agents-cli require our opinionated project structure, and which should work for any arbitrary ADK project. Otherwise, we risk having something that breaks in unexpected ways because agents-cli is assuming structure that doesn't match the existing ADK project.
• This could possibly also be done as part of enhance, perhaps with a flag like --from-adk-project if needed.
• I did try doing a basic adk create project followed by agents-cli scaffold enhance . from within the folder, and I agree that as-is it isn't the experience we'd hope for. (Among other things, you end up with a copy of agent.py added to a subfolder under the original agent folder root, in addition to the original).