con un clic
aigon-feature-eval
Evaluate feature <ID> - code review or comparison
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Menú
Evaluate feature <ID> - code review or comparison
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Revise the current feature worktree after code review — decide accept/revert/modify
Show Aigon commands
Close feature <ID> [agent] [--adopt] - merges branch, cleans up, optionally adopts from losers
Create feature <name> - creates spec in inbox
Fast-track feature <name> - create + setup + implement in one step
Prioritise feature <name> - assigns ID, moves to backlog
| name | aigon-feature-eval |
| description | Evaluate feature <ID> - code review or comparison |
Evaluate a feature implementation. Works in Drive mode (code review) and Fleet mode (comparison).
If no ID is provided or doesn't match an active feature, run aigon feature-list --active, filter to matches, and ask the user which.
aigon feature-eval $1
# optional: --allow-same-model-judge # suppress same-family bias warning
This records the evaluation lifecycle state, refreshes the generated view, creates ./docs/specs/features/evaluations/feature-$1-eval.md, detects mode (Drive or Fleet), warns on same-family evaluator/implementer, and commits owned artifacts. The spec body is printed inline — use that copy; do not re-run aigon feature-spec.
./docs/specs/features/logs/feature-$1-*-log.mdgit diff main...feature-$1-*For each agent worktree at ../feature-$1-<agent>-*:
git diff main...HEAD in each worktreeBias guard:
feature-evalwarns automatically on same-family eval. Pass--allow-same-model-judgeto suppress if intentional.
Update ./docs/specs/features/evaluations/feature-$1-eval.md.
Complete the checklist (Spec Compliance, Code Quality, Testing, Documentation, Security) and add Strengths, Areas for Improvement, and an Approval decision (Approved / Needs Changes).
Use this exact structure — scoring table, then summary table, then Strengths/Weaknesses, then Recommendation.
| Criteria | cx | gg |
|---|---|---|
| Code Quality | /10 | /10 |
| Spec Compliance | /10 | /10 |
| Performance | /10 | /10 |
| Maintainability | /10 | /10 |
| **Total** | **/40** | **/40** |
| Agent | Lines | Score |
|---|---|---|
| cx | | /40 |
| gg | | /40 |
Adjust agent columns to match the actual agents. Use standard GFM pipe tables (not Unicode box-drawing) and do NOT wrap them in code fences — the dashboard needs raw markdown to render as HTML tables.
After the tables, include per-agent Strengths & Weaknesses (#### headings) and a 1-2 sentence Recommendation.
Summarise your review, highlight concerns, state your recommendation, then ask: "Would you like to proceed with merging this implementation?" and WAIT.
Do NOT run feature-close automatically. Once the user approves, tell them to run aigon-feature-close $1.
Summarise the comparison, show scores, state your recommendation, and update **Winner:** in the eval file with the winning agent code (e.g., **Winner:** cc (Claude) — rationale).
Explicitly address cross-pollination — you MUST state one of:
<agent>: <specific aspect>" (be concrete), orThen ask: "Which implementation would you like to merge?" and WAIT. Do NOT run feature-close automatically. Once chosen, tell them to run (from the main repo, not a worktree): aigon-feature-close $1 <winning-agent>.
End your response with the next command on its own line:
aigon-feature-close <ID>aigon-feature-close <ID> <winning-agent>