refactor(prompts): deduplicate Squint protocol across agent templates

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 <slug> --json` for each relevant feature — returns its flows, modules involved, and interactions
-   - `squint flows show <slug> --json` for each relevant flow — returns the ordered interaction chain with entry point and definition-level call trace across modules
-   - `squint modules show <path> --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 <path> --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 <path> --json` via Tmux first — this aggregates all symbols, relationships, interactions, and flows for the file
+<% if (it.squintEnabled) { %>   - Use `squint symbols show --file <path> --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

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 <slug> --json` for each relevant feature — returns flows, modules involved, interactions
-   - `squint flows show <slug> --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 <path> --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 <path> --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?

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 <slug> --json` for each relevant feature — returns flows, modules involved, interactions
-   - `squint flows show <slug> --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 <path> --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 <path> --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?<% } %>
 

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 <path> --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") %>
 

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 <slug> --json` for each relevant feature — returns flows, modules involved, interactions
-   - `squint flows show <slug> --json` for key flows — returns ordered interaction steps and the definition-level call trace across module boundaries
-   - `squint modules show <path> --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 <path> --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?