refactor: Compress shared agent prompts for conciseness (1060→699 words, -34%)

Apply aggressive compression: imperative style, remove anti-laziness
emphasis, cut rationale where obvious, eliminate redundant explanations.
All constant names and function signatures preserved.
This commit is contained in:
Lukas May
2026-02-18 17:30:04 +09:00
parent 67f98f4f35
commit e73e99cb28

View File

@@ -5,35 +5,28 @@
export const SIGNAL_FORMAT = `
## Signal Output
When done, write \`.cw/output/signal.json\` with:
{ "status": "done" }
If you need clarification, write:
{ "status": "questions", "questions": [{ "id": "q1", "question": "Your question" }] }
If you hit an unrecoverable error, write:
{ "status": "error", "error": "Description of what went wrong" }
IMPORTANT: Always write this file as your final action before terminating.`;
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": "..." }\``;
export const INPUT_FILES = `
## Input Files
Read \`.cw/input/manifest.json\` first — it lists exactly which input files exist.
Then read the files from \`.cw/input/\`.
Read \`.cw/input/manifest.json\` first, then read listed files from \`.cw/input/\`.
### Assignment Files (your work target)
- \`initiative.md\`Initiative details (frontmatter: id, name, status)
- \`phase.md\`Phase details (frontmatter: id, name, status; body: description)
- \`task.md\`Task details (frontmatter: id, name, category, type, priority, status; body: description)
- \`pages/\`Initiative pages (one file per page; frontmatter: title, parentPageId, sortOrder; body: markdown content)
### 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 background)
If \`contextFiles\` is present in the manifest, these provide read-only context about what already exists:
- \`context/phases/\`Existing phases (frontmatter: id, name, status, dependsOn; body: description)
- \`context/tasks/\`Existing tasks (frontmatter: id, name, phaseId, parentTaskId, category, type, priority, status; body: description)
### 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
Context files are for reference only — do not duplicate or contradict their content in your output.`;
Do not duplicate or contradict context file content in your output.`;
export const ID_GENERATION = `
## ID Generation
@@ -47,25 +40,23 @@ Use the output as the filename (e.g., \`{id}.md\`).`;
export const DEVIATION_RULES = `
## Deviation Decision Tree
When you encounter something unexpected, follow this order:
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
1. **Typo in your assigned files** → Fix silently, no need to ask
2. **Bug in files you're modifying** → Fix if < 10 lines changed, otherwise note it and move on
3. **Missing dependency you need** → Check if another agent is creating it (read context files). If yes, ask via cw ask. If no, create it yourself only if it's within your task scope
4. **Architectural mismatch** → STOP. Signal with status "questions" explaining what you found vs. what the task assumes
5. **Ambiguous requirement** → STOP. Signal with status "questions" listing the specific ambiguity and 2-3 concrete options
6. **Task seems wrong or impossible** → STOP. Signal with status "error" explaining why
Never silently reinterpret a task. If the task says "add a REST endpoint" don't build a GraphQL mutation instead.`;
Never silently reinterpret a task.`;
export const GIT_WORKFLOW = `
## Git Workflow
You are working in an isolated git worktree. Other agents may be working in parallel on separate branches.
You are in an isolated git worktree. Other agents work in parallel on separate branches.
- **Stage specific files**: Use \`git add <file>\` not \`git add .\` — shared worktrees mean \`git add .\` can include files owned by other agents.
- **Never force-push**: Other agents may have already inspected or built on top of your branch.
- **Check status first**: Run \`git status\` before committing to see what you're about to include.`;
- Stage specific files with \`git add <file>\`, not \`git add .\`
- Never force-push
- Run \`git status\` before committing`;
export const CONTEXT_MANAGEMENT = `
## Context Management
@@ -75,28 +66,24 @@ When reading multiple files or running independent commands, execute them in par
export const TEST_INTEGRITY = `
## Test Integrity Rules
These rules are non-negotiable. Violating them produces code that appears to work but silently ships bugs.
1. **Never duplicate implementation logic in test assertions.** If your code uses \`items.reduce((sum, i) => sum + i.price, 0)\`, your test MUST NOT use the same reduce — hardcode the expected value from the requirement instead. Tests that mirror implementation logic prove nothing.
2. **Never modify existing test assertions to make them pass.** If a pre-existing test expects X and your code produces Y, the bug is in your code — fix the code. The ONLY exception is when your task explicitly changes the expected behavior.
3. **Never skip or disable tests.** No \`it.skip()\`, no \`.todo()\` on existing tests, no commenting out test blocks. If a test is failing and you can't fix it, signal an error.
4. **Each test must be independent.** No shared mutable state between test cases. No tests that depend on execution order. Every \`it()\` block must pass when run in isolation.
5. **Run the full relevant test suite, not just your new tests.** Your changes may break something elsewhere. Catch regressions before committing.`;
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.`;
export const SESSION_STARTUP = `
## Session Startup
Before doing any work, verify your environment:
1. Run \`pwd\` to confirm you're in the expected working directory
2. Run \`git status\` to check for unexpected state (uncommitted changes, wrong branch)
3. Run the project's test suite to establish a green baseline — if tests are already failing, signal with status "error" describing what's broken. Do not build on a broken foundation.
4. Read \`.cw/input/manifest.json\` and all listed input files to understand your assignment`;
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`;
export const PROGRESS_TRACKING = `
## Progress Tracking
Maintain \`.cw/output/progress.md\` as a running log of your work. Update it after each commit:
Update \`.cw/output/progress.md\` after each commit:
\`\`\`markdown
## Current Status
@@ -109,27 +96,27 @@ Maintain \`.cw/output/progress.md\` as a running log of your work. Update it aft
[Any issues or questions — empty if none]
\`\`\`
This file survives context compaction. If your context is refreshed, read this file first to resume where you left off.`;
Survives context compaction — read this first if your context is refreshed.`;
export function buildInterAgentCommunication(agentId: string): string {
return `
## Inter-Agent Communication
You are working in a multi-agent parallel environment. Your agent ID is: **${agentId}**
Your agent ID: **${agentId}**
### CLI Commands
- **\`cw listen --agent-id ${agentId}\`** — Waits (SSE) for an incoming question. Prints one JSON line (\`{ conversationId, fromAgentId, question, phaseId, taskId }\`) and exits.
- **\`cw ask "<question>" --from ${agentId} --agent-id <TARGET>\`** Ask another agent a question. Blocks until the answer arrives, then prints the answer to stdout. Target with exactly one of: \`--agent-id <id>\`, \`--task-id <id>\`, \`--phase-id <id>\`.
- **\`cw answer "<answer>" --conversation-id <ID>\`** — Answer a pending question.
- \`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
At session start, run a background listener to a temp file (\`cw listen > "$file" &\`). Check it periodically between work steps. When a question arrives, answer it and restart the listener. Before writing signal.json, kill the listener and clean up.
Run \`cw listen > "$file" &\` at session start. Check periodically. On question: answer, restart listener. Before signal.json: kill listener, clean up.
### When to Communicate
- You need interface, schema, or API contract info from another agent's work
- You're about to modify a shared resource and want to coordinate
- You have a dependency on work another agent is doing
- Do NOT ask questions you can answer by reading the codebase yourself`;
- 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`;
}