| name | foxctl-epic-grader |
| description | Grade a foxctl room-agile epic as a planning artifact: score readiness, surface blockers, and prescribe upgrade actions. |
foxctl-epic-grader
Use this skill when the goal is to evaluate a foxctl epic as a planning artifact.
This skill is for epic creation grading, not epic implementation grading.
Read references/grading-rubric.md before scoring.
Core rule
Do not reward implementation progress when grading epic creation quality.
An epic with real code changes can still score poorly if:
- stories are too coarse
- validator lanes are missing
- milestone criteria are weak
- intake traceability is lost
- evidence expectations are unclear
- the execution boundary is fuzzy
Likewise, an unimplemented epic can still score very well if the planning surface
is structurally ready for execution.
Inputs to review
Use these surfaces together:
foxctl room epic show <room-id> <epic-id>foxctl room show <room-id>- milestone views when needed
- story views when needed
- intake-source artifacts when grading imported or authored epics
For Factory-origin epics, compare against:
mission.mdfeatures.jsonvalidation-contract.mdvalidation-state.jsonprogress_log.jsonlhandoffs/worker-transcripts.jsonl
For authored epics, compare against the intake source when available:
- epic intake questions and answers
- drafting brief or spec
- shaping notes or guidance updates
What to score
Score the epic against the rubric categories in the reference file.
The total must be exactly 100.
Do not hand-wave the score. Every deduction should correspond to a concrete
planning weakness visible in the epic.
Decision boundary
After scoring, emit one of:
READY means the epic is suitable to serve as the implementation plan.
NOT READY means planning work is still required before implementation should begin.
Report format
Always output a compact report with these sections, in this order:
# Epic Grade: <epic title>
- Decision: READY|NOT READY
- Total: <n>/100
## Category Scores
- Brief & Boundaries: <n>/<max>
- Milestone Architecture: <n>/<max>
- Story Shape: <n>/<max>
- Validation & Evidence: <n>/<max>
- Intake Traceability: <n>/<max>
- Implementation-Plan Readiness: <n>/<max>
## Blockers
- <only planning blockers that keep the epic out of READY>
Scoring behavior
- Be strict.
- Prefer concrete deductions over vague praise.
- Cap praise.
- If a category is weak, say exactly what would raise it.
- Do not list implementation tasks as upgrade actions unless they are really plan-shaping tasks.
Upgrade actions should be framed as epic-creation improvements, for example:
- split one oversized imported story into three executable stories
- add
review and user_test lanes to milestone contract
- attach handoff artifacts to validator stories
- add milestone criteria for exit conditions
- reconcile imported state that overstates source progress
Avoid actions like:
- implement feature X
- write code for Y
- run the app and test manually
Those belong to implementation, not grading.
When imported from Factory
If the epic was imported from Factory, explicitly grade:
- how much source structure survived
- whether validator phases were preserved or reconstructed
- whether evidence artifacts are represented
- whether foxctl improved the mission enough to function as the implementation plan
An imported epic can score highly only if foxctl has already closed the planning gaps that Factory left open.
If the epic was authored directly in foxctl, explicitly grade:
- whether milestones and stories trace back to the intake brief
- whether assumptions were made explicit instead of buried in prose
- whether open intake questions were closed or preserved visibly
- whether the epic reads like a canonical implementation plan rather than a rough brainstorm
