Work goals to completion
Process implementation goals in order from a GOALMAP, stopping to ask before high-risk steps, and record evidence recipes confirming each Done Means item.
/goal Read context/goals/GOALMAP.md, its product loop, global constraints, and global invariants. Work the goals one at a time in status order. For each goal, read the brief. If Interpretation Risk is High or any Stop / Ask Condition is met, stop and ask before proceeding; do not guess to maintain momentum. Otherwise do the work needed to satisfy Done Means while preserving Constraints and Invariants. Record Evidence as a reproducible recipe: exact command/workflow/artifact/source review plus expected result a reviewer can re-run or inspect. The Evidence Recipe must confirm each Done Means item, including the highest-risk one, not an easier adjacent claim. Update Status and Completion Notes as bookkeeping only. When all implementation goals are done, run the final validation goal and present its evidence recipe/results plus the status table for acceptance; do not self-close the map
claude-code
More planning loops
Ship GOALS.md phases 1-13
Implement each GOALS.md phase with tests and validation, committing and pushing after stable milestones until unblocked.
/goal Complete GOALS.md phases 1-13 in order. For each phase, implement the deliverables, add/update tests, run the common validation plus that phase's Automated QA, commit after the phase passes, and push after stable milestones. Preserve unrelated user changes. Stop only if blocked by missing credentials, external service access, or an explicit product decision that cannot be safely inferred
planninghigh risk
Looper — design-review your loop before running it
A plan-the-loop-first skill: it interviews you about the automation idea, previews the flow as ASCII art, and only writes final loop artifacts after you confirm — a safe on-ramp for loop beginners.
Skill interviews you about the automation idea, writes loop artifacts to `looper-output/`, shows an ASCII flow preview, and only finalizes after you confirm — design the loop before any runner touches files.
planningmedium risk
Draft a sprint plan from the backlog
Turn the open issue backlog into a proposed two-week sprint plan with estimates, a dependency ordering, and an explicit cut line, written as a document for the team to edit.
/goal SPRINT-PLAN.md contains a proposed 2-week plan — read all open issues labeled `ready`, estimate each as S/M/L based on the code it touches, order them by dependency and value, draw a cut line at a realistic capacity, and list what falls below it with reasons; make no changes to the issues themselves; stop after 6 turns
planninglow risk
⧉ 1