@rune-kit/rune 2.1.1

package/skills/safeguard/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: safeguard
+description: Build safety nets before refactoring. Creates characterization tests, boundary markers, config freezes, and rollback points.
+metadata:
+  author: runedev
+  version: "0.2.0"
+  layer: L2
+  model: sonnet
+  group: rescue
+  tools: "Read, Write, Edit, Bash, Glob, Grep"
+---
+
+# safeguard
+
+## Purpose
+
+Build safety nets before any refactoring begins. Safeguard creates characterization tests that capture current behavior, adds boundary markers to distinguish legacy from new code, freezes config files, and creates git rollback points. Nothing gets refactored without safeguard running first.
+
+<HARD-GATE>
+Characterization tests MUST pass on the current (unmodified) code before any refactoring starts. If they do not pass, safeguard is not complete.
+</HARD-GATE>
+
+## Called By (inbound)
+
+- `rescue` (L1): Phase 1 SAFETY NET — build protection before surgery
+- `surgeon` (L2): untested module found during surgery
+
+## Calls (outbound)
+
+- `scout` (L2): find all entry points and public interfaces of the target module
+- `test` (L2): write and run characterization tests for the target module
+- `verification` (L3): verify characterization tests pass on current code
+
+## Cross-Hub Connections
+
+- `surgeon` → `safeguard` — untested module found during surgery
+
+## Execution Steps
+
+### Step 1 — Identify module boundaries
+
+Call `rune:scout` targeting the specific module. Ask scout to return:
+- All public functions, classes, and exported symbols
+- All files that import from this module (consumers)
+- All files this module imports from (dependencies)
+- Existing test files for this module (if any)
+
+Use `Read` to open the module entry file and confirm the public interface.
+
+### Step 2 — Write characterization tests
+
+Create a test file at `tests/char/<module-name>.test.ts` (or `.js`, `.py` matching project convention).
+
+Use `Write` to create the characterization test file. Rules for characterization tests:
+- Tests MUST capture what the code CURRENTLY does, not what it should do
+- Include edge cases that currently produce surprising output — test for that actual output
+- Do NOT fix bugs in characterization tests — if the current code returns wrong data, test for that wrong data
+- Cover every public function in the module
+- Include at least one integration test calling the module as an external consumer would
+
+Example structure:
+```typescript
+// tests/char/<module>.test.ts
+// CHARACTERIZATION TESTS — DO NOT MODIFY without running safeguard again
+// These tests capture existing behavior as of: [date]
+
+describe('<module> — characterization', () => {
+  it('existing behavior: [function] with [input] returns [actual output]', () => {
+    // ...
+  })
+})
+```
+
+### Step 3 — Add boundary markers
+
+Use `Edit` to add boundary comments at the top of the module file and at key function boundaries:
+
+```typescript
+// @legacy — rune-safeguard [date] — do not refactor without characterization tests passing
+```
+
+For functions flagged by autopsy as high-risk, add:
+```typescript
+// @do-not-touch — coupled to [module], change both or neither
+```
+
+For planned new implementations, mark insertion points:
+```typescript
+// @bridge — new-v2 will replace this interface
+```
+
+### Step 4 — Config freeze
+
+Use `Bash` to record current config state:
+
+```bash
+mkdir -p .rune
+cp tsconfig.json .rune/tsconfig.frozen.json 2>/dev/null || true
+cp .eslintrc* .rune/ 2>/dev/null || true
+cp package-lock.json .rune/package-lock.frozen.json 2>/dev/null || true
+echo "Config frozen at $(date)" > .rune/freeze.log
+```
+
+This preserves the baseline config so surgery can be verified against it.
+
+### Step 5 — Create rollback point
+
+Use `Bash` to create a git tag:
+
+```bash
+git add -A
+git commit -m "chore: safeguard checkpoint before [module] surgery" --allow-empty
+git tag rune-safeguard-<module>
+```
+
+Replace `<module>` with the actual module name. Confirm the tag was created.
+
+### Step 6 — Verify
+
+Call `rune:verification` and explicitly pass the characterization test file path.
+
+```
+If characterization tests fail on the CURRENT (unchanged) code → STOP.
+Fix the tests to match actual behavior before proceeding.
+Characterization tests MUST pass on current code. This is non-negotiable.
+```
+
+Only after verification passes, declare the safety net complete.
+
+## Output Format
+
+```
+## Safeguard Report
+- **Module**: [module name]
+- **Tests Added**: [count] characterization tests
+- **Coverage**: [before]% → [after]%
+- **Markers Added**: [count] boundary comments
+- **Rollback Tag**: rune-safeguard-[module]
+- **Config Frozen**: [list of files in .rune/]
+- **Hard Gate**: PASSED — all characterization tests pass on current code
+
+### Characterization Tests
+- `tests/char/[module].test.ts` — [count] tests capturing current behavior
+
+### Boundary Markers
+- `@legacy`: [count] files marked
+- `@do-not-touch`: [count] files protected
+- `@bridge`: [count] insertion points marked
+
+### Config Frozen
+- [list of locked config files in .rune/]
+
+### Next Step
+Safe to proceed with: `rune:surgeon` targeting [module]
+```
+
+## Constraints
+
+1. MUST write characterization tests that pass on CURRENT code before any refactoring
+2. MUST NOT proceed to surgery if characterization tests fail — the safety net is broken
+3. MUST cover critical paths identified by autopsy — not just easy-to-test functions
+4. MUST verify tests are meaningful — tests that always pass regardless of code are useless
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Characterization tests that always pass regardless of code (trivial asserts) | CRITICAL | Constraint 4: tests must fail if the module is deleted or its logic is changed |
+| Not covering critical paths identified by autopsy | HIGH | Constraint 3: cover high-risk functions first — autopsy flags which ones |
+| Characterization tests written to "correct" behavior instead of current behavior | HIGH | Tests capture ACTUAL output, including bugs — do not fix behavior in the tests |
+| Skipping config freeze step | MEDIUM | Step 4 is required — baseline config needed for comparison after surgery |
+| No git tag created before declaring safeguard complete | MEDIUM | Tag `rune-safeguard-<module>` must exist before surgery begins |
+
+## Done When
+
+- Module boundaries identified via scout (public functions, consumers, dependencies)
+- Characterization tests written for all public functions
+- Tests PASS on current (unmodified) code — HARD-GATE verified
+- Boundary markers added (@legacy, @bridge, @do-not-touch)
+- Config files frozen to .rune/
+- Git tag `rune-safeguard-<module>` created
+- Safeguard Report emitted with test count, coverage, and rollback tag
+
+## Cost Profile
+
+~2000-5000 tokens input, ~1000-2000 tokens output. Sonnet for test writing quality.

package/skills/sast/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: sast
+description: "Static analysis tool runner. Wraps ESLint, Semgrep, Bandit, Clippy, and language-specific analyzers with unified severity output. Use when deeper code analysis needed beyond pattern matching."
+metadata:
+  author: runedev
+  version: "1.0.0"
+  layer: L3
+  model: haiku
+  group: validation
+  tools: "Read, Bash, Glob, Grep"
+---
+
+# sast
+
+## Purpose
+
+Unified static analysis tool runner. While `sentinel` does regex-based security pattern matching and `verification` runs lint/type/test/build, SAST goes deeper — running dedicated static analysis tools that understand data flow, taint tracking, and language-specific vulnerability patterns.
+
+Sentinel catches obvious patterns (hardcoded secrets, SQL string concat). SAST catches subtle ones (tainted data flowing through 3 function calls to a sink, unsafe deserialization behind a wrapper).
+
+## Triggers
+
+- Called by `sentinel` (L2) when deep analysis needed beyond pattern matching
+- Called by `audit` (L2) during security dimension assessment
+- Called by `cook` (L1) on security-sensitive code (auth, crypto, payments)
+- `/rune sast` — manual static analysis scan
+
+## Calls (outbound)
+
+None — pure runner using Bash for all tools.
+
+## Called By (inbound)
+
+- `sentinel` (L2): deep analysis beyond regex patterns
+- `audit` (L2): security dimension in full audit
+- `cook` (L1): security-sensitive code paths
+- `review` (L2): when security patterns detected in diff
+
+## Execution
+
+### Step 1 — Detect Language and Tools
+
+Use `Glob` to detect project language and available tools:
+
+| Indicator | Language | Primary Tool | Fallback |
+|---|---|---|---|
+| `package.json` | JavaScript/TypeScript | `npx eslint --ext .js,.ts,.tsx` | `npx oxlint` |
+| `tsconfig.json` | TypeScript | `npx tsc --noEmit` + ESLint | — |
+| `pyproject.toml` / `setup.py` | Python | `bandit -r . -f json` | `ruff check --select S .` |
+| `Cargo.toml` | Rust | `cargo clippy -- -D warnings` | `cargo audit` |
+| `go.mod` | Go | `govulncheck ./...` | `go vet ./...` |
+| `.semgrep.yml` / any | Any | `semgrep --config auto` | — |
+
+Check tool availability:
+```
+Bash: command -v <tool> 2>/dev/null
+→ If not installed: mark as SKIP with install instruction
+→ If installed: proceed with scan
+```
+
+### Step 2 — Run Primary Analysis
+
+Run the detected primary tool on changed files (or full project if no diff):
+
+```
+For each available tool:
+  Bash: <tool command> 2>&1
+  → Capture stdout + stderr
+  → Parse output into unified format (see Step 4)
+  → Record: exit code, finding count, execution time
+```
+
+**Tool-specific commands:**
+
+```bash
+# ESLint (JS/TS) — security-focused rules
+npx eslint --no-eslintrc --rule '{"no-eval": "error", "no-implied-eval": "error"}' <files>
+
+# Bandit (Python) — security scanner
+bandit -r <path> -f json -ll  # medium+ severity only
+
+# Semgrep (any language) — pattern-based analysis
+semgrep --config auto --json --severity ERROR --severity WARNING <path>
+
+# Clippy (Rust) — lint + security
+cargo clippy --all-targets -- -D warnings -W clippy::unwrap_used
+
+# govulncheck (Go) — vulnerability check
+govulncheck ./...
+```
+
+### Step 3 — Run Semgrep (If Available)
+
+Semgrep provides cross-language analysis with community rules. Run regardless of primary language tool:
+
+```
+IF semgrep is installed:
+  Bash: semgrep --config auto --json <changed-files-or-project>
+  → Parse JSON output
+  → Map severity: error→BLOCK, warning→WARN, info→INFO
+```
+
+If semgrep is NOT installed, log INFO: "semgrep not installed — install with `pip install semgrep` for deeper cross-language analysis."
+
+### Step 4 — Normalize to Unified Format
+
+Map all tool outputs to unified severity:
+
+```
+BLOCK (must fix):
+  - Bandit: HIGH confidence + HIGH severity
+  - ESLint: error-level security rules
+  - Semgrep: ERROR severity
+  - Clippy: deny-level warnings
+  - govulncheck: any known vulnerability
+
+WARN (should fix):
+  - Bandit: MEDIUM confidence or MEDIUM severity
+  - ESLint: warning-level rules
+  - Semgrep: WARNING severity
+  - Clippy: warn-level suggestions
+
+INFO (informational):
+  - Bandit: LOW severity
+  - Semgrep: INFO severity
+  - Style/convention suggestions
+```
+
+### Step 5 — Report
+
+```
+## SAST Report
+- **Status**: PASS | WARN | BLOCK
+- **Tools Run**: [list with versions]
+- **Tools Skipped**: [list with install instructions]
+- **Files Scanned**: [count]
+- **Findings**: [count by severity]
+
+### BLOCK (must fix)
+- `path/to/file.py:42` — [tool] Possible SQL injection via string formatting (B608)
+- `path/to/auth.ts:15` — [semgrep] JWT token not verified before use
+
+### WARN (should fix)
+- `path/to/utils.py:88` — [bandit] Use of `subprocess` with shell=True (B602)
+
+### INFO
+- `path/to/config.ts:10` — [eslint] Prefer `const` over `let` for unchanging variable
+
+### Tool Coverage
+| Tool | Status | Findings | Duration |
+|------|--------|----------|----------|
+| ESLint | RAN | 2 WARN | 1.2s |
+| Semgrep | SKIPPED | — | — (not installed) |
+| Bandit | N/A | — | — (not Python) |
+```
+
+## Output Format
+
+SAST Report with status (PASS/WARN/BLOCK), tools run, files scanned, findings by severity (BLOCK/WARN/INFO), and tool coverage table. See Step 5 Report above for full template.
+
+## Constraints
+
+1. MUST run all available tools for the detected language — not just one
+2. MUST attempt Semgrep regardless of primary language (if installed)
+3. MUST normalize all outputs to unified BLOCK/WARN/INFO — don't dump raw tool output
+4. MUST show install instructions for missing tools — not silently skip
+5. MUST report which tools ran and which were skipped — transparency
+6. MUST NOT block on missing tools — SKIP with instruction, not FAIL
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Tool not installed → entire scan skipped silently | HIGH | Constraint 4: show install instruction, continue with available tools |
+| Raw tool output dumped without normalization | MEDIUM | Step 4: always normalize to unified format |
+| Only running one tool when multiple apply | MEDIUM | Constraint 1: run ALL available tools for the language |
+| Semgrep community rules producing noise | LOW | Filter to ERROR+WARNING severity only — skip INFO-level Semgrep |
+| Long-running scan on large codebase | MEDIUM | Run on changed files only when diff available, full scan only on manual invocation |
+
+## Done When
+
+- Language detected from project config files
+- All available tools executed (or SKIP with install instruction)
+- Findings normalized to unified BLOCK/WARN/INFO format
+- Tool coverage table showing what ran and what was skipped
+- SAST Report emitted with overall verdict
+
+## Cost Profile
+
+~300-800 tokens input, ~200-500 tokens output. Haiku + Bash commands. Tool execution time varies (1-30s depending on project size).

package/skills/scaffold/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: scaffold
+description: Autonomous project bootstrapper. Generates complete project from a description — structure, code, tests, docs, config. Orchestrates ba → plan → design → fix → test → docs → git in one pipeline. The "0 to production-ready" skill.
+metadata:
+  author: runedev
+  version: "0.1.0"
+  layer: L1
+  model: sonnet
+  group: orchestrator
+  tools: "Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch"
+---
+
+# scaffold
+
+## Purpose
+
+The "zero to production-ready" orchestrator. Takes a project description and autonomously generates a complete, working project — directory structure, code, tests, documentation, git setup, and verification. Orchestrates 8+ skills in sequence to produce output that builds, passes tests, and is ready for development.
+
+<HARD-GATE>
+Generated projects MUST build and pass tests. A scaffold that produces broken code is WORSE than no scaffold. Phase 9 (VERIFY) is mandatory — if verification fails, fix before presenting to user.
+</HARD-GATE>
+
+## Triggers
+
+- `/rune scaffold <description>` — Interactive mode (asks questions)
+- `/rune scaffold express <detailed-description>` — Express mode (autonomous)
+- Called by `team` when task is greenfield project creation
+- Auto-trigger: when user says "new project", "start from scratch", "bootstrap", "create a new [app/api/lib]"
+
+## Calls (outbound)
+
+- `ba` (L2): Phase 1 — requirement elicitation (always, even in Express mode)
+- `research` (L3): Phase 2 — best practices, starter templates, library comparison
+- `plan` (L2): Phase 3 — architecture and implementation plan
+- `design` (L2): Phase 4 — design system (frontend projects only)
+- `fix` (L2): Phase 5 — code generation (implements the plan)
+- `team` (L1): Phase 5 — parallel implementation when 3+ independent modules
+- `test` (L2): Phase 6 — test suite generation
+- `docs` (L2): Phase 7 — README, API docs, architecture doc
+- `git` (L3): Phase 8 — initial commit with semantic message
+- `verification` (L3): Phase 9 — lint + types + tests + build
+- `sentinel` (L2): Phase 9 — security scan on generated code
+
+## Called By (inbound)
+
+- User: `/rune scaffold` direct invocation
+- `team` (L1): when decomposed task is a new project
+- `cook` (L1): when task is classified as greenfield (rare — cook usually handles features, not projects)
+
+## Modes
+
+### Interactive Mode (default)
+
+Full phase-gate workflow. User reviews and approves at each major phase:
+1. BA asks 5 questions → user answers
+2. Plan presented → user approves
+3. Design system presented → user approves (if frontend)
+4. Implementation proceeds
+5. Results presented with full report
+
+### Express Mode
+
+Autonomous mode for detailed descriptions. User provides enough context upfront:
+1. BA extracts requirements from description (no questions asked)
+2. Plan auto-approved (user gave enough detail)
+3. Implementation proceeds autonomously
+4. User reviews only the final output
+
+<HARD-GATE>
+Express mode MUST still validate. Auto-approve doesn't mean skip quality checks.
+BA still extracts requirements — it just doesn't ask questions.
+Verification (Phase 9) is NEVER skipped in any mode.
+</HARD-GATE>
+
+## Project Templates
+
+Auto-detected from BA output. Template selection informs Phase 3 (Plan) architecture decisions.
+
+| Template | Stack | Key Generation Targets |
+|----------|-------|----------------------|
+| REST API | Node.js/Python + DB + Auth | Routes, models, middleware, migrations, Docker, CI |
+| Web App (Full-stack) | Next.js/SvelteKit + DB | Pages, components, API routes, auth, DB setup |
+| CLI Tool | Node.js/Python/Rust | Commands, arg parsing, config, tests |
+| Library/Package | TypeScript/Python | Src, tests, build config, npm/pypi publish setup |
+| MCP Server | TypeScript/Python | Tools, resources, handlers, tests (delegates to mcp-builder) |
+| Chrome Extension | React/Vanilla | Manifest, popup, content script, background, tests |
+| Mobile App | React Native/Expo | Screens, navigation, auth, API client |
+
+## Executable Steps
+
+### Phase 1 — BA (Requirement Elicitation)
+
+Invoke `rune:ba` with the user's project description.
+
+**Interactive Mode**: BA asks 5 questions, discovers hidden requirements, produces Requirements Document.
+
+**Express Mode**: BA extracts requirements from the detailed description without asking questions. Still produces Requirements Document with scope, user stories, and acceptance criteria.
+
+Output: `.rune/features/<project-name>/requirements.md`
+
+Gate: In Interactive mode, user must approve requirements before proceeding.
+
+### Phase 2 — RESEARCH (Best Practices & Templates)
+
+Invoke `rune:research` to find:
+- Best practices for the detected project type
+- Recommended libraries (compare 2-3 options for each concern)
+- Starter templates or skeleton projects to reference
+- Common pitfalls for this stack
+
+Do NOT clone templates blindly. Use them as REFERENCE for architecture decisions in Phase 3.
+
+### Phase 3 — PLAN (Architecture & Implementation)
+
+Invoke `rune:plan` with the Requirements Document from Phase 1 and research from Phase 2.
+
+Plan must include:
+- Directory structure (exact paths)
+- File list with purpose of each file
+- Implementation order (dependency-aware)
+- Technology choices with rationale
+- Test strategy (what to test, coverage target)
+
+Gate: In Interactive mode, user must approve plan before proceeding.
+
+### Phase 4 — DESIGN (Design System — Frontend Only)
+
+If project has frontend (Web App, Mobile App, Chrome Extension):
+- Invoke `rune:design` to generate design system
+- Output: `.rune/design-system.md` with tokens, components, patterns
+
+If backend-only or CLI → skip this phase.
+
+### Phase 5 — IMPLEMENT (Code Generation)
+
+Execute the plan from Phase 3. For each planned file:
+
+1. Create directory structure first
+2. Generate shared types/interfaces
+3. Generate core modules (models, services, utilities)
+4. Generate API layer (routes, controllers, handlers)
+5. Generate UI layer (pages, components) if applicable
+6. Generate configuration (env, docker, CI)
+
+**Parallelization**: If plan has 3+ independent modules → invoke `rune:team` to implement in parallel using worktrees.
+
+**Quality during generation**:
+- Follow project conventions from research
+- Include proper error handling
+- Use environment variables for config (never hardcode)
+- Add TypeScript strict types / Python type hints
+- Follow file size limits (< 500 LOC per file)
+
+### Phase 6 — TEST (Test Suite Generation)
+
+Invoke `rune:test` to generate tests based on acceptance criteria from Phase 1:
+
+- Unit tests for each module/function
+- Integration tests for API endpoints
+- E2E test template for critical flows
+- Target: 80%+ coverage on generated code
+
+Each acceptance criterion from BA → at least one test case.
+
+### Phase 7 — DOCS (Documentation)
+
+Invoke `rune:docs init` to generate:
+
+- `README.md` — Quick Start, Features, Tech Stack, Commands
+- `ARCHITECTURE.md` — if project has 10+ files
+- `docs/API.md` — if project has API endpoints
+- `.env.example` — all required environment variables with descriptions
+
+### Phase 8 — GIT (Initial Commit)
+
+Invoke `rune:git commit` to create initial commit:
+
+- Stage all generated files (except .env, node_modules, __pycache__)
+- Commit message: `feat: scaffold <project-name> with <template> template`
+- Set up `.gitignore` appropriate for the stack
+
+### Phase 9 — VERIFY (Quality Gate)
+
+Invoke `rune:verification` to run ALL checks:
+
+1. **Lint**: ESLint/Ruff/Clippy — zero errors
+2. **Types**: tsc --noEmit / mypy — zero errors
+3. **Tests**: npm test / pytest — all pass
+4. **Build**: npm run build / python -m build — succeeds
+5. **Security**: `rune:sentinel` quick scan — no critical issues
+
+<HARD-GATE>
+If ANY check fails → fix the issue (invoke rune:fix) and re-verify.
+Do NOT present broken scaffold to user.
+Max 3 fix-verify loops. If still failing after 3 → report failures to user with context.
+</HARD-GATE>
+
+## Output Format
+
+```
+## Scaffold Report: [Project Name]
+- **Template**: [detected template]
+- **Stack**: [framework, language, DB, etc.]
+- **Files Generated**: [count]
+- **Test Coverage**: [percentage]
+- **Phases**: BA → Research → Plan → Design? → Implement → Test → Docs → Git → Verify
+- **Verification**: ✅ All checks passed / ⚠️ [issues]
+
+### Generated Structure
+[file tree — max 30 lines, group similar files]
+
+### What's Included
+- [feature list with key implementation details]
+
+### What's NOT Included (Next Steps)
+- [out-of-scope items from BA — things user should build next]
+
+### Commands
+- `[start command]` — start development server
+- `[test command]` — run tests
+- `[build command]` — production build
+- `[lint command]` — check code quality
+```
+
+## Error Recovery
+
+| Phase | Failure | Recovery |
+|-------|---------|----------|
+| Phase 1 (BA) | User refuses to answer questions | Extract what you can, flag assumptions prominently |
+| Phase 2 (Research) | No good references found | Use built-in knowledge, flag as "no external reference" |
+| Phase 3 (Plan) | Plan too complex (10+ phases) | Split into MVP (Phase 1) + Future (Phase 2) |
+| Phase 5 (Implement) | Code generation errors | Invoke fix → retry, max 3 attempts per file |
+| Phase 6 (Test) | Tests fail on generated code | Fix code (not tests) → re-run, max 3 loops |
+| Phase 9 (Verify) | Lint/type/build errors | Fix → re-verify, max 3 loops |
+| Phase 9 (Verify) | Still failing after 3 loops | Report to user with specific failures |
+
+## Constraints
+
+1. MUST run BA (Phase 1) before generating any code — even in Express mode
+2. MUST generate tests — no project without test suite is "production-ready"
+3. MUST generate docs — README at minimum, API docs if applicable
+4. MUST pass verification — generated project must build and pass lint/types/tests
+5. MUST NOT use `--dangerously-skip-permissions` or `--no-verify` — quality gates are mandatory
+6. MUST NOT generate hardcoded secrets — use .env.example with placeholder values
+7. Express mode MUST still extract and validate requirements — auto-approve ≠ skip analysis
+8. MUST generate .gitignore appropriate for the stack
+9. MUST respect user's existing project if scaffolding into non-empty directory — warn and ask before overwriting
+10. Generated files MUST be < 500 LOC each — split large files
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Generating code without BA → wrong features | CRITICAL | Constraint 1: BA is Phase 1, always runs |
+| Scaffold passes locally but fails on fresh clone | HIGH | Phase 9 catches this — verify build from clean state |
+| Overwriting existing files in non-empty directory | HIGH | Constraint 9: detect existing files, warn user |
+| Express mode skipping quality checks | HIGH | HARD-GATE: Express mode still validates everything |
+| Template mismatch (CLI template for web app) | MEDIUM | Template auto-detected from BA output, confirmed with user |
+| Generated tests are trivial (only smoke tests) | MEDIUM | Phase 6: tests derived from acceptance criteria, not generic |
+| Missing .gitignore → committing node_modules | MEDIUM | Constraint 8: generate stack-appropriate .gitignore |
+
+## Done When
+
+- Requirements gathered (BA complete, Requirements Document produced)
+- Architecture planned (directory structure, tech choices, implementation order)
+- Design system generated (if frontend project)
+- All code generated (following plan, < 500 LOC per file)
+- Test suite generated (80%+ coverage target, acceptance criteria covered)
+- Documentation generated (README + ARCHITECTURE + API docs as applicable)
+- Initial git commit created
+- All verification checks passed (lint + types + tests + build + security)
+- Scaffold Report presented to user
+
+## Cost Profile
+
+~10000-20000 tokens total (across all sub-skill invocations). Sonnet for orchestration — sub-skills use their own model selection (ba uses opus, git uses haiku, etc.). Most expensive L1 skill due to 9-phase pipeline, but runs rarely (project creation is infrequent).