Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Follow-on Skills

These are follow-on skills we have found useful once your coding agent can search with Apira.

Start with Apira for Coding Agents. Apira finds candidate repositories. The skills on this page help the agent inspect selected repositories with more depth.

The shared shape is:

  1. Use Apira to find candidate repositories.
  2. Select one or a few candidates from the evidence.
  3. Clone each selected repository locally.
  4. The agent inspects the local clone with a focused methodology.
  5. Return findings with source paths, caveats, and next actions.

Cloning first matters. A local worktree gives the agent normal file tools for reading, grepping, following imports, and citing precise locations instead of relying on shallow web snippets.

Install these in your agent harness

Copy one of the skill recipes below into your coding agent and ask it to create the skill using the harness's native convention.

Different harnesses store reusable instructions differently:

  • Pi uses skill files.
  • Claude Code may use skills or agent instructions.
  • Cursor may use rules.
  • Other agents may use tool registries, memory, or prompt files.

Before creating files, the agent should inspect the local harness conventions and adapt the recipe to that format. Preserve the skill name, trigger conditions, workflow, methodology, and output contract.

Do not force a specific storage format. If the harness supports named skills with frontmatter, use the suggested name and description. If it uses rules or prompt files, convert the same content into that format.

Repo deep dive — your personal DeepWiki

Use this when the agent needs top-down understanding of a selected repository.

repo-deepdive clones the repository, explores the local files systematically, and returns an architectural explanation. Use it to understand module maps, design decisions, trade-offs, and how the system fits together before deciding what to copy or adapt.

Create a reusable skill named `repo-deepdive`.

Use this harness's native skill, rule, or reusable-instruction format. If the harness supports frontmatter, use equivalent metadata:

name: repo-deepdive
description: Deep-dive on a selected GitHub repository after Apira finds candidate repos; clone locally, inspect top-down, and return architecture, module map, trade-offs, and cited source locations.

Purpose:
Give the agent top-down understanding of a selected repository after Apira finds candidate repos.

Trigger when:
- The user wants to understand how a selected repo works.
- The user asks for architecture, module map, design trade-offs, extension points, or onboarding.
- Apira returned a promising repo and the next step is top-down understanding.

Do not use for:
- Searching for candidate repos; use `apira` first.
- Extracting copy-ready implementation snippets; use `repo-patterns`.
- License, security, or dependency-risk review.

Workflow:
1. Use `apira` to find repositories that solve a similar architectural problem.
2. Select 1-2 strong candidates based on evidence and maintenance signals.
3. Clone each selected repository locally before analysis.
4. Inspect the local clone with the methodology below.
5. Summarize architecture, module map, trade-offs, extension points, and risks.
6. Use the findings to inform the user's implementation plan.

Best for:
- Comparing architecture approaches.
- Getting unstuck on complex subsystem design.
- Understanding mature open-source implementations before building.
- Building a top-down mental model of an unfamiliar repo.

Methodology:
1. Skeleton pass:
   - Enumerate the file tree. Prefer `git ls-files`; otherwise use `find . -type f` excluding `.git`, `node_modules`, `dist`, `build`, `.venv`, lock files, and binaries.
   - If there are no files, stop with Stopping reason `empty repository`.
   - Read the highest-signal artifacts in one pass: root README plus stack manifests such as `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `build.gradle`, `Gemfile`, or `*.csproj`.
   - Rank 3-8 candidate files against the user's objective and record deferred candidates for `Files NOT explored`.

2. Focused read pass:
   - Use the cheapest tool that can answer the question: search paths first, search symbols or patterns next, read files only when needed.
   - Read as many files as the objective genuinely requires.
   - Prefer focused ranges for files over roughly 400 lines.
   - Never read generated artifacts, lock files, or vendored code unless the objective is specifically about them.

3. Synthesis and verification:
   - Lead with a short TL;DR.
   - Explain the architecture, key modules, data/control flow, design trade-offs, and risks relevant to the objective.
   - Cite specific files and lines for load-bearing claims.
   - Verify the most important cited line numbers with targeted searches before returning.
   - Be explicit about gaps and files not explored.

Stopping behavior:
- Stop when the objective is answered with verified citations.
- If three consecutive searches or reads produce no new useful file, symbol, or pattern, stop and report the partial answer.

Output schema:

### Answer

A 2-3 sentence TL;DR, followed by the architectural explanation. Cite `path:LINE` or `path:LINE-LINE` for specific claims; cite whole files for README, manifests, or configs.

### Files explored

- `path/to/file` — one-sentence reason

### Files NOT explored

- `path/to/file` — one-sentence reason, or `None.`

### Open questions

- Follow-ups for the caller, or `None.`

### Stopping reason

One sentence: objective answered, no-progress, objective too broad, objective ambiguous, or empty repository.

Repo patterns — implementation pattern extraction

Use this when the agent needs reusable implementation details from a selected repository.

repo-patterns starts from concrete files and extracts named patterns, snippets, dependencies, and adaptation caveats. It is best when the user is likely to reuse a specific implementation technique.

Create a reusable skill named `repo-patterns`.

Use this harness's native skill, rule, or reusable-instruction format. If the harness supports frontmatter, use equivalent metadata:

name: repo-patterns
description: Extract reusable implementation patterns from a selected GitHub repository after Apira finds candidate repos; clone locally, inspect bottom-up, and return named patterns, snippets, dependencies, and reuse caveats.

Purpose:
Extract reusable implementation patterns from a selected repository after Apira finds candidate repos.

Trigger when:
- The user wants reusable implementation patterns from a selected repo.
- The user asks how a repo implements a specific concern.
- Apira returned a promising repo and the next step is extracting snippets or adaptation guidance.

Do not use for:
- Searching for candidate repos; use `apira` first.
- General architecture onboarding; use `repo-deepdive`.
- Copying code without license, security, fit, and code-quality review.

Workflow:
1. Use `apira` to find repositories matching the implementation pattern or dependency need.
2. Select 1-3 candidates based on evidence, maintenance signals, and ecosystem fit.
3. Clone each selected repository locally before analysis.
4. Inspect the local clone with the methodology below.
5. Extract reusable snippets, module boundaries, dependencies, and adaptation caveats.
6. Explain which patterns are reusable and what must change for the user's codebase.

Best for:
- Reusing implementation patterns.
- Finding concrete snippets to adapt with review.
- Understanding how a specific concern is implemented across files.

What counts as a reusable pattern:
A pattern is worth surfacing only if it passes all four checks:
1. Self-contained — fits in a single function, class, or file with a nameable interface.
2. Clear interface — has inputs and outputs another agent can name without reading the body.
3. Replicable shape — could plausibly be lifted into a different codebase with only type, dependency, or naming adjustments. Assembly patterns count when repo-specific glue wraps a reusable algorithm.
4. Concrete instance — a real symbol at a real path and line, not a paraphrase.

If a candidate fails any check, drop it. Quality beats quantity.

Methodology:
1. Skeleton pass:
   - Enumerate the file tree. Prefer `git ls-files`; otherwise use `find . -type f` excluding `.git`, `node_modules`, `dist`, `build`, `.venv`, lock files, and binaries.
   - If there are no files, stop with Stopping reason `empty repository`.
   - Read the highest-signal artifacts in one pass: root README plus stack manifests such as `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `build.gradle`, `Gemfile`, or `*.csproj`.
   - Rank files by likely pattern density. `utils`, `lib`, `helpers`, and single-purpose module-root files rank high; route definitions, dependency-injection wiring, generated code, and config-only files rank low unless they wrap a reusable algorithm.

2. Mining pass:
   - Use the cheapest useful tool: path search, then pattern search, then file reads.
   - Search for export shapes such as functions, classes, constants, decorators, and higher-order wrappers.
   - Skip pure glue, but mine glue when it contains a reusable algorithm or assembly pattern.
   - Concern-scoped prompts often surface 2-5 patterns from 4-10 files. Broad prompts may surface more, but no pattern should be included unless it passes the four checks.

3. Distill and verify:
   - For each surviving pattern, capture a short noun-phrase name, location, one-line shape, verbatim snippet, dependencies, variations, and reuse caveat.
   - For long patterns, show the signature plus the first and last relevant lines with a clear omission marker.
   - For assembly patterns, show the verbatim core algorithm and identify omitted project-specific wrapper code.
   - Verify each cited line with a targeted search before returning. If the citation cannot be verified, drop the pattern.

Stopping behavior:
- Stop when three consecutive mining searches or reads produce no new candidate pattern.
- Report this as Stopping reason `yield-exhausted`.

Output schema:

### Patterns

For each pattern, most copy-worthy first:

#### <pattern name>

- **Where:** `path:LINE-LINE`
- **Shape:** one-line interface description
- **Snippet:** verbatim code block
- **Dependencies:** packages, sibling modules, non-obvious built-ins, or `none — stdlib only`
- **Variations:** related locations, if any
- **Reuse caveat:** one sentence

If no candidates survive, write `None — see Stopping reason.`

### Files explored

- `path/to/file` — one-sentence reason

### Files NOT explored

- `path/to/file` — one-sentence reason, or `None.`

### Open questions

- Follow-ups for the caller, or `None.`

### Stopping reason

One sentence: yield-exhausted, objective too broad, objective ambiguous, or empty repository.

Choosing between them

Use repo-deepdive when the question is top-down and architectural:

  • “Explain how this repo works.”
  • “Map the data layer.”
  • “Onboard me to this package.”
  • “Compare this architecture to our planned approach.”

Use repo-patterns when the question is bottom-up and implementation-specific:

  • “Show me how this repo implements retry/backoff.”
  • “Find reusable config-loading patterns.”
  • “Extract the streaming JSON utility and adaptation caveats.”