mcpbeat Sign in

Codebase Recon Agent Skill

Reconstruct a repository as cited entry-to-test flows and bounded claims. Triggers: "codebase recon", "trace this codebase", "repository audit", "refresh the prior recon".

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
416
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/boshu2/agentops --skill codebase-recon

The instruction itself

10 sections, as written by the author

Codebase Recon

Build a reusable, falsifiable model of a repository. This skill reports what

the tree and executable probes support; it does not edit code or issue a final

PASS/WARN/FAIL verdict.

Constraints

  • To prevent a floating recon, record the exact repository commit and local

source-of-truth precedence.

  • Because confidence is not evidence, type every material claim and cite each

fact and inference.

  • To preserve traceability, prefer a verified delta when a prior pack exists

instead of rewriting unchanged evidence as fresh discovery.

Modes, views, and lenses

One skill replaces a cluster of loose recon skills. Steer it with mode, view

emphasis, lens, and depth — do not invent a second skill for each shape.

| Control | Values | Use when |

|---|---|---|

| Mode | baseline \| delta | First pack vs refresh after a prior recon |

| View emphasis | mental model · bounded audit · pattern evidence · synthesis | Archaeology-style map, audit-style findings, pattern harvest, or executive synthesis |

| Lens | persistence · auth · CLI · build · test (one per pass) | Domain-deep cut instead of a shallow whole-tree sweep |

| Depth | quick · standard · deep | Orientation vs onboarding vs decision-grade evidence |

Ask for the shape explicitly, for example:

codebase-recon --mode=delta --view=audit --lens=cli --depth=standard
codebase-recon baseline, mental-model view, persistence lens, deep

Natural-language equivalents count. The durable pack still carries all four

views; emphasis changes what you spend tokens on and what the companion report

leads with. Pattern packaging beyond evidence pointers belongs in

pattern-mining. Binding PASS/FAIL stays with

validate.

Workflow

  • Record the current commit and the repository's local source-of-truth

precedence. Search for a prior recon pack before starting.

  • If no prior pack exists, use baseline mode. If one exists, verify its

still-valid claims against the current commit and use delta mode. Preserve

valid evidence by reference and describe only changed paths and synthesis.

  • Trace representative paths from entry point to domain logic, integration

boundary, and test. Prefer a few complete flows over a broad file inventory.

  • Keep four views distinct in the report: mental model, bounded audit, pattern

evidence, and synthesis. Label each claim fact, inference, or unknown,

assign confidence, and cite evidence for facts and inferences.

  • List inspected and uninspected scope. Write the JSON manifest and companion

report, then run the validator. Missing evidence and hidden coverage gaps are

contract failures, not prose caveats.

Docs-first entry-point tracing

Enter through what the repository declares about itself — README, architecture

docs, build manifests, CLI help — and only then verify those declarations

against the tree. Before the first broad search, list the declared entry points

and trace at least one of them to code. The named failure mode is grep-first

drift: opening with keyword sweeps builds a model of whatever happened to

match, and the recon inherits the search terms' blind spots instead of the

repository's actual shape. When declaration and code disagree, that is a

finding, not noise: record the doc's claim as inference, the traced behavior

as fact, and cite both.

One-domain-deep lens per pass

Each pass adopts exactly one lens — persistence, auth, CLI surface, build

system, test harness — and follows it from entry point through domain logic to

its tests before switching lenses. A pass ends in exactly one of two states:

the lens has one complete entry-to-test flow, or the report names the file and

line where the trace was cut and why. The named failure mode is the shallow

sweep: touching every directory at depth one produces a file inventory that

reads like a model but supports no claim, because no path was followed far

enough to falsify anything.

Citation floor: file:line or downgrade

The durable output doc earns its keep only if a future reader can re-verify a

claim without redoing the recon. Every fact cites file:line; every

inference cites the file:line facts it rests on. A claim that cannot be

cited is downgraded to unknown before the report ships — never shipped

uncited at its original confidence. The manifest validator accepts a bare file

path (it requires the path resolve to an existing regular file, so a bare

directory is rejected as a coverage gap), but does not require the line number;

hold the companion report to the stricter floor: a path without a line is a

pointer to homework, not a citation, and counts as a coverage gap in the

report's own terms.

When reconstructing a repository other than the one that ships this skill, pass

--repo-root <target> to the validator so evidence resolves against the target

tree rather than the skill's own checkout.

Output Specification

  • Artifact directory: .agents/recon/<run-id>/
  • Filename convention: codebase-recon.json with companion report

codebase-recon.md in the same directory.

  • Format: codebase-recon.v1 JSON manifest plus an evidence-cited Markdown

report covering the same commit, mode, flows, claims, and scope boundaries.

  • Validation command: skills/codebase-recon/scripts/validate-output.sh <codebase-recon.json>

validates the machine-readable manifest; the cited Markdown report remains

its human-readable companion.

  • Downstream handoff: pass both validated artifact paths to the requesting

research, planning, review, or documentation workflow; the consumer owns any

decision or code-change plan.

Baseline manifests carry at least one complete entry-to-test flow. Delta

manifests name an existing prior recon, prove baseline_verified: true, and

describe at least one changed path. Every manifest lists both inspected and

uninspected scope.

The validator is the machine boundary:

skills/codebase-recon/scripts/validate-output.sh <recon.json>

Evidence entries are existing file paths, optionally followed by a line number.

Delta manifests require an existing prior pack, baseline_verified: true, and

at least one described change.

Executable behavior:

references/codebase-recon.feature.

Quality

  • Every fact and inference resolves to existing evidence; unknowns remain

visibly typed and never masquerade as established behavior.

  • Representative flows reach entry, domain, integration, and test surfaces,

while inspected and uninspected scope stay explicit.

  • The named validator passes before the JSON manifest and companion report are

handed to a downstream consumer.

Do not

  • Regenerate a full replacement report when a verified delta is possible.
  • Present an inference as fact or omit uninspected scope.
  • Turn the recon artifact into a completion verdict or a code-change plan.

Other skills for the same job

different authors, same section of the catalogue
MCP Builder
by anthropics
vendor ×13

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

30k tokens scripts
Changelog Generator
by frostant
×9

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

774 tokens
Finishing A Development Branch
by ZhanlinCui
×7

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

1k tokens
MCP Builder
by JayZeeDesign
×7

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

37k tokens scripts
Vercel React Native Skills
by vercel-labs
vendor ×6

React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.

39k tokens
Vercel React Best Practices
by ratacat
×5

React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

34k tokens
Next Best Practices
by vercel-labs
vendor ×4

Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling

20k tokens
Using Git Worktrees
by ZhanlinCui
×4

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

1k tokens

How to use it

Copy the folder

Take boshu2/codebase-recon from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.