Identifies existing codebase capabilities that can be reused or extended to prevent building redundant features.
Install
mkdir -p .claude/skills/harness-recon && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/19152" && unzip -o skill.zip -d .claude/skills/harness-recon && rm skill.zipInstalls to .claude/skills/harness-recon
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Reconnoiter the codebase for prior art a proposed change could reuse or extend before its design is authored. Runs between the proposal and design artifacts in the OpenSpec flow (and is called by harness:build after proposal.md). Extracts the capabilities a proposal implies, searches at concept altitude, and writes a reuse ledger (reuse / extend / build-new per capability) into the proposal so the design author consumes it through OpenSpec's dependency channel. Use to find what already exists before building, avoid duplicating a service/util/component, or "understand the landscape" before committing a design. Triggers on "recon", "prior art", "what already exists", "before I build this", "find reuse", "harness recon", "/harness:recon".Key capabilities
- →Extract capabilities implied by a proposed change
- →Search the codebase for existing services or components
- →Classify overlap of existing code with proposed capabilities
- →Determine a reuse verdict (reuse, extend, build-new) for each capability
- →Write an evidence report of the recon findings
- →Update the proposal document with reuse verdicts
How it works
The skill extracts capabilities from a proposal, searches the codebase for existing solutions, classifies overlap, and then provides a reuse verdict for each capability, updating the proposal and generating an evidence report.
Inputs & outputs
When to use harness:recon
- →Check for reusable services
- →Identify existing functionality
- →Understand codebase landscape
About this skill
harness:recon — prior-art recon before design
Answers the one thing the proposal doesn't: what already exists that this change could reuse or extend instead of building new? Records what exists + the reuse verdict — never the HOW.
Bindings. Resolve rules dir, sources layout, change-state dir from
docs/HARNESS.md(› Paths). Never hardcode a project's directory structure.
Breadcrumbs
Emit one line at start + one at end — so harness iteration can trace this run in the session transcript.
- start:
▶ harness:recon+ any mode/target this run has (e.g.· gated · <change>,· <task-id>,· #<pr>). - end:
■ harness:recon v<hash8> → <outcome>— one-line result; addstopped: <fork>/skipped: <reason>when applicable.<hash8>= first 8 chars ofgit hash-objecton this SKILL.md — compute it (run the command) in the end-of-run commands; never a placeholder.
Operator input
👉 = operator's turn. Prefix any line needing their answer (question / confirm / pick) and make it the terminal block — below the breadcrumb/trail/next, nothing actionable under it (a blocking ask buried above a ready action gets skipped; the eye must land on it last). While a 👉 is open, don't render a runnable /harness: next — show it gated behind the answer. Reserved marker, distinct from ⚠️ (warning) / ✨ (improvement) / ❓ (unclear-status).
Where: harness:build invokes it after proposal.md, before design.md. Also runs standalone.
Input: optional change name; if omitted, infer from context, else openspec list --json + a walk-me-through fork card (references/walk-me-through.md).
Steps
-
Resolve change. Announce
Using change: <name>.openspec status --change "<name>" --json. Noproposalartifact → stop: "Recon needs a proposal; author it first (openspec new/harness:build)." -
Seam check.
design.mdexists → prevention impossible → a walk-me-through fork card (references/walk-me-through.md):[R] Review-only/[S] Stop. Existingharness:reconblock in proposal → re-run, replace in place. -
Extract capabilities. Read
proposal.md. List implied behaviors, concept-level not file-level (e.g. "rank tasks in a project"). Per capability: label, domain nouns, verb, likely layer. <2 emerge → note + continue (all-build-newis valid for a novel change). -
Search prior art (read-only; ≥3 capabilities → one parallel agent each, else inline). Per capability:
- Conventional home via project structure + rules dir (HARNESS.md › Paths).
- Grep home + module index/barrel/public-API files for nouns + verb.
- Read candidate signature/doc/exports — judge purpose overlap, not name. Discard name-only collisions.
- Classify overlap:
full/partial/none.
-
Verdict per capability:
reuse <X>—full, usable as-is.extend <X>—partial, missing piece cohesive withX's responsibility; record the addition.build-new— no candidate, or reuse/extend would couple independent concerns (name the coupling).- Committed-use guard: new shared abstraction needs ≥2 named consumers today + stable interface, else
build-new("write the second use first").
-
Write two artifacts.
a. Evidence →
<change-state-dir>/recon.md(overwrite):# Recon ledger: <change> · against proposal.md · <N> capabilities | Capability | Candidate | Location | Overlap | Verdict | Reason | | --- | --- | --- | --- | --- | --- | | filter tasks by label | TaskRepository | <path> | partial | extend | add `labelId?` to the scoped query | | label CRUD service | (none) | — | none | build-new | no labeling domain yet | ## Notes <One block per row needing nuance — coupling rationale, committed-use deferral, a blocked near-dup. Omit self-evident rows.>b. Verdicts → idempotent marked block in
proposal.md(replace between markers, else append):<!-- harness:recon:start --> ## Prior-art recon (advisory) > Reuse verdicts for the design author. Advisory — design may override with a stated reason; > `harness:architecture` verifies these. Full evidence: `<change-state-dir>/recon.md`. | Capability | Verdict | | --- | --- | | filter tasks by label | **extend** — `TaskRepository` scoped query | | label CRUD service | **build-new** — no prior art | <!-- harness:recon:end --> -
Confirm. Show verdict tally. Any judgment call (contested
extendvsbuild-new, a coupling decision) → a walk-me-through fork card:[Y] Accept/[A] Adjust/[D] Discuss. On A/D, revise + rewrite both. A contested verdict that's resolved → append one line to the decision log (<change-state-dir>/decisions.md, perreferences/decision-log.md—🤖 recon, or👤 humanif the human picked). Obvious verdicts: not logged.
Output
harness:recon complete — <name>
Verdicts → proposal.md (## Prior-art recon) · evidence → <change-state-dir>/recon.md
Verdicts: <R> reuse · <E> extend · <B> build-new
Next: author design.md (reads the proposal incl. verdicts)
harness:architecture — gate; verifies design honored the verdicts
Review-only mode → replace Next with: "design already exists — feed the ledger to harness:architecture."
Don't
- Writes two places only — the marked
harness:reconblock inproposal.md+<change-state-dir>/recon.md. No other artifact, no code. Never edit vendor files (.claude/skills/openspec-*,.claude/commands/opsx/*). - Never design prose or implementation shape — existence + verdict only (the no-stake searcher seam).
build-newis first-class — never bias toward reuse; discard name-only matches.- Concept altitude only — file-level near-dupe is
harness:build's surface-map job. - Don't over-DRY — coupling independent modules to remove duplication is the wrong trade.
When not to use it
- →When the design document already exists
- →When the task is to write design prose or implementation shape
- →When the task involves editing vendor files
Limitations
- →It does not write design prose or implementation shape
- →It does not edit vendor files
- →It does not bias toward reuse
How it compares
This skill systematically identifies reusable code before design, preventing duplication and informing architectural decisions, unlike starting design without prior art research.
Compared to similar skills
harness:recon side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| harness:recon (this skill) | 0 | 11d | No flags | Advanced |
| agent-v3-security-architect | 3 | 5mo | Review | Advanced |
| gz-adr-audit | 0 | 1mo | Review | Advanced |
| audit-workflow | 0 | 2mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
agent-v3-security-architect
ruvnet
Agent skill for v3-security-architect - invoke with $agent-v3-security-architect
gz-adr-audit
tvproductions
Gate-5 audit templates and procedure for ADR verification. GovZero v6 skill.
audit-workflow
FlorianDrevet
Use when: code audit, technical audit, security audit, performance audit, scalability audit, database audit, audit markdown, GitHub audit issues, findings reconciliation, labels sync.
architect-review
sickn33
Master software architect specializing in modern architecture patterns, clean architecture, microservices, event-driven systems, and DDD. Reviews system designs and code changes for architectural integrity, scalability, and maintainability. Use PROACTIVELY for architectural decisions.
solid-principles
SmidigStorm
Enforce SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) in object-oriented design. Use when writing or reviewing classes and modules.
codex
Lucklyric
Invoke Codex CLI for complex coding tasks requiring high reasoning capabilities. This skill should be invoked when users explicitly mention "Codex", request complex implementation challenges, advanced reasoning, or need high-reasoning model assistance. Automatically triggers on codex-related requests and supports session continuation for iterative development.