菜单
Initialize new Darkroom project from a satus or novus starter (NOT the same as native /init which writes CLAUDE.md). Triggers "new darkroom project", "satus", "novus", "scaffold from starter".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dr-init |
| description | Initialize new Darkroom project from a satus or novus starter (NOT the same as native /init which writes CLAUDE.md). Triggers "new darkroom project", "satus", "novus", "scaffold from starter". |
| argument-hint | [project-name] |
Create a new project using a Darkroom starter. Darkroom maintains two:
| Starter | Stack | When to use |
|---|---|---|
| satus | Next.js 16 + App Router + RSC + React 19 | Content-driven sites, SEO-critical, Vercel-friendly, projects that benefit from Server Components / Server Actions |
| novus | React Router 7 + Vite + React 19 | SPA-leaning apps, projects that prefer the loader/action data model, projects without need for RSC, projects deploying to non-Vercel infra |
If the user already specified ("/dr-init satus", "/dr-init novus", "create new react-router project"), use that. Otherwise ask:
Which starter?
- satus (Next.js) — App Router, Server Components, Vercel-optimized
- novus (React Router) — RR7, Vite, classic loader/action model
When the user is unsure, prefer satus for marketing/content sites and novus for app-heavy SPAs.
bunx degit darkroomengineering/satus $ARGUMENTS
cd $ARGUMENTS
bun install
bunx degit darkroomengineering/novus $ARGUMENTS
cd $ARGUMENTS
bun install
Both starters:
name, description..env.example to .env (or .env.local for satus).bun dev.Cmd/Ctrl + O (satus) or Cmd + . / Ctrl + O (novus).s alias@/ path aliass alias~/ path aliasapp/ # Next.js routes
components/ # React components
lib/
├── hooks/ # Custom hooks
├── integrations/ # Third-party clients
├── styles/ # Global CSS, Tailwind
└── utils/ # Pure utilities
app/
├── root.tsx # Root layout
├── routes/ # Route modules (file-based)
└── routes.ts # Optional explicit route config
components/ # React components
hooks/ # Custom hooks
integrations/ # Third-party clients
styles/ # Global CSS, Tailwind
utils/ # Pure utilities
create-next-app / create-react-app — missing Darkroom standardsAfter initialization:
Both satus and novus starters ship Lenis wired up. For non-Darkroom projects needing Lenis setup, see commit history of the retired lenis skill (git log --all -- skills/lenis/).
Lock file edits to one directory for the session — Edit/Write outside it are blocked, not just warned. Use when debugging to stop accidental edits to unrelated code, or to fence a parallel agent to one module. Triggers "freeze edits", "lock editing scope", "restrict edits to", "only edit this folder", "unfreeze", "lift the freeze".
Lighthouse audit + improvement loop until targets met. Triggers "lighthouse", "performance audit", "page speed", "improve scores", "LCP", "CLS", "INP", "core web vitals".
Extremely strict whole-codebase maintainability audit — checks structural quality, 1k-line file sprawl, thin wrappers, leaked logic, spaghetti growth, and dependency freshness + usage quality via context7. Pushes "code-judo" moves that delete whole branches instead of rearranging them. When fixes land, the same pass updates CHANGELOG, MANUAL, and derived schemas so the docs don't drift. Triggers "nuclear review", "thermonuclear review", "thermo-nuclear code quality review", "code judo", "deep code quality audit", "harsh maintainability review", "whole codebase review". Sibling to `/review` (per-diff Darkroom checklist) and `/zero-tech-debt` (rework patch to end-state).
Adversarial whole-repo audits in three goal-spec modes — hunt defects, drift, and dead ends rather than validate. Triggers "adversarial audit", "fable audit", "audit the codebase", "expectation gaps" (codebase mode - correctness, incoherences, affordance mismatches); "audit the docs", "docs audit", "documentation audit", "doc drift" (docs mode - accuracy vs code, inverted pyramid, doc sizing, diagram backlog); "process audit", "audit the workflows", "walk the journeys", "end-to-end audit" (process mode - empirical journey walking, state-machine map, dead ends, re-run semantics). Sibling to /nuclear-review (maintainability + code-judo deletion) - this skill audits whether the system does what it promises, not whether it should exist.
CEO/founder-mode plan review. Stress-tests plans through a product lens. Use when: - User says "ceo review", "founder review", "product review" - User wants to challenge whether they're solving the right problem - User asks "is this the right approach?", "should we even build this?" - Before committing to a large feature or architectural change - User wants to evaluate a plan from a product/business perspective
Local pre-commit review of unstaged/staged diff against the Darkroom quality checklist (TypeScript, React, a11y, perf, security). Also summarizes inbound PR review comments on the active PR. Distinct from native /review which inspects open PRs. Triggers "review my changes", "check this diff", "feedback on this code", "PR comments", "what did reviewers say", "summarize PR feedback", post-implementation self-review before commit.