preflight-build-or-borrow

name

preflight-build-or-borrow

description

Evidence-backed pre-build decision workflow for software ideas. Use when the user is deciding whether to build a new product, agent, internal tool, package, clone, or feature and wants to know whether similar repos, packages, or tools already exist, whether to build, fork/adapt, use a package stack, narrow the wedge, or skip/pivot. Do not use for implementation, debugging, code review, or polishing work already underway.

Purpose

Prevent unnecessary greenfield builds.

Act like a skeptical technical product partner. Search for evidence, compare reuse options, and return a short forced-choice recommendation. Default to a decision memo, not a long report.

Trigger Boundaries

Use this skill when the user is:

• deciding whether to build something new
• asking whether a similar repo, package, or tool already exists
• asking whether they should fork, reuse, or buy time with packages
• asking for a pre-build check before implementation starts

Do not use this skill for:

• debugging
• code review
• implementation planning after the build decision is already made
• UI polish, refactoring, or bug fixing
• broad market research with no software build/reuse decision attached

First Reads

Always read:

• references/workflow.md
• references/output-contract.md

Read these when needed:

• references/scoring-rubric.md before final scoring
• references/query-playbook.md when terminology is ambiguous or the space is crowded
• references/confidence-policy.md when evidence is mixed or sparse

Required Workflow

1. Normalize the request into:
   • idea
   • user_type
   • core_features
   • stack_preferences
   • constraints
   • claimed_differentiator
2. Build at least four query styles:
   • plain-English repo query
   • compressed noun phrase
   • feature-based query
   • alternate terminology query
3. Gather evidence in this order:
   • GitHub MCP if available
   • Grep MCP if available
   • general GitHub/web search fallback
   • package/library checks only when obviously relevant
4. Merge and deduplicate:
   • forks
   • thin wrappers
   • archived repos
   • abandoned near-duplicates
5. Score candidates with the rubric in references/scoring-rubric.md.
6. Produce a forced verdict:
   • build
   • build_narrower_wedge
   • fork_existing
   • use_package_stack
   • skip_or_pivot
7. Return:
   • a concise human-readable memo
   • machine-readable JSON that matches references/output-contract.md

Decision Rules

• Recommend fork_existing when one or more maintained candidates have high overlap, workable licenses, and a credible adaptation path.
• Recommend use_package_stack when mature packages solve most of the need and the user is really facing an implementation choice, not a product wedge.
• Recommend build_narrower_wedge when the category is crowded or partially served, but a narrower segment or workflow still looks open.
• Recommend skip_or_pivot when the space is crowded and the user has no credible differentiator.
• Recommend build only when overlap is weak, the wedge is clear, and coverage is strong enough to justify the call.

Confidence Rules

• Say high only when search coverage is broad and multiple signals agree.
• Say medium when there is enough evidence for a directional decision but not full certainty.
• Say low when search coverage is thin, terminology is ambiguous, or the evidence conflicts.
• Prefer a low-confidence memo over invented certainty.

Output Rules

• Keep the default memo short.
• Include evidence, not vibes.
• Distinguish products, repos, and packages.
• Call out weak coverage explicitly.
• If the verdict is positive, include one clear next move for Codex.

Anti-Patterns

• Do not write a 20-section market report by default.
• Do not recommend build without search evidence.
• Do not confuse packages with end-user products.
• Do not treat abandoned repos as strong competition.
• Do not overstate market certainty.
• Do not bury the verdict under background context.

Deterministic Support

If structured help is useful, use the bundled scripts in scripts/.

Each script accepts JSON in and emits JSON out. The orchestrator can also accept externally gathered candidates, which is the preferred way to combine this skill with MCP-based search.