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 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)
- 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.
- 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.
- "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 — " rather
than deleting it. The point is a conscious decision, never a silent skip.
- 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 — ". 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.
1---2name: new-project3description: Project bootstrap standard — guarantees all 25 core engineering and product disciplines are consulted in lifecycle order. Use when starting a new project, repository, feature, or phase. Prevents auto-trigger gaps by making the standard enforceable through a checklist.4---56# new-project — Full project bootstrap standard78This 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.910Invoking `new-project` once = a guarantee that all mandatory skills below are consulted at the right moment in the project lifecycle.1112## How to run this (do this immediately on invocation)13141. **Create a TodoWrite checklist** with one item per skill in the table below (25 items). This is15 the enforcement mechanism — it makes a skipped skill visible instead of silently lost.162. **Work the phases in order.** Within a phase, invoke each skill via the **Skill tool** using the17 exact identifier in the `invoke` column. Mark its todo `completed` once consulted.183. **"As-needed" skills** (tagged ⟳) still get a todo. If genuinely not applicable this project19 (e.g. no database, no external API), mark it `completed` with a one-line note "N/A — <reason>" rather20 than deleting it. The point is a conscious decision, never a silent skip.214. **Behavioral standards** (tagged ✦) are rules, not Skill-tool calls — apply them as ongoing22 behavior for the whole session; tick the todo once you've internalized/announced them.2324Do not batch all 25 Skill invocations into one turn — that floods context with end-of-session25guidance while you're still planning. Pull each one in as its phase arrives.2627## The 25 — by lifecycle phase2829### Phase 0 — Orientation (always first, before any design)30| Skill | invoke | why here |31|---|---|---|32| Brainstorming | `superpowers:brainstorming` | Explore intent/requirements/user intent BEFORE any build. Process skill — runs first. |33| Project context | *(optional: load project OWNER.md / README if exists)* | If project has existing vision/stack docs, read them. Else skip. |34| 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. |3536### Phase 1 — Planning37| Skill | invoke | why here |38|---|---|---|39| Agent Flywheel | `agent-flywheel` | Plan-space-first: cost of fixing error in plan (~1x) vs. in code (~25x). Picks the build mode. |40| Plan synthesis | `superpowers:writing-plans` | Multi-phase execution plan with checkpoints, or single-phase sprint plan. |41| Red-team the plan | `superpowers:requesting-code-review` or manual adversarial pass | Challenge assumptions, identify failure modes, stress-test requirements. |42| Impact metrics | `impact-metrics-gate` | Define primary success metric + measurement + baseline BEFORE building. |43| Business validation ⟳ | `business-guardrails` | Validate before building: market fit, competitive gap, anti scope-creep. Only when product/business angle exists. |4445### Phase 2 — Foundation gates (before writing code)46| Skill | invoke | why here |47|---|---|---|48| Specification + ADRs | `adr-spec-gate` | Software spec + Architecture Decision Records mandatory before code. |49| Engineering standards | `engineering-standards` | Charter, threat model, CI/CD gates, branch protection, SBOM, runbook templates. |50| Infrastructure-as-Code (IaC) | `iac-first-commit` | Rebuildable from `git pull` + one command, declarative & idempotent from commit #1. |51| Secrets management ⟳ | `tokens-taxonomy` | 1 token per purpose, least privilege, centralized vault strategy. Whenever secrets/credentials involved. |5253### Phase 3 — Build54| Skill | invoke | why here |55|---|---|---|56| Test-driven development | `superpowers:test-driven-development` | Test-first for every feature/bugfix. |57| Parallel execution ⟳ | `superpowers:dispatching-parallel-agents` | When executing a plan with independent tasks that can run in parallel. |58| Documentation | `docs-as-code` | Code without docs isn't done. Mandatory per session. |59| Version control discipline | `git-pr-rules` | Pull requests always, never direct local merge into main. Non-negotiable. |60| Version numbering | `version-bump-rules` | Every shipped change bumps version (semver). |61| Excellence principle ✦ | `excellence-no-intermediates` | Never present "good enough for MVP / polish later" as a valid option. Excellence is binary. |62| Instrumentation ⟳ | `observability-when-to-add` | Add observability only with confirmed pain; follow industry standards (OpenTelemetry, structured logging). |63| Data completeness ⟳ | `large-payload-completeness` | When fetching/importing large datasets, verify no silent truncation. |64| External integrations ⟳ | *(API/SDK/service-specific skill if available)* | When integrating third-party APIs, services, or external data sources. |65| Data quality ⟳ | *(manual QA checklist if no dedicated skill)* | Before shipping analysis or data-driven features, validate methodology, accuracy, and bias. |66| Deep research ⟳ | `deep-research` | Multi-source, fact-checked research when ground truth is unclear or claim needs verification. |6768### Phase 4 — Tracking & close69| Skill | invoke | why here |70|---|---|---|71| Executive tracking ⟳ | *(PROGRESS.md if product/business project, otherwise optional)* | Dashboard tracking for product projects; phase tracking for multi-phase builds. |72| Ledger updates | `superpowers:verification-before-completion` or `ledger-auto-updates` | CHANGELOG + session-handoff at end of every substantive session. |7374## Legend75- ✦ = behavioral rule applied for the whole session (not a Skill-tool call).76- ⟳ = consult when its context appears; if not applicable, mark the todo "N/A — <reason>". Never silent-skip.7778## Note on overlaps7980Some skills in this checklist may overlap intentionally (e.g., planning skills, review skills). Treat them81as complementary: if running one already satisfied the need, mark the other's todo done with a one-line82note "covered by [previous skill]" rather than invoking both.8384## Runtime availability caveat8586Some runtimes or projects may not have every referenced skill installed. If an exact identifier is missing:8788- Mark the todo "N/A — skill unavailable in this runtime"89- If the skill covers something critical (e.g., `git-pr-rules` for version control), apply a manual90 checklist for that discipline instead.91- For specialized skills (e.g., database migration, API design), if the tool is missing and the topic92 is not relevant to the project, mark "N/A — not applicable".9394This caveat keeps the aggregator enforceable without pretending unavailable tools were invoked.9596## Scope9798Use for:99- New projects or repositories100- New non-trivial features in existing projects101- Major refactors or phase kickoffs102- "Let's build X from scratch" requests103104Skip for:105- Trivial one-off edits or documentation tweaks106- Emergency ops or urgent hotfixes107- Merely executing an already-approved plan (the standard was already applied when the plan was made)108- Routine maintenance or CI/CD fixes109110## Why this exists111112Auto-triggering of individual skills is unreliable because:113- Context windows vary; a skill may not see its trigger.114- Work flows may skip a phase (e.g., "just write the API, no business validation") and auto-trigger never fires.115- Silent skips are harder to detect than a visible unchecked todo.116117This aggregator makes the entire standard **enforceable** through explicit invocation and a visible checklist.
avizmarlon