---
name: avizmarlon/new-project
source: https://app.decimal.ai/s/avizmarlon-new-project@1/SKILL.md
source_sha256: 53ae81562e69
---

# 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.
2. **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.
3. **"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.
4. **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.