new-project — Full project bootstrap standard

This skill aggregates 25 core disciplines — engineering, product, testing, documentation, and security — into a single executable checklist. It exists because auto-triggering of individual skills is unreliable, and demanding that every new build apply the complete standard requires explicit invocation, not passive hopes.

Invoking new-project once = a guarantee that all mandatory skills below are consulted at the right moment in the project lifecycle.

How to run this (do this immediately on invocation)

1. Create a TodoWrite checklist with one item per skill in the table below (25 items). This is

the enforcement mechanism — it makes a skipped skill visible instead of silently lost.

1. Work the phases in order. Within a phase, invoke each skill via the Skill tool using the

exact identifier in the invoke column. Mark its todo completed once consulted.

1. "As-needed" skills (tagged ⟳) still get a todo. If genuinely not applicable this project

(e.g. no database, no external API), mark it completed with a one-line note "N/A — <reason>" rather than deleting it. The point is a conscious decision, never a silent skip.

1. Behavioral standards (tagged ✦) are rules, not Skill-tool calls — apply them as ongoing

behavior for the whole session; tick the todo once you've internalized/announced them.

Do not batch all 25 Skill invocations into one turn — that floods context with end-of-session guidance while you're still planning. Pull each one in as its phase arrives.

The 25 — by lifecycle phase

Phase 0 — Orientation (always first, before any design)

| Skill | invoke | why here | |---|---|---| | Brainstorming | superpowers:brainstorming | Explore intent/requirements/user intent BEFORE any build. Process skill — runs first. | | Project context | (optional: load project OWNER.md / README if exists) | If project has existing vision/stack docs, read them. Else skip. | | Search-first ✦ | (rule, not a skill) | Verify external facts (tool behavior, API limits, versioning, third-party state) before asserting them. Embedded behavior for the whole session. |

Phase 1 — Planning

| Skill | invoke | why here | |---|---|---| | Agent Flywheel | agent-flywheel | Plan-space-first: cost of fixing error in plan (~1x) vs. in code (~25x). Picks the build mode. | | Plan synthesis | superpowers:writing-plans | Multi-phase execution plan with checkpoints, or single-phase sprint plan. | | Red-team the plan | superpowers:requesting-code-review or manual adversarial pass | Challenge assumptions, identify failure modes, stress-test requirements. | | Impact metrics | impact-metrics-gate | Define primary success metric + measurement + baseline BEFORE building. | | Business validation ⟳ | business-guardrails | Validate before building: market fit, competitive gap, anti scope-creep. Only when product/business angle exists. |

Phase 2 — Foundation gates (before writing code)

| Skill | invoke | why here | |---|---|---| | Specification + ADRs | adr-spec-gate | Software spec + Architecture Decision Records mandatory before code. | | Engineering standards | engineering-standards | Charter, threat model, CI/CD gates, branch protection, SBOM, runbook templates. | | Infrastructure-as-Code (IaC) | iac-first-commit | Rebuildable from git pull + one command, declarative & idempotent from commit #1. | | Secrets management ⟳ | tokens-taxonomy | 1 token per purpose, least privilege, centralized vault strategy. Whenever secrets/credentials involved. |

Phase 3 — Build

| Skill | invoke | why here | |---|---|---| | Test-driven development | superpowers:test-driven-development | Test-first for every feature/bugfix. | | Parallel execution ⟳ | superpowers:dispatching-parallel-agents | When executing a plan with independent tasks that can run in parallel. | | Documentation | docs-as-code | Code without docs isn't done. Mandatory per session. | | Version control discipline | git-pr-rules | Pull requests always, never direct local merge into main. Non-negotiable. | | Version numbering | version-bump-rules | Every shipped change bumps version (semver). | | Excellence principle ✦ | excellence-no-intermediates | Never present "good enough for MVP / polish later" as a valid option. Excellence is binary. | | Instrumentation ⟳ | observability-when-to-add | Add observability only with confirmed pain; follow industry standards (OpenTelemetry, structured logging). | | Data completeness ⟳ | large-payload-completeness | When fetching/importing large datasets, verify no silent truncation. | | External integrations ⟳ | (API/SDK/service-specific skill if available) | When integrating third-party APIs, services, or external data sources. | | Data quality ⟳ | (manual QA checklist if no dedicated skill) | Before shipping analysis or data-driven features, validate methodology, accuracy, and bias. | | Deep research ⟳ | deep-research | Multi-source, fact-checked research when ground truth is unclear or claim needs verification. |

Phase 4 — Tracking & close

| Skill | invoke | why here | |---|---|---| | Executive tracking ⟳ | (PROGRESS.md if product/business project, otherwise optional) | Dashboard tracking for product projects; phase tracking for multi-phase builds. | | Ledger updates | superpowers:verification-before-completion or ledger-auto-updates | CHANGELOG + session-handoff at end of every substantive session. |

Legend

• ✦ = behavioral rule applied for the whole session (not a Skill-tool call).
• ⟳ = consult when its context appears; if not applicable, mark the todo "N/A — <reason>". Never silent-skip.

Note on overlaps

Some skills in this checklist may overlap intentionally (e.g., planning skills, review skills). Treat them as complementary: if running one already satisfied the need, mark the other's todo done with a one-line note "covered by previous skill]" rather than invoking both.

Runtime availability caveat

Some runtimes or projects may not have every referenced skill installed. If an exact identifier is missing:

• Mark the todo "N/A — skill unavailable in this runtime"
• If the skill covers something critical (e.g., git-pr-rules for version control), apply a manual

checklist for that discipline instead.

• For specialized skills (e.g., database migration, API design), if the tool is missing and the topic

is not relevant to the project, mark "N/A — not applicable".

This caveat keeps the aggregator enforceable without pretending unavailable tools were invoked.

Scope

Use for:

• New projects or repositories
• New non-trivial features in existing projects
• Major refactors or phase kickoffs
• "Let's build X from scratch" requests

Skip for:

• Trivial one-off edits or documentation tweaks
• Emergency ops or urgent hotfixes
• Merely executing an already-approved plan (the standard was already applied when the plan was made)
• Routine maintenance or CI/CD fixes

Why this exists

Auto-triggering of individual skills is unreliable because:

• Context windows vary; a skill may not see its trigger.
• Work flows may skip a phase (e.g., "just write the API, no business validation") and auto-trigger never fires.
• Silent skips are harder to detect than a visible unchecked todo.

This aggregator makes the entire standard enforceable through explicit invocation and a visible checklist.