[FEATURE] Non-interactive flags for `apm init` project metadata (name, description, version, author)

[sproott]

Is your feature request related to a problem? Please describe.

apm init's interactive mode collects four metadata fields — name, version,
description, author — but its non-interactive mode can freely set none of them,
so scripted / CI / --yes init is stuck with auto-detected boilerplate and must
hand-edit apm.yml afterward.

The command
(init)
declares only these value-bearing options: the project_name argument, --yes,
--plugin, --marketplace, --target, --verbose. There is no
--description, --version, or --author. The two paths diverge on what a user
can control:

• Interactive
  (_interactive_project_setup)
  prompts for name, version, description, and author. In the current
  directory (no positional arg) it seeds the name prompt with the directory
  basename but lets the user type any name — a custom-named project in-place.
• Non-interactive (--yes or non-TTY stdin) takes
  _get_default_config,
  which hardcodes version: "1.0.0", description: f"APM project for {name}",
  and author from git config user.name. No flag feeds config, so the field
  the interactive user is most likely to customize — the description — is the one
  a non-interactive user cannot set at all. For name, the positional arg is the
  only input, and _perform_init treats it as mkdir(project_name) + chdir
  into that subdir; a bare ./no-arg forces the current dir's basename. Neither
  path names a project in-place.

Current behavior — every metadata field is either rejected as an unknown option
or pinned to boilerplate:

$ apm init myproj --yes --description "My cool project"
Error: No such option: --description

$ apm init myproj --yes
$ cat myproj/apm.yml
name: myproj
version: 1.0.0
description: APM project for myproj      # boilerplate, unsettable
author: Jane Dev                         # git user.name, unsettable

Describe the solution you'd like

--description, --version, and --author flags on apm init, so every field
the interactive prompt collects can be set without the prompt:

apm init myproj --yes --description "My cool project" --version 0.1.0 --author "Jane Dev"

writes those exact values and exits 0. Also a way to name a project in the current
directory non-interactively (e.g. a --name flag decoupled from the positional
arg's mkdir behavior), matching what interactive init already allows in-place.

Describe alternatives you've considered

• Run apm init interactively, then re-run non-interactively — not viable in CI.
• Hand-edit or sed the generated apm.yml after apm init --yes — works but
  defeats the point of a scaffolding command and is brittle.

There is precedent in the CLI's own scaffolding surface: sibling
apm marketplace init
already takes --name and --owner, so "set metadata without the prompt" is an
established mode — just not on apm init.

Additional context

Observed on apm v0.24.0 (Linux, Python 3.14). The gap is visible from the
apm init flag surface alone (apm init --help lists no metadata flags) and the
two code paths cited above — no reproduction directory needed.

[github-actions]

Triage Panel Verdict

Thank you for this well-documented feature request, @sproott. The gap between what interactive apm init collects and what non-interactive apm init --yes allows is a real CI/scripting friction point.

DevX UX Expert: Non-interactive / CI use is a first-class scenario for any scaffolding command. The four metadata fields that the interactive prompt collects -- name, version, description, author -- should all be settable via flags without a prompt. The apm marketplace init --name --owner precedent confirms this is the established pattern in the CLI. A --name flag decoupled from the positional arg's mkdir behavior is the correct solution for in-place naming; the positional arg conflating "name the project" with "mkdir + chdir" is a footgun that should not be extended to --yes users.

OSS Growth Hacker: This is a friction point that will affect any team integrating APM into CI pipelines or project templates. A well-scoped, externally filed issue with code references and reproduction steps -- this is exactly the kind of contribution to encourage. Marking as help wanted is appropriate if the maintainer wants to route it back to the contributor or community.

APM CEO (arbiter): Accepted. The scope is clear and bounded: add --description, --version, --author, and --name flags to apm init; wire them into _get_default_config so --yes + flags produces a manifest without prompts. No design doc required. Targeted for v0.25.0 as a feature addition.

---

Triage decision: Accepted. Next action: implement --description, --version, --author, and --name flags on apm init; ensure flag values take precedence over _get_default_config defaults in non-interactive mode; update apm init --help output and docs.

Field	Value
Area	cli
Type	feature
Milestone	v0.25.0

Generated by Triage Panel · 112.4 AIC · ⌖ 8.08 AIC · ⊞ 9.2K · ◷

[github-actions]

Triage Panel Verdict

Thanks for the well-specified feature request, @sproott. Panel ran three mandatory reviewers (DevX UX Expert, Supply Chain Security Expert, APM CEO) plus Python Architect given the CLI surface change.

Panel consensus

DevX UX Expert: This is a real ergonomics gap. CI/CD users and script authors who call apm init --yes today are forced to post-edit apm.yml for every project -- defeating the purpose of a scaffolding command. Adding --description, --version, and --author is table-stakes parity with interactive mode. The --name decoupled from mkdir behavior is a secondary but legitimate ask; it should be scoped carefully to avoid breaking the positional-arg contract.

Python Architect: Implementation is straightforward: add Click options to init.py, thread them through _get_default_config (or a small override layer). No architectural change required. Recommend a single --name flag that only affects the manifest's name: field when no positional arg triggers mkdir; the positional-arg mkdir path stays unchanged to avoid breaking existing scripts.

APM CEO (arbiter): Scripted init is a common entry point for platform teams managing many agent projects. Blocking CI on interactive prompts is a friction point that reduces adoption. This is a well-understood, bounded feature with clear precedent. Targeting v0.25.0 to allow proper design review of the --name boundary.

Triage decision

Dimension	Value
Theme	(none -- CLI ergonomics)
Area	area/cli (added)
Type	type/feature (existing)
Status	status/triaged (added)
Priority	(not assigned -- normal backlog priority)
Milestone	v0.25.0

Suggested next action: Implement --description, --version, --author as Click options in init.py with a clear note in help text that --name only applies when no positional project_name argument is given. Add unit tests covering --yes + each flag, non-TTY stdin + each flag, and the in-place naming case.

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · 112.4 AIC · ⌖ 8.08 AIC · ⊞ 9.2K · ◷