afc

aigon-feature-create

Run this command followed by the feature name.

aigon feature-create {{args}}

This creates a new feature spec in ./docs/specs/features/01-inbox/.

IMPORTANT: Do not launch or foreground an editor, terminal, or Markdown preview after creation. Continue by reading and editing the spec through the current agent session; use the exact path printed by the CLI.

Step 1: Read Project Conventions

Tip: If you are running this command in your own Claude Code session (no --agent flag), press Shift+Tab now to enter plan mode before drafting — this keeps your session read-only while you explore the codebase and propose the spec.

Explore the codebase to understand the existing architecture, patterns, and code relevant to this feature. Use that investigation both to plan the approach and to resolve technical facts without asking the user. Consider:

• What existing code will this feature interact with?
• Are there patterns or conventions in the codebase to follow?
• What technical constraints or dependencies exist?

Use this understanding to write a well-informed spec — especially the Technical Approach, Dependencies, and Acceptance Criteria sections.

Step 2: Deepen — interview the user before writing

Follow this procedure literally. Deepen applies to this installed agent command; the bare aigon feature-create CLI remains a noninteractive scaffolder.

1. Apply the gate. Inspect the raw invocation arguments in the command above. If they contain --quick, skip the rest of Deepen and continue to Step 3. Otherwise run:

   aigon config get deepen.enabled
   

   Skip the rest of Deepen only when the effective value is false. Remember whether a value of true was reported as (from default) or came from explicit project/global configuration; this controls the final hint below.

2. Build a coverage map before asking anything. Read the user's request, the bare-bones spec just created, any available planning context, and the relevant code. If the in-flight spec has planning_context:, read that plan and use it as the source of recommended answers. Do not re-interview the user about decisions already resolved there. Investigate discoverable technical facts — including existing patterns, dependencies, constraints, and file paths — instead of asking the user for them.

3. Check coverage internally in dependency order: Summary → User Stories → Acceptance Criteria → Technical Approach → Dependencies → Out of Scope → complexity:. This is a decision dependency order, not a requirement to ask one question for every section. Ask only when the answer could materially change scope, acceptance criteria, or approach.

4. Ask the highest-leverage unresolved question, one question per message. Every question must challenge a consequential assumption or surface a meaningful alternative; do not ask a template-completion question. Attach a proposed answer on its own clearly labelled line: