c8f370583a
Architect agents (discuss, plan, detail, refine) were producing generic analysis disconnected from the actual codebase. They had full tool access in their worktrees but were never instructed to explore the code. - Add CODEBASE_EXPLORATION shared constant: read project docs, explore structure, check existing patterns, use subagents for parallel exploration - Inject into all 4 architect prompts after INPUT_FILES - Strengthen discuss prompt: analysis method references codebase, examples cite specific paths, definition_of_done requires codebase references - Fix spawnArchitectDiscuss to pass full context (pages/phases/tasks) via gatherInitiativeContext() — was only passing bare initiative metadata - Update docs/agent.md with new tag ordering and shared block table
144 lines
6.6 KiB
TypeScript
144 lines
6.6 KiB
TypeScript
/**
|
|
* Shared prompt instructions reused across agent types.
|
|
* Each constant is wrapped in a descriptive XML tag for unambiguous
|
|
* first-order / second-order delimiter separation per Anthropic best practices.
|
|
*/
|
|
|
|
export const SIGNAL_FORMAT = `
|
|
<signal_format>
|
|
As your final action, write \`.cw/output/signal.json\`:
|
|
- Done: \`{ "status": "done" }\`
|
|
- Need clarification: \`{ "status": "questions", "questions": [{ "id": "q1", "question": "..." }] }\`
|
|
- Unrecoverable error: \`{ "status": "error", "error": "..." }\`
|
|
</signal_format>`;
|
|
|
|
export const INPUT_FILES = `
|
|
<input_files>
|
|
Read \`.cw/input/manifest.json\` first, then read listed files from \`.cw/input/\`.
|
|
|
|
**Assignment Files**
|
|
- \`initiative.md\` — frontmatter: id, name, status
|
|
- \`phase.md\` — frontmatter: id, name, status; body: description
|
|
- \`task.md\` — frontmatter: id, name, category, type, priority, status; body: description
|
|
- \`pages/\` — one per page; frontmatter: title, parentPageId, sortOrder; body: markdown
|
|
|
|
**Context Files (read-only)**
|
|
Present when \`contextFiles\` exists in manifest:
|
|
- \`context/phases/\` — frontmatter: id, name, status, dependsOn; body: description
|
|
- \`context/tasks/\` — frontmatter: id, name, phaseId, parentTaskId, category, type, priority, status; body: description
|
|
|
|
Do not duplicate or contradict context file content in your output.
|
|
</input_files>`;
|
|
|
|
export const ID_GENERATION = `
|
|
<id_generation>
|
|
When creating new entities (phases, tasks, decisions), generate a unique ID by running:
|
|
\`\`\`
|
|
cw id
|
|
\`\`\`
|
|
Use the output as the filename (e.g., \`{id}.md\`).
|
|
</id_generation>`;
|
|
|
|
export const DEVIATION_RULES = `
|
|
<deviation_rules>
|
|
1. **Typo in assigned files** → Fix silently
|
|
2. **Bug in files you're modifying** → Fix if < 10 lines, otherwise note and move on
|
|
3. **Missing dependency** → Check context files for another agent's work; \`cw ask\` if yes, create if within scope
|
|
4. **Architectural mismatch** → STOP. Signal "questions" with what you found vs. what the task assumes
|
|
5. **Ambiguous requirement** → STOP. Signal "questions" with the ambiguity and 2-3 concrete options
|
|
6. **Task wrong or impossible** → STOP. Signal "error" explaining why
|
|
|
|
Never silently reinterpret a task.
|
|
</deviation_rules>`;
|
|
|
|
export const GIT_WORKFLOW = `
|
|
<git_workflow>
|
|
You are in an isolated git worktree. Other agents work in parallel on separate branches.
|
|
|
|
- Stage specific files with \`git add <file>\`, not \`git add .\`
|
|
- Never force-push
|
|
- Run \`git status\` before committing
|
|
</git_workflow>`;
|
|
|
|
export const CODEBASE_EXPLORATION = `
|
|
<codebase_exploration>
|
|
Before beginning your analysis, explore the actual codebase to ground every decision in reality.
|
|
|
|
**Step 1 — Read project docs**
|
|
Check for CLAUDE.md, README.md, and docs/ at the repo root. These contain architecture decisions, conventions, and patterns you MUST follow. If they exist, read them first — they override any assumptions.
|
|
|
|
**Step 2 — Understand project structure**
|
|
Explore the project layout: key directories, entry points, config files (package.json, tsconfig, pyproject.toml, go.mod, etc.). Understand the tech stack, frameworks, and build system before proposing anything.
|
|
|
|
**Step 3 — Check existing patterns**
|
|
Before proposing any approach, search for how similar things are already done in the codebase. If the project has an established pattern for routing, state management, database access, testing, etc. — your decisions must build on those patterns, not invent new ones.
|
|
|
|
**Step 4 — Use subagents for parallel exploration**
|
|
Spawn subagents to explore different aspects of the codebase simultaneously rather than reading files one at a time. For example: one subagent for project structure and tech stack, another for existing patterns related to the initiative, another for test conventions. Parallelize aggressively.
|
|
|
|
**Grounding rule**: Every decision, question, and plan MUST reference specific files, patterns, or conventions found in the codebase. If your output could apply to any generic project without modification, you have failed — start over with deeper exploration.
|
|
</codebase_exploration>`;
|
|
|
|
export const CONTEXT_MANAGEMENT = `
|
|
<context_management>
|
|
When reading multiple files or running independent commands, execute them in parallel rather than sequentially. After each commit, update your progress file (see Progress Tracking).
|
|
</context_management>`;
|
|
|
|
export const TEST_INTEGRITY = `
|
|
<test_integrity>
|
|
1. **Never mirror implementation logic in assertions.** Hardcode expected values from requirements, don't recalculate them.
|
|
2. **Never modify existing test assertions to make them pass.** If a test expects X and your code produces Y, fix your code. Exception: your task explicitly changes expected behavior.
|
|
3. **Never skip or disable tests.** No \`it.skip()\`, \`.todo()\`, or commenting out. If unfixable, signal error.
|
|
4. **Each test must be independent.** No shared mutable state, no order dependence.
|
|
5. **Run the full relevant test suite**, not just your new tests.
|
|
</test_integrity>`;
|
|
|
|
export const SESSION_STARTUP = `
|
|
<session_startup>
|
|
1. \`pwd\` — confirm working directory
|
|
2. \`git status\` — check for unexpected state
|
|
3. Run test suite — establish green baseline. If already failing, signal "error". Don't build on a broken foundation.
|
|
4. Read \`.cw/input/manifest.json\` and all listed input files
|
|
</session_startup>`;
|
|
|
|
export const PROGRESS_TRACKING = `
|
|
<progress_tracking>
|
|
Update \`.cw/output/progress.md\` after each commit:
|
|
|
|
\`\`\`markdown
|
|
## Current Status
|
|
[What you just completed]
|
|
|
|
## Next Steps
|
|
[What you're working on next]
|
|
|
|
## Blockers
|
|
[Any issues or questions — empty if none]
|
|
\`\`\`
|
|
|
|
Survives context compaction — read this first if your context is refreshed.
|
|
</progress_tracking>`;
|
|
|
|
export function buildInterAgentCommunication(agentId: string): string {
|
|
return `
|
|
<inter_agent_communication>
|
|
Your agent ID: **${agentId}**
|
|
|
|
**CLI Commands**
|
|
|
|
- \`cw listen --agent-id ${agentId}\` — Waits for incoming question. Prints JSON (\`{ conversationId, fromAgentId, question, phaseId, taskId }\`) and exits.
|
|
- \`cw ask "<question>" --from ${agentId} --agent-id <TARGET>\` — Blocks until answered. Target with one of: \`--agent-id <id>\`, \`--task-id <id>\`, \`--phase-id <id>\`.
|
|
- \`cw answer "<answer>" --conversation-id <ID>\` — Answer a pending question.
|
|
|
|
**Usage Pattern**
|
|
|
|
Run \`cw listen > "$file" &\` at session start. Check periodically. On question: answer, restart listener. Before signal.json: kill listener, clean up.
|
|
|
|
**When to Communicate**
|
|
- Need interface/schema/API contract info from another agent
|
|
- About to modify a shared resource
|
|
- Have a dependency on another agent's work
|
|
- Don't ask questions you can answer by reading the codebase
|
|
</inter_agent_communication>`;
|
|
}
|