Explore

Explore

Overview

Turn a task's code references into a fact checklist the main agent can act on without re-reading the repo.

Core principle: the repo owns facts; the user owns decisions. Read everything the task names; verify everything the user asserts; deliver a checklist, not an opinion.

Who reads

The main agent dispatches a background explore subagent and tells it to load this skill. The subagent is read-only: no design, no questions to the user, no code. If you are that subagent, this skill is your entire task — follow it exactly.

When to Use

• Task names code to change or reference: "refactor X", "model after Y", "reuse Z's pattern"
• The prompt contains technical assertions to verify (signatures, fields, SQL, types, "try not to update" style constraints)
• Refactor / legacy rework / reuse, where guessing the code shape would waste grill questions

When NOT to use: brand-new code with no anchors; bugfix with known root cause (debug); mechanical rename.

Trigger threshold (anchors trigger, width decides dispatch)

• Trigger: any task that names existing code — a method/class to change, a table/SQL, or a "reuse / model-after" pointer — gets an explore pass. No threshold below that.
• Dispatch width: one anchor, obvious chain (≤ 1 method + 1 table) → the main agent reads inline. Wide chain (multiple tables + referenced classes + data consumers) → dispatch a background subagent.
• The threshold is a rule, not a judgment call — decide by counting anchors, then dispatch.

The Iron Law (non-negotiable)

READ EVERYTHING THE TASK NAMES. VERIFY EVERYTHING THE USER ASSERTS.
Deliver facts only. If the repo can't answer it, it's a blocker — never guess.

Workflow

1. Parse anchors — every named method/class/table/config/SQL + every "reuse / model-after" pointer.
2. Read the full chain — target method → referenced classes → Mappers/entities/XML → the data's consumers (e.g., existing Redis retry consumers) → relevant config. Read implementations, not just signatures, when behavior matters.
3. Verify assertions — each technical claim in the prompt → ✓ consistent / ✗ contradicts, with file:line evidence.
4. Map conflicts — constraint vs repo reality (e.g., "try not to update" vs no status field → re-run duplicates).
5. Deliver the fact checklist — the format below, nothing else. Compact: it lives in session history, grill consumes it directly, and write-spec folds it into the Current state section.

Deliverable: Fact Checklist

### 1. Anchors
- <method>: exists ✓ — current behavior: <2 lines>
- <referenced class>: <signature/usage, 2 lines>
- <table> → Entity X; fields: <relevant fields>

### 2. Assertion check
- "<user's claim>": ✗ actual <thing> returns <X> (file:line)

### 3. Conflicts
- "<soft constraint>" ↔ <repo reality> → <consequence> → grill Q<#>

### 4. Judgment calls for grill  (one line each: question + why the repo can't answer)
- <idempotency / redis fallback / acceptance …>

### 5. Blockers
- <not found in repo; main agent decides whether to ask the user>

Rules: no design opinions (grill's job); no user-directed questions; missing anchor = blocker.

Small-task fallback (main agent)

One anchor, obvious chain → read inline. Dispatch the subagent when the chain is wide (multiple tables + referenced classes + consumers).

Rationalization Table

Red Flags

• Checklist contains recommendations or "should we…?" questions (that's grill's output channel)
• Assertion check empty despite claims in the prompt
• Anchor listed but not read (no evidence lines)
• User asked a question; subagent answered — subagents deliver facts, never decisions

Checklist

• All anchors read (target + references + tables + consumers)
• Every user assertion marked ✓/✗ with evidence
• Conflicts surfaced (constraint vs repo fact)
• Judgment calls framed for grill to ask one at a time
• No opinions, no user questions, no code