* fix(#1041): route all source agents through the canonical multi-runtime gsd-tools resolver Source agents/*.md (gsd-planner, gsd-executor, gsd-verifier, gsd-plan-checker, gsd-intel-updater, gsd-debugger, …) called bare "gsd-tools …" in shell blocks. On a shim-only install — where gsd-tools.cjs exists under the runtime home but gsd-tools is NOT on PATH — those calls fail with "command not found" and the agent silently skips init/state/validate/commit ceremony, deferring to the orchestrator or bypassing GSD bookkeeping entirely. were never migrated, so it persisted on Claude Code and every other runtime that consumes the source agents directly. Only gsd-phase-researcher.md carried a resolver — and a stale, claude-only truncated one. Fix (all runtimes): - Inject the canonical multi-runtime gsd_run preamble (byte-equal to _runtime-launcher.snippet.sh — claude/codex/cursor/gemini/copilot/windsurf/ augment/trae/qwen/cline/opencode/kilo/hermes/antigravity homes) at the top of the first gsd_run block of all 12 gsd-tools-calling agents, and rewrite every command-position bare gsd-tools to gsd_run. - Upgrade gsd-phase-researcher.md's stale resolver to the canonical one. - Extend scripts/sync-runtime-launcher.cjs to maintain agents/ in parity (the sync caught and corrected a mis-placed preamble during development). - Extend the bare-gsd-tools (#2851) and launcher-parity (#373) regression guards to agents/ so no runtime can silently regress. Closes #1041 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * chore(#1041): backfill changeset PR number to 1045 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
6.1 KiB
Planner Guidance: Philosophy, Task Calibration, and Output Formats
Solo Developer + Claude Workflow
Planning for ONE person (the user) and ONE implementer (Claude).
- No teams, stakeholders, ceremonies, coordination overhead
- User = visionary/product owner, Claude = builder
- Estimate effort in context window cost, not time
Plans Are Prompts
PLAN.md IS the prompt (not a document that becomes one). Contains:
- Objective (what and why)
- Context (@file references)
- Tasks (with verification criteria)
- Success criteria (measurable)
Quality Degradation Curve
| Context Usage | Quality | Claude's State |
|---|---|---|
| 0-30% | PEAK | Thorough, comprehensive |
| 30-50% | GOOD | Confident, solid work |
| 50-70% | DEGRADING | Efficiency mode begins |
| 70%+ | POOR | Rushed, minimal |
Rule: Plans should complete within ~50% context. More plans, smaller scope, consistent quality. Each plan: 2-3 tasks max.
Ship Fast
Plan -> Execute -> Ship -> Learn -> Repeat
Anti-enterprise patterns (delete if seen): team structures, RACI matrices, sprint ceremonies, time estimates in human units, complexity/difficulty as scope justification, documentation for documentation's sake.
Task Types
| Type | Use For | Autonomy |
|---|---|---|
auto |
Everything Claude can do independently | Fully autonomous |
checkpoint:human-verify |
Visual/functional verification | Pauses for user |
checkpoint:decision |
Implementation choices | Pauses for user |
checkpoint:human-action |
Truly unavoidable manual steps (rare) | Pauses for user |
Automation-first rule: If Claude CAN do it via CLI/API, Claude MUST do it. Checkpoints verify AFTER automation, not replace it.
Task Sizing
Each task targets 10–30% context consumption.
| Context Cost | Action |
|---|---|
| < 10% context | Too small — combine with a related task |
| 10-30% context | Right size — proceed |
| > 30% context | Too large — split into two tasks |
Context cost signals (use these, not time estimates):
- Files modified: 0-3 = ~10-15%, 4-6 = ~20-30%, 7+ = ~40%+ (split)
- New subsystem: ~25-35%
- Migration + data transform: ~30-40%
- Pure config/wiring: ~5-10%
Too large signals: Touches >3-5 files, multiple distinct chunks, action section >1 paragraph.
Combine signals: One task sets up for the next, separate tasks touch same file, neither meaningful alone.
Interface-First Task Ordering
When a plan creates new interfaces consumed by subsequent tasks:
- First task: Define contracts — Create type files, interfaces, exports
- Middle tasks: Implement — Build against the defined contracts
- Last task: Wire — Connect implementations to consumers
This prevents the "scavenger hunt" anti-pattern where executors explore the codebase to understand contracts. They receive the contracts in the plan itself.
Specificity
Test: Could a different Claude instance execute without asking clarifying questions? If not, add specificity. See @~/.claude/gsd-core/references/planner-antipatterns.md for vague-vs-specific comparison table.
User Setup Detection
For tasks involving external services, identify human-required configuration:
External service indicators: New SDK (stripe, @sendgrid/mail, twilio, openai), webhook handlers, OAuth integration, process.env.SERVICE_* patterns.
For each external service, determine:
- Env vars needed — What secrets from dashboards?
- Account setup — Does user need to create an account?
- Dashboard config — What must be configured in external UI?
Record in user_setup frontmatter. Only include what Claude literally cannot do. Do NOT surface in planning output — execute-plan handles presentation.
Building the Dependency Graph
For each task, record:
needs: What must exist before this runscreates: What this produceshas_checkpoint: Requires user interaction?
Example: A→C, B→D, C+D→E, E→F(checkpoint). Waves: {A,B} → {C,D} → {E} → {F}.
Prefer vertical slices (User feature: model+API+UI) over horizontal layers (all models → all APIs → all UIs). Vertical = parallel. Horizontal = sequential. Use horizontal only when shared foundation is required.
File Ownership for Parallel Execution
Exclusive file ownership prevents conflicts:
# Plan 01 frontmatter
files_modified: [src/models/user.ts, src/api/users.ts]
# Plan 02 frontmatter (no overlap = parallel)
files_modified: [src/models/product.ts, src/api/products.ts]
No overlap → can run parallel. File in multiple plans → later plan depends on earlier.
Granularity Calibration
The resolved granularity is provided in the planning context as **Granularity:** <value>. Read that value and apply the corresponding row below. When no explicit value is present, default to Standard.
| Granularity | Typical Plans/Phase | Tasks/Plan |
|---|---|---|
| Coarse | 1-3 | 2-3 |
| Standard | 3-5 | 2-3 |
| Fine | 5-10 | 2-3 |
Derive plans from actual work. Granularity determines compression tolerance, not a target.
Planning Complete Return Format
## PLANNING COMPLETE
**Phase:** {phase-name}
**Plans:** {N} plan(s) in {M} wave(s)
### Wave Structure
| Wave | Plans | Autonomous |
|------|-------|------------|
| 1 | {plan-01}, {plan-02} | yes, yes |
| 2 | {plan-03} | no (has checkpoint) |
### Plans Created
| Plan | Objective | Tasks | Files |
|------|-----------|-------|-------|
| {phase}-01 | [brief] | 2 | [files] |
| {phase}-02 | [brief] | 3 | [files] |
### Next Steps
Run `/clear` first for a fresh context window, then execute: `/gsd:execute-phase {phase}`
Gap Closure Plans Created Return Format
## GAP CLOSURE PLANS CREATED
**Phase:** {phase-name}
**Closing:** {N} gaps from {VERIFICATION|UAT}.md
### Plans
| Plan | Gaps Addressed | Files |
|------|----------------|-------|
| {phase}-04 | [gap truths] | [files] |
### Next Steps
Execute: `/gsd:execute-phase {phase} --gaps-only`
Checkpoint Reached / Revision Complete
Follow templates in checkpoints and revision_mode sections respectively.