Gather Context

---
name: gather-context
description: Build comprehensive understanding of a problem by gathering context from GitHub issues, dagger nodes, codebase exploration, git history, and linked references. Use when starting work on an issue or investigating a problem.
argument-hint: "[#issue | slug#7 | problem description]"
allowed-tools:
  - Bash(command -v:*)
  - Bash(echo:*)
  - Bash(gh issue view:*)
  - mcp__plugin_dagger_dagger__show_node
  - mcp__plugin_dagger_dagger__inputs
  - mcp__plugin_dagger_dagger__explain
  - Bash(gh pr view:*)
  - Bash(git blame:*)
  - Bash(git diff:*)
  - Bash(git log:*)
  - Bash(git remote get-url:*)
  - Bash(git rev-parse:*)
  - Bash(git show:*)
  - Bash(ls:*)
  - Glob
  - Grep
  - Read
  # Read-only index queries. The mutating tools on these servers
  # (index_repository, delete_project, manage_adr, ingest_traces) are
  # deliberately withheld — this skill does not write.
  - mcp__codebase-memory__search_graph
  - mcp__codebase-memory__search_code
  - mcp__codebase-memory__trace_path
  - mcp__codebase-memory__get_code_snippet
  - mcp__codebase-memory__query_graph
  - mcp__codebase-memory__get_graph_schema
  - mcp__codebase-memory__get_architecture
  - mcp__codebase-memory__index_status
  - mcp__qmd__query
  - mcp__qmd__get
  - mcp__qmd__multi_get
  - mcp__qmd__status
---

# Gather Context: Build Understanding Before Acting

**Autonomy:** model-invocable · acts autonomously · has no write, edit, or commit capability

Gather comprehensive context about a problem before proposing solutions. Practice Chesterton's Fence: understand why things exist before changing them.

## Arguments
```
$ARGUMENTS
```

## Pre-computed Context

```
Git root: !`git rev-parse --show-toplevel 2>/dev/null || echo "NOT A GIT REPO"`
Remote: !`git remote get-url origin 2>/dev/null || echo "no remote"`
Has gh: !`command -v gh 2>/dev/null && echo "yes" || echo "no"`
```

## Constraints

- **Never use `git -C <path>`** — it rewrites the command prefix, breaking `allowed-tools` pattern matching.
- This skill is read-only. Do not modify files, create branches, or make commits.
- Gather context proportional to the problem size. A typo fix doesn't need 3 Explore agents.

## Instructions

### 1. Determine Context Scope

Assess what kind of investigation is needed based on `$ARGUMENTS`:

| Input | Scope |
|-------|-------|
| Dagger node whose body names deliverables, acceptance criteria and the docs that govern it | **Skip** — read the body and what it cites; re-reading it as "research" is pure cost |
| Dagger node with a thin body, or one pointing into code you don't know | **Gap-scoped** — investigate only what the body left open, not the whole node |
| Issue ref (`#123`) with clear, narrow body | **Light** — fetch issue, quick codebase scan |
| Issue ref with broad/vague body or multiple comments | **Full** — fetch issue + parallel exploration + history |
| Problem description (no issue) | **Full** — explore codebase, search history |

A well-written work order has already absorbed this phase: its Context section names the specs, its Notes section carries the traps. Read those rather than rediscovering them, and say explicitly which gap you are investigating. On a dagger node, also read `inputs` — a predecessor's result is context that no amount of codebase exploration will recover.

### 2. Fetch the Issue (if applicable)

If `$ARGUMENTS` is an issue reference:

```bash
gh issue view <number> --json number,title,body,labels,comments,assignees,milestone,projectItems
```

Extract:
- **Goal**: What needs to change and why
- **Labels**: What labels are applied and what they indicate about priority, readiness, type, and scope
- **Comments**: Additional requirements, discussion, decisions
- **Linked references**: Other issues, PRs, URLs mentioned in body/comments

If comments reference other issues, fetch those too:
```bash
gh issue view <linked-number> --json number,title,body,labels
```

### 3. Query the Indexes Before Spawning Agents

Two local indexes answer in one call what an Explore agent spends several greps on, and they reach past the current repo. Call patterns and argument shapes: `INDEXES.md`.

| Question | Index |
|---|---|
| Where is this defined, who calls it, what would a change reach? | `codebase-memory` — every repo in `~/src`, not just this one |
| Have I already written about this — a decision, a note, prior research? | `qmd` — the markdown vault |

Project names are derived, never looked up: `~/src/<host>/<owner>/<repo>` → `<host>-<owner>-<repo>`, dots and slashes to dashes, **case preserved** — `Gusto/glide` is `github-com-Gusto-glide`, and lowercasing it returns "project not found". **Do not call `list_projects`** — it overruns the result budget at this corpus size.

Both indexes **locate**; neither is authoritative about behaviour. Treat every hit as a pointer and `Read` the file before asserting anything about it. A stale index answers confidently and gives no signal that it is out of date.

Reach for the graph hardest when the problem names a service, client, or library that lives in **another repo** — an Explore agent cannot grep a checkout nobody pointed it at, and that is the case where blind exploration quietly returns nothing.

### 4. Explore in Parallel

Spawn Explore agents for what the indexes could not answer — unindexed or uncommitted code, behaviour under specific inputs, anything needing judgement rather than lookup. Each agent gets a specific focus; don't duplicate work across agents, or repeat what step 3 already found.

**Light scope** (1 agent):
- Find files and functions relevant to the issue using keywords from the title/body

**Full scope** (up to 3 agents):

| Agent | Focus | Approach |
|-------|-------|----------|
| **Codebase** | Find relevant code | Start from the graph hits in step 3 and read outward — tests, callers, adjacent types. Fall back to keyword search only where the graph came up empty. |
| **History** | Understand prior work | `git log --all --grep="<keywords>"` for related commits. `git log --follow <file>` for files mentioned in the issue. Check for reverted commits or abandoned PRs. Look at who last touched the relevant code and what they changed. |
| **Related** | Gather linked context | Fetch linked issues/PRs. If the issue references external docs or URLs, use `WebFetch` to gather them. Check if similar issues were filed and closed before. |

Only spawn the Related agent if there are actual linked references to follow.

### 5. Synthesize Findings

Produce a structured summary. This is the output other skills (like `/think` and `/plan`) will consume.

**Problem Statement**
- What needs to change (from issue body + comments)
- Why it needs to change (motivation, who's affected)
- What "done" looks like (acceptance criteria, if stated)

**Relevant Code**
- File paths and line ranges
- Key functions, types, or patterns involved
- How the current code works (trace the relevant path)

**Prior Art**
- Previous attempts (commits, PRs, reverted changes)
- Related issues (open or closed)
- Relevant discussion or decisions from comments
- Notes or decisions already written down, from `qmd` — cite the document path

**Constraints**
- Project conventions (from CLAUDE.md, if it exists)
- Testing requirements (test suite location, patterns)
- Platform considerations (OS-specific behavior, templates)

**Open Questions**
- Gaps in the issue specification
- Ambiguities that need human clarification
- Assumptions that should be validated

Present findings concisely. Link to specific files and line numbers so the next phase can act on them directly.