Files
msd-core/gsd-core/references/planner-guidance.md
Tom Boucher 1fab2e10ba fix(#1041): route all source agents through the canonical multi-runtime gsd-tools resolver (#1045)
* 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>
2026-06-11 11:42:59 -04:00

6.1 KiB
Raw Blame History

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:

  1. First task: Define contracts — Create type files, interfaces, exports
  2. Middle tasks: Implement — Build against the defined contracts
  3. 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:

  1. Env vars needed — What secrets from dashboards?
  2. Account setup — Does user need to create an account?
  3. 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 runs
  • creates: What this produces
  • has_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.