- quick.md Step 5.6: commit PLAN.md to base branch before worktree executor spawn when USE_WORKTREES is active, preventing CC #36182 path-resolution drift that caused silent writes to main repo instead of worktree - reapply-patches.md Option A: replace first-add commit heuristic with pristine_hashes SHA-256 matching from backup-meta.json so baseline detection works correctly on multi-cycle repos; first-add fallback kept for older installers without pristine_hashes - CONFIGURATION.md: move security_enforcement/security_asvs_level/security_block_on to workflow.* (matches templates/config.json and workflow readers); rename context_profile → context (matches VALID_CONFIG_KEYS in config.cjs); add planning.sub_repos to schema example - universal-anti-patterns.md + context-budget.md: fix context_window_tokens → context_window (the actual key name in config.cjs) Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
5.9 KiB
5.9 KiB
Universal Anti-Patterns
Rules that apply to ALL workflows and agents. Individual workflows may have additional specific anti-patterns.
Context Budget Rules
- Never read agent definition files (
agents/*.md) --subagent_typeauto-loads them. Reading agent definitions into the orchestrator wastes context for content automatically injected into subagent sessions. - Never inline large files into subagent prompts -- tell agents to read files from disk instead. Agents have their own context windows.
- Read depth scales with context window -- check
context_windowin.planning/config.json. At < 500000: read only frontmatter, status fields, or summaries. At >= 500000 (1M model): full body reads permitted when content is needed for inline decisions. Seereferences/context-budget.mdfor the complete table. - Delegate heavy work to subagents -- the orchestrator routes, it does not build, analyze, research, investigate, or verify.
- Proactive pause warning: If you have already consumed significant context (large file reads, multiple subagent results), warn the user: "Context budget is getting heavy. Consider checkpointing progress."
File Reading Rules
- SUMMARY.md read depth scales with context window -- at context_window < 500000: read frontmatter only from prior phase SUMMARYs. At >= 500000: full body reads permitted for direct-dependency phases. Transitive dependencies (2+ phases back) remain frontmatter-only regardless.
- Never read full PLAN.md files from other phases -- only current phase plans.
- Never read
.planning/logs/files -- only the health workflow reads these. - Do not re-read full file contents when frontmatter is sufficient -- frontmatter contains status, key_files, commits, and provides fields. Exception: at >= 500000, re-reading full body is acceptable when semantic content is needed.
Subagent Rules
- NEVER use non-GSD agent types (
general-purpose,Explore,Plan,Bash,feature-dev, etc.) -- ALWAYS usesubagent_type: "gsd-{agent}"(e.g.,gsd-phase-researcher,gsd-executor,gsd-planner). GSD agents have project-aware prompts, audit logging, and workflow context. Generic agents bypass all of this. - Do not re-litigate decisions that are already locked in CONTEXT.md (or PROJECT.md ## Context section) -- respect locked decisions unconditionally.
Questioning Anti-Patterns
Reference: references/questioning.md for the full anti-pattern list.
- Do not walk through checklists -- checklist walking (asking items one by one from a list) is the #1 anti-pattern. Instead, use progressive depth: start broad, dig where interesting.
- Do not use corporate speak -- avoid jargon like "stakeholder alignment", "synergize", "deliverables". Use plain language.
- Do not apply premature constraints -- don't narrow the solution space before understanding the problem. Ask about the problem first, then constrain.
State Management Anti-Patterns
- No direct Write/Edit to STATE.md or ROADMAP.md for mutations. Always use
gsd-tools.cjsCLI commands (state update,state advance-plan,roadmap update-status) for mutations. Direct Write tool usage bypasses safe update logic and is unsafe in multi-session environments. Exception: first-time creation of STATE.md from template is allowed.
Behavioral Rules
- Do not create artifacts the user did not approve -- always confirm before writing new planning documents.
- Do not modify files outside the workflow's stated scope -- check the plan's files_modified list.
- Do not suggest multiple next actions without clear priority -- one primary suggestion, alternatives listed secondary.
- Do not use
git add .orgit add -A-- stage specific files only. - Do not include sensitive information (API keys, passwords, tokens) in planning documents or commits.
Error Recovery Rules
- Git lock detection: Before any git operation, if it fails with "Unable to create lock file", check for stale
.git/index.lockand advise the user to remove it (do not remove automatically). - Config fallback awareness: Config loading returns
nullsilently on invalid JSON. If your workflow depends on config values, check for null and warn the user: "config.json is invalid or missing -- running with defaults." - Partial state recovery: If STATE.md references a phase directory that doesn't exist, do not proceed silently. Warn the user and suggest diagnosing the mismatch.
GSD-Specific Rules
- Do not check for
mode === 'auto'ormode === 'autonomous'-- GSD usesyoloconfig flag. Checkyolo: truefor autonomous mode, absence orfalsefor interactive mode. - Always use
gsd-tools.cjs(notgsd-tools.jsor any other variant) -- GSD uses CommonJS for Node.js CLI compatibility. - Plan files MUST follow
{padded_phase}-{NN}-PLAN.mdpattern (e.g.,01-01-PLAN.md). Never usePLAN-01.md,plan-01.md, or any other variation -- gsd-tools detection depends on this exact pattern. - Do not start executing the next plan before writing the SUMMARY.md for the current plan -- downstream plans may reference it via
@includes.
iOS / Apple Platform Rules
- NEVER use
Package.swift+.executableTarget(or.target) as the primary build system for iOS apps. SPM executable targets produce macOS CLI binaries, not iOS.appbundles. They cannot be installed on iOS devices or submitted to the App Store. Use XcodeGen (project.yml+xcodegen generate) to create a proper.xcodeproj. Seereferences/ios-scaffold.mdfor the full pattern. - Verify SwiftUI API availability before use. Many SwiftUI APIs require a specific minimum iOS version (e.g.,
NavigationSplitViewis iOS 16+,List(selection:)with multi-select and@Observablerequire iOS 17). If a plan uses an API that exceeds the declaredIPHONEOS_DEPLOYMENT_TARGET, raise the deployment target or add#availableguards.