Sheldon Finlay
b3d263258a
- Fix evaluator bypass on last story (moved completion check) - Fix all stale command name references across README, loop.sh, skills, plugin.json - Fix explore evaluator false rejects (.loop/ files are expected) - Fix stderr capture order in headless mode - Fix shell injection risk in hooks.sh python fallback - Remove .DS_Store from tracking - Rewrite README to match current architecture (single entry point, tmux, optional tools) - Add XcodeBuildMCP and iOS simulator MCP to optional tools docs
1.7 KiB
1.7 KiB
Planner Context
This file provides additional context for PRD generation.
Story Decomposition Guidelines
When breaking a feature into stories, think about:
Independence
Each story should be independently deployable. After completing story N, the codebase should be in a valid, working state — even if the feature isn't fully built yet.
Context Window Fit
A story must fit in a single AI context window (~100K tokens). This means:
- Reading relevant existing code
- Understanding the task
- Implementing the change
- Writing tests
- Running quality checks
- Committing
Budget roughly:
- 30% of context for reading/understanding
- 40% for implementation
- 20% for testing and quality
- 10% for bookkeeping (prd.json, progress.md)
Failure Isolation
If a story fails (evaluator rejects it), the next iteration should be able to retry it cleanly. Stories with too many moving parts are hard to retry because partial state is messy.
Evaluability
Every story must have criteria the evaluator can independently verify. "The code is clean" is not evaluable. "The function returns 404 when the user doesn't exist" is evaluable.
PRD Anti-Patterns
Avoid these common mistakes:
- Stories too large: "Build the API" — split into individual endpoints
- Stories too small: "Create the file" — combine with meaningful work in that file
- Vague criteria: "Works correctly" — what does correctly mean? Be specific.
- Missing dependencies: Story 5 needs Story 3's database table but doesn't say so
- Testing as afterthought: Tests should be part of each story, not a separate "add tests" story at the end
- UI without backend: A UI story that calls an API that doesn't exist yet