Use this skill to prepare a project before repetitive AI execution begins.
-
Inspect the project first.
-
Classify it as blank/new or existing.
-
Classify source mode as founder-fed, web-assisted, or
public-first-prototype.
-
Run the read-only preflight helper when available:
bun <skill-path>/scripts/preflight-check.ts --cwd <project> --mode all --format markdown
Then run managed planning setup before artifact creation or readiness:
bun <skill-path>/scripts/ensure-openspec.ts --cwd <project> --format markdown
Stop fail-closed on provider/runtime, compatibility, or setup failure.
-
Report the helper findings before writing:
Preflight decision: <decision>
Confidence: <confidence>
Project type: <blank/new | existing>
Next action: <next action>
Missing artifacts: <paths or none>
Readiness warnings: <warnings or none>
Founder input gaps: <gaps or none>
-
Reconcile the helper decision before continuing:
delegate-inventory: run or prompt an existing-project inventory review.ask-founder: ask the smallest useful founder-question batch.run-research: run bounded public research and record public evidence.write-artifacts: create or update missing canonical docs.create-sprint0: create Sprint 0 and the first bounded executable task.ready-for-execution: prepare handoff to execution.blocked: record the blocker and stop or ask.
-
Announce a concise file plan:
Create:
- <path> - <purpose>
Update:
- <path> - <purpose>
Leave untouched:
- <path> - <reason>
Needs user input:
- <question or blocker>
-
In interactive runs, ask a focused founder-question batch before treating
founder intent, customer, positioning, MVP, or product promise as captured.
If those answers are already explicit in the prompt or repo docs, record the
evidence path instead of asking again.
-
Look up repository and public facts directly. Ask founders for decisions,
not discoverable facts. When missing knowledge belongs to a domain expert,
create a bounded questionnaire instead of inventing an answer.
-
Create or update CONTEXT.md only when overloaded terms, important aliases,
or multiple actors/concepts materially affect requirements. Keep it
implementation-free and optional.
-
Route empirically answerable behavioral or visual uncertainty to
$build-right-prototype. Record the result as prototype evidence or a
prototype-assumption, never customer validation.
-
Create or update docs and task files by default after the file plan.
-
Stop before writing only when the user requested planning-only mode, a write
would overwrite substantial ambiguous content, project state is too unclear
for a safe edit, or the target belongs to an unrelated generated workflow.
-
Ask founder questions in small batches. Do not ask for everything at once.
If the user does not answer, continue only with repo-evidence inventory and
mark founder-owned claims as blocked or needing founder validation.
-
If founder context is thin and fast prototyping is allowed, use bounded web
research to fill gaps and mark those claims as prototype-assumption or
public-evidence-backed.
-
Use subagents when a required delegation trigger applies and subagent tools
are available. If a trigger applies but subagents are unavailable or the
user forbids them, record the skipped review and reduce confidence.
-
Mark unsupported claims as assumptions. Do not invent product truth.
-
Prepare the first executable task, but do not complete it unless the user
explicitly asks to continue into execution.
For an existing project whose completed baseline and blueprint explicitly
route next to build-right-feature-planning, preserve that handoff instead
of inventing a duplicate non-managed execution task.
-
Run the preflight helper again after artifact creation when available, then
reconcile its warnings against the readiness gate.
-
Report the helper decision again before claiming readiness.
-
End with an explicit readiness result. If founder input, external evidence,
required research, or required review is missing, stop at the gate instead
of advancing as if ready.
Treat a project as blank/new when it lacks most product docs, task trackers, and
authority docs. A scaffolded codebase with no product truth still counts as
pre-execution blank.
Treat a project as existing when it has meaningful docs, code structure, task
tracking, release process, or prior product decisions. Preserve existing
structure and create a source index before filling gaps.
Never automatically commit, push, merge, publish, deploy, or abort or resolve
an existing Git operation. Perform those actions only when the user explicitly
authorizes the exact action and target.
Do not claim product-feature readiness until product truth, MVP scope, evidence,
operating rules, and at least one bounded executable task exist.
