reuse-before-build

中文 · When to use it · Quick start · Results · Compatibility · MIT license

An Agent Skill that helps your coding agent discover existing implementations before choosing an architecture or technology stack, then decide what to Take, Borrow, or Build. When the project leaves a material gap, it searches GitHub and official repositories and inspects actual code, compatibility, integration cost, and license scope before recommending a direction.

The same workflow checks existing code before implementation, existing coverage before new tests, and saved evidence before resuming a task. It guides the agent toward the smallest justified design or change, using the tools already available in your project and host.

What this looks like in practice

Architecture discovery — illustrative workflow, not an executed evaluation:

Request   Design durable webhook delivery for a new service.
Discover  Find relevant implementations on GitHub and in official repositories.
Inspect   Read the core code, failure semantics, integration needs, and license.
Decide    Take a verified core, Borrow a suitable pattern, Build only the gap.
Deliver   Explain how those boundaries shape the architecture and its open checks.

The architecture example shows the constraints and evidence needed for that decision. An architecture-only request produces a design; it does not authorize installing dependencies or writing implementation code.

Test reuse — observed on the prior revision (2026-09-20): a recorded run on the small synthetic retry-service fixture explicitly loaded that version of the skill:

Request   Cover the retry failure boundaries.
Found     An existing retry function and test suite.
Changed   Added 2 cases to the existing test file; production code unchanged.
Verified  All 4 tests passed.

The result was a focused extension of the existing tests. Inspect the actual diff and test replay. This observation applies to that earlier revision; see the dated results below.

When to use it

• Tasks: architecture and technology choices for a new project, substantial features, dependency choices, test coverage gaps, or continuing unfinished engineering work. Small edits get a brief local check.
• Invocation: select or mention reuse-before-build to request the workflow. Hosts that support automatic skill selection may also load it when the task matches its description. Automatic selection is not guaranteed for every task; use an explicit first invocation to check that it loads. See host discovery guidance.
• Resuming work: have the agent save an engineering record before handoff, then provide its path to the next session. It checks the record against current code and test evidence. Installing the skill does not save the whole conversation or recover information that was never recorded.

Quick start

From the project where you want to use the skill, run:

npx [email protected] add Ai-Eastern/reuse-before-build --skill reuse-before-build --agent codex --copy -y

The optional installer needs Node.js ≥22.20.0. The skill itself does not. Prefer a manual copy? Put SKILL.md and LICENSE in .agents/skills/reuse-before-build/ for Codex; see copy commands and other host paths.

Use a clean checkout or source archive. From a separate consuming project, replace the source path and run:

npx [email protected] add "<absolute-path-to-clean-checkout>" --skill reuse-before-build --agent codex --copy -y

Do not run add . inside the skill source repository. See local installation details.

Open the target project in your agent, select or mention reuse-before-build, and try a real task:

Use reuse-before-build to add retry support to the existing HTTP client.
Check existing code, tests, and relevant decisions first.
Before editing, show what can be reused, what needs verification,
and the smallest next step.

For architecture planning:

Use reuse-before-build to design durable webhook delivery for a new project.
Check GitHub and official repositories where existing assets leave a gap.
Show what to Take, Borrow, or Build and how that changes the architecture.
Keep this to design; do not install dependencies or implement code.

The response should cite actual files or sources and explain its choice. See loading checks if the skill is absent, or use the included practice project.

How it works

Find existing work → Check fit and evidence → Choose the smallest scope → Verify.

Search starts with local code and tests, then standard library or platform capabilities, installed dependencies, and external candidates when needed. For architecture or a new project's stack, a material gap can lead to discovery on GitHub and in official repositories before committing to components and boundaries. Inspect the strongest candidates' code and contracts; a README claim or search snippet does not establish fit.

Research is event-scoped: an unresolved capability or compatibility gap can open external research, while a verified local fit closes it. Read the existing runner, actual assertions, fixtures, and exercised code before adding tests. An error, a new development phase, or a new session alone does not trigger a new survey.

Finding a candidate starts inspection. Before selecting it, record the inspected release or revision, compatibility fields, implementation symbols, a test or call site, and the applicable license. Missing evidence keeps it an unverified option. Design-only work defers installation and integration tests, while still requiring these checks before component selection.

Stop when the evidence is sufficient. Internet research is unnecessary when existing assets meet the need, and must respect user restrictions. External discovery depends on the host's existing search tools and network access; the skill provides neither. Small edits get a brief local check.

If the selected path lacks necessary evidence and has no verified alternative, report Blocked. If a specific next action exceeds existing authorization, report Needs human approval. O