set-core: Command for Claude Code

Review a spec document against the orchestration planning guide and checklist.

Input: The argument after /set:plan-review is the path to the spec file to review. If no path is given, ask the user which file to review.

Steps

1. Read the planning guide and checklist

   • Read docs/planning-guide.md from the set-core project (find it via which set-orchestrate → resolve to set-core root, or check common locations: ~/code2/set-core/docs/, ~/code/set-core/docs/)
   • Read docs/plan-checklist.md from the same location
   • If not found locally, check if the current project has copies in its own docs/ directory

2. Read the spec document

   • Read the file path provided by the user
   • If no path given, use AskUserQuestion to ask

3. Review against the checklist

   Go through each checklist category and evaluate the spec:

   Scope & Overlap

   • Are scopes self-contained? Any shared files between parallel items?
   • Are scopes specific enough (not vague)?
   • Any L-sized items that should be split?

   Dependencies

   • Are schema migrations sequential?
   • Is auth foundational?
   • Are shared type changes identified?
   • Any missing implicit dependencies (barrel exports, config files)?

   Manual/Human Tasks

   • Do any items involve external services (Stripe, Firebase, AWS, OAuth providers)?
   • Do any items require API keys, tokens, or secrets that must be provided by a human?
   • Do any items need external account creation, webhook setup, or DNS configuration?
   • If yes: flag a warning if the spec doesn't mention manual steps, and suggest adding [?] tasks with [input:KEY] or [confirm] annotations in the tasks.md

   Dependency Graph Analysis Classify each spec item by change type and detect ordering issues:

   Change types (in natural execution order):

   • infrastructure — test/build setup, CI config
   • schema — DB migrations, model changes
   • foundational — auth, shared types, base components
   • feature — new functionality
   • cleanup-before — refactor/rename/reorganize that should precede features in same area
   • cleanup-after — dead code removal, cosmetic fixes after features

   Check for these ordering issues:

   • Cleanup/refactor items alongside feature items that touch the same area → cleanup should run first
   • Schema/migration items alongside data-layer or API items → schema should run first
   • Auth/role/permission items alongside features that need auth → auth should run first
   • Multiple items extending the same type/enum/interface → extract shared change or chain them
   • Items with no declared dependencies that clearly depend on each other semantically

   Testing

   • Does each item mention what to test?
   • Is test infrastructure addressed?
   • Are existing test patterns referenced?

   Sizing & Phases

   • Is the batch size reasonable (4-6 per phase)?
   • Are phases marked if >6 items?
   • Are phases independently valuable?

   Directives

   • Are orchestrator directives present?
   • Is test_command set?
   • Is merge_policy appropriate?

   Design Rules (Layer Check)

   • Layer 1 (Business Intent): Is the "what" clear for each item?
   • Layer 2 (Constraints): Are boundaries, validation rules, access control specified?
   • Layer 3 (Solution Shape): Are selective choices (libraries, UI patterns) reasonable?
   • Layer 4 (Implementation): Is anything over-specified that should be left to the agent?

   Spec-Writing Checklist per Feature For each feature, check:

   • What data does it read/write?
   • Who can access it?
   • What happens on error?
   • Happy path AND edge cases covered?
   • Does it interact with existing features?
   • What's the UI entry point?

4. Output the review

   Format:

   ## Plan Review: <filename>
   
   ### Summary
   <1-2 sentence overall assessment>
   
   ### Checklist Results
   
   #### Scope & Overlap
   - [x] or [ ] for each item, with notes
   
   #### Dependencies
   ...
   
   #### Testing
   ...
   
   #### Sizing & Phases
   ...
   
   #### Directives
   ...
   
   ### Per-Feature Review
   
   **<Feature 1>**
   - Layers: ✅ Intent, ✅ Constraints, ⚠️ Missing error handling, ✅ Not over-specified
   - Data: specified / missing
   - Access: specified / missing
   - Tests: specified / missing
   - Suggestion: <specific improvement>
   
   **<Feature 2>**
   ...
   
   ### Dependency Graph
   
   **Change Types:**
   | Item | Type | Notes |
   |------|------|-------|
   | <item 1> | feature | — |
   | <item 2> | cleanup-before | touches same UI area as item 1 |
   
   **Suggested Dependencies:**
   - `<Feature X>`: add `depends_on: <cleanup-change>` (cleanup should precede feature work on shared components)
   - `<Data layer Y>`: add `depends_on: <schema-change>` (schema migration must complete first)
   
   Or if no issues: "Dependency ordering looks good — items are independent (touch different modules/areas)."
   
   ### Suggested Improvements
   1. <Concrete, actionable suggestion>
   2. <Concrete, actionable suggestion>
   ...