diff --git a/src/agents/prompts/templates/implementation.eta b/src/agents/prompts/templates/implementation.eta index 6173c799..8dd220c8 100644 --- a/src/agents/prompts/templates/implementation.eta +++ b/src/agents/prompts/templates/implementation.eta @@ -7,13 +7,9 @@ You are an expert software engineer implementing features and fixing issues base 1. **Review the pre-loaded work item data** and verify your pre-populated todo list matches the implementation plan <% if (it.squintEnabled) { %>2. **Consult the pre-loaded Squint overview** — identify which features and modules relate to the <%= it.workItemNoun || 'card' %> -3. **MANDATORY: Drill into features and modules before reading any source files:** - - `squint features show --json` for each relevant feature — returns its flows, modules involved, and interactions - - `squint flows show --json` for each relevant flow — returns the ordered interaction chain with entry point and definition-level call trace across modules - - `squint modules show --json` for each module area the <%= it.workItemNoun || 'card' %> touches — returns members, outgoing/incoming interactions, flows, and features - - This reveals cross-cutting dependencies (e.g., backend response shapes that frontend tests must match) that you will MISS by reading individual files +3. **Use the Squint Codebase Intelligence Protocol (below)** to explore features, flows, and modules before reading source files 4. **Read codebase guidelines** - CLAUDE.md, AGENTS.md (these are meta-docs about conventions) -5. **THEN read source files** — only the files Squint identified as relevant. Use `squint symbols list --file --json` to understand a file's full architectural role before reading its source.<% } else { %>2. **Read codebase guidelines** - CLAUDE.md, AGENTS.md (these are meta-docs about conventions) +5. **THEN read source files** — only the files Squint identified as relevant<% } else { %>2. **Read codebase guidelines** - CLAUDE.md, AGENTS.md (these are meta-docs about conventions) 3. **Read source files** — use `ListDirectory`, `ReadFile`, and `RipGrep` to explore the codebase and identify relevant files before making changes.<% } %> ### Phase 2: Prepare @@ -24,7 +20,7 @@ You are an expert software engineer implementing features and fixing issues base ### Phase 3: Implement 6. **For each file to modify:** -<% if (it.squintEnabled) { %> - Use `squint symbols list --file --json` via Tmux first — this aggregates all symbols, relationships, interactions, and flows for the file +<% if (it.squintEnabled) { %> - Use `squint symbols show --file --json` via Tmux first to understand the file's architectural role <% } %> - Read 1-2 similar files for patterns and conventions - Make changes - Verify no diagnostics errors before moving to next file diff --git a/src/agents/prompts/templates/planning.eta b/src/agents/prompts/templates/planning.eta index dd2eeebe..c7206eb1 100644 --- a/src/agents/prompts/templates/planning.eta +++ b/src/agents/prompts/templates/planning.eta @@ -18,12 +18,8 @@ You are running in a cloned copy of the project repository. Before creating your 1. **Read the <%= it.workItemNoun || 'card' %>** to identify scope signals (file names, components, features, domain terms) <% if (it.squintEnabled) { %>2. **Consult the pre-loaded Squint overview** — identify which features and modules relate to the <%= it.workItemNoun || 'card' %> -3. **MANDATORY: Drill into features, flows, and modules before reading any files:** - - `squint features show --json` for each relevant feature — returns flows, modules involved, interactions - - `squint flows show --json` for key flows — returns ordered interaction steps and the definition-level call trace showing which function calls which across module boundaries - - `squint modules show --json` for each module area — returns members, outgoing/incoming interactions, flows - - DO NOT SKIP — plans that miss cross-cutting dependencies (e.g., shared types, API contracts between backend and frontend) cause implementation failures -4. **THEN read specific files** — only files Squint identified as relevant. Use `squint symbols list --file --json` to understand a file's architectural role before reading source. +3. **Use the Squint Codebase Intelligence Protocol (below)** to explore features, flows, and modules before reading any files +4. **THEN read specific files** — only files Squint identified as relevant 5. **Understand existing patterns** — how does the codebase already solve similar problems? 6. **Map terminology** — <%= it.workItemNoun || 'card' %> may use different terms than code<% } else { %>2. **Explore the codebase** using `ListDirectory`, `ReadFile`, `RipGrep`, and `Tmux` to identify relevant files and patterns. 3. **Understand existing patterns** — how does the codebase already solve similar problems? diff --git a/src/agents/prompts/templates/respond-to-planning-comment.eta b/src/agents/prompts/templates/respond-to-planning-comment.eta index 2b37cc32..d47ba88f 100644 --- a/src/agents/prompts/templates/respond-to-planning-comment.eta +++ b/src/agents/prompts/templates/respond-to-planning-comment.eta @@ -19,12 +19,8 @@ You are running in a cloned copy of the project repository. Before updating the 1. **Read the triggering comment** to understand what the user wants changed 2. **Read the current <%= it.workItemNoun || 'card' %>** to understand the existing plan <% if (it.squintEnabled) { %>3. **Consult the pre-loaded Squint overview** — identify which features and modules relate to the requested changes -4. **MANDATORY: Drill into features, flows, and modules before reading any files:** - - `squint features show --json` for each relevant feature — returns flows, modules involved, interactions - - `squint flows show --json` for key flows — returns ordered interaction steps and the definition-level call trace showing which function calls which across module boundaries - - `squint modules show --json` for each module area — returns members, outgoing/incoming interactions, flows - - DO NOT SKIP — plans that miss cross-cutting dependencies (e.g., shared types, API contracts between backend and frontend) cause implementation failures -5. **THEN read specific files** — only files Squint identified as relevant. Use `squint symbols list --file --json` to understand a file's architectural role before reading source. +4. **Use the Squint Codebase Intelligence Protocol (below)** to explore features, flows, and modules before reading any files +5. **THEN read specific files** — only files Squint identified as relevant 6. **Understand existing patterns** — how does the codebase already solve similar problems?<% } else { %>3. **Explore the codebase** using `ListDirectory`, `ReadFile`, `RipGrep`, and `Tmux` to understand the relevant areas. 4. **Understand existing patterns** — how does the codebase already solve similar problems?<% } %> diff --git a/src/agents/prompts/templates/review.eta b/src/agents/prompts/templates/review.eta index b5f373af..05b901f0 100644 --- a/src/agents/prompts/templates/review.eta +++ b/src/agents/prompts/templates/review.eta @@ -21,7 +21,7 @@ CRITICAL: 1. **Understand the change**: Read the PR description and all modified files. Understand WHAT changed and WHY. An initial comment has already been posted on the PR acknowledging the review is in progress. -<% if (it.squintEnabled) { %>2. **Consult the pre-loaded Squint overview BEFORE reading files**: The overview maps module boundaries, dependencies (→ arrows), and feature flows. Use `squint modules show --json` via Tmux to drill into modules touched by the PR. This lets you verify changes fit established patterns without manually tracing the architecture. +<% if (it.squintEnabled) { %>2. **Use the Squint Codebase Intelligence Protocol (below)** to understand the codebase structure before reading files. Focus on modules touched by the PR to verify changes fit established patterns. <%~ include("partials/squint-exploration") %> diff --git a/src/agents/prompts/templates/splitting.eta b/src/agents/prompts/templates/splitting.eta index b6ef3fd4..7d4fbf7b 100644 --- a/src/agents/prompts/templates/splitting.eta +++ b/src/agents/prompts/templates/splitting.eta @@ -82,12 +82,8 @@ You are running in a cloned copy of the project repository. Before creating stor 1. **Read the <%= it.workItemNoun || 'card' %>** to identify scope signals (file names, components, features, domain terms) <% if (it.squintEnabled) { %>2. **Consult the pre-loaded Squint overview** — identify which features and modules relate to the <%= it.workItemNoun || 'card' %> -3. **MANDATORY: Drill into features, flows, and modules before reading any files:** - - `squint features show --json` for each relevant feature — returns flows, modules involved, interactions - - `squint flows show --json` for key flows — returns ordered interaction steps and the definition-level call trace across module boundaries - - `squint modules show --json` for each module area — returns members, outgoing/incoming interactions, flows - - DO NOT SKIP — accurate story sizing requires understanding cross-cutting dependencies -4. **THEN read specific files** — only files Squint identified as relevant. Use `squint symbols list --file --json` to understand a file's architectural role before reading source. +3. **Use the Squint Codebase Intelligence Protocol (below)** to explore features, flows, and modules before reading any files +4. **THEN read specific files** — only files Squint identified as relevant 5. **Understand existing patterns** — how does the codebase already solve similar problems? 6. **Map terminology** — <%= it.workItemNoun || 'card' %> may use different terms than the code<% } else { %>2. **Explore the codebase** using `ListDirectory`, `ReadFile`, `RipGrep`, and `Tmux` to identify relevant files and patterns. 3. **Understand existing patterns** — how does the codebase already solve similar problems?