بنقرة واحدة
aigon-feature-create
Create feature <name> - creates spec in inbox
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Create feature <name> - creates spec in inbox
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Record or show a feature author handoff
Revise feature spec after pending spec reviews — decide and acknowledge in one pass
Record or show a research author handoff
Create research <name> - creates topic in inbox
Revise research spec after pending spec reviews — decide and acknowledge in one pass
Do feature <ID> - works in both Drive and Fleet modes
| name | aigon-feature-create |
| description | Create feature <name> - creates spec in inbox |
Run this command followed by the feature name.
aigon feature-create $ARGUMENTS
This creates a new feature spec in ./docs/specs/features/01-inbox/.
IMPORTANT: After the CLI command completes, open the created feature file in markdown preview mode in a separate window:
./docs/specs/features/01-inbox/feature-$ARGUMENTS.md (or similar, check the CLI output for exact filename)Cmd+Shift+P / Ctrl+Shift+P) and run: Markdown: Open Preview (or press Cmd+Shift+V / Ctrl+Shift+V)Tip: If you are running this command in your own Claude Code session (no
--agentflag), 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. Plan your approach before writing. Consider:
Use this understanding to write a well-informed spec — especially the Technical Approach, Dependencies, and Acceptance Criteria sections.
set: frontmatter)Default: standalone. Most new specs should not have a set: tag.
Use set: <slug> only when you are creating two or more inbox specs that ship together and will be prioritised with aigon set-prioritise <slug>.
Before reusing any set slug, run aigon set show <slug>. If every member is done, the set is closed — do not tag into it. For follow-up work, use depends_on: [<id>] and mention prior features under ## Related instead.
See .aigon/docs/feature-sets.md § Completed sets — do not rejoin.
complexity: (required) — drives the per-agent {model, effort} defaults in the dashboard start modal, resolved from each agent's complexity-defaults table and then aigon config. Do not put model names or effort levels in the spec; those SKUs change over time and belong only in agent config.
Use this rubric:
planning_context: (set this when you ran plan mode) — if you entered plan mode (EnterPlanMode / Shift+Tab) before writing this spec and a plan file was written to ~/.claude/plans/, set this field to that path:
planning_context: ~/.claude/plans/your-plan-file.md
The implementing agent will read the plan before writing any code, and the content is copied into the implementation log at start time so it’s durable even if the plan file is later deleted. Skipping this means the agent has to re-derive all the context from the spec alone.
Promote every durable product decision into the spec, then record a compact
author handoff. Derive the active author identity through agent-context; do
not copy provider session IDs or transcripts manually:
eval "$(aigon agent-context --shell)"
aigon feature-context record <ID> --file=<handoff.json>
The handoff JSON contains decisions, constraints, nonGoals,
unresolvedQuestions, implementationNotes, and specReferences arrays.
Commit the spec file:
git add docs/specs/features/01-inbox/ .aigon/context/features/
git commit -m "feat: create feature spec - <name>"
Next step: Once the spec is committed, suggest aigon-feature-prioritise $ARGUMENTS to assign an ID and prioritise it to backlog.
End your response with the suggested next command on its own line. This helps agent UIs surface the next suggested Aigon command. Use the actual feature name:
aigon-feature-prioritise <name>