@rune-kit/rune 2.8.0 → 2.10.0

package/skills/mcp-builder/references/auto-discovery-pattern.md

@@ -0,0 +1,169 @@
+# Auto-Discovery Tool Registry Pattern
+
+Reference architecture for MCP servers that support partial deployment — tools register automatically at startup, gracefully skipping those with missing API keys.
+
+## Problem
+
+MCP servers with 10+ tools often require 5+ API keys. Requiring ALL keys before the server starts means users can't use any tools until every key is configured. This kills adoption.
+
+## Pattern: Scan → Validate → Register
+
+```
+tools/
+├── web-search/
+│   └── index.ts       # exports: definition, handler, requiredEnvVars
+├── reddit-search/
+│   └── index.ts
+├── youtube-search/
+│   └── index.ts
+└── content-scorer/
+    └── index.ts       # no requiredEnvVars → always available
+```
+
+### Startup Flow
+
+```typescript
+// lib/tool-registry.ts
+import { glob } from 'fs';
+
+interface ToolModule {
+  definition: ToolDefinition;
+  handler: (params: unknown) => Promise<unknown>;
+  requiredEnvVars?: string[];
+}
+
+async function discoverTools(toolsDir: string): Promise<Map<string, ToolModule>> {
+  const registered = new Map<string, ToolModule>();
+  const skipped: string[] = [];
+
+  const toolDirs = await glob(`${toolsDir}/*/index.ts`);
+
+  for (const toolPath of toolDirs) {
+    const mod: ToolModule = await import(toolPath);
+
+    // Check env vars — skip if missing
+    const missing = (mod.requiredEnvVars ?? [])
+      .filter(key => !process.env[key]);
+
+    if (missing.length > 0) {
+      skipped.push(`${mod.definition.name} (missing: ${missing.join(', ')})`);
+      continue;
+    }
+
+    registered.set(mod.definition.name, mod);
+  }
+
+  if (skipped.length > 0) {
+    console.error(`[registry] Skipped ${skipped.length} tools: ${skipped.join('; ')}`);
+  }
+
+  console.error(`[registry] Registered ${registered.size} tools`);
+  return registered;
+}
+```
+
+### Per-Tool Module Contract
+
+```typescript
+// tools/reddit-search/index.ts
+import { z } from 'zod';
+
+export const requiredEnvVars = ['RAPIDAPI_KEY'];
+
+export const definition = {
+  name: 'reddit_search',
+  description: 'Search Reddit posts and comments. Use when researching community sentiment, finding discussions about a topic, or gathering user feedback.',
+  inputSchema: z.object({
+    query: z.string().describe('Search query'),
+    subreddit: z.string().optional().describe('Limit to specific subreddit'),
+    sort: z.enum(['hot', 'top', 'new', 'relevance']).default('relevance'),
+    time_filter: z.enum(['hour', 'day', 'week', 'month', 'year', 'all']).default('month'),
+    limit: z.number().min(1).max(25).default(10),
+  }),
+};
+
+export async function handler(params: z.infer<typeof definition.inputSchema>) {
+  // Implementation...
+}
+```
+
+### Tools Without API Keys (Always Available)
+
+```typescript
+// tools/content-scorer/index.ts — no external dependencies
+export const requiredEnvVars = []; // or omit entirely
+
+export const definition = {
+  name: 'content_scorer',
+  description: 'Score content items by engagement with time-decay. Pure computation, no API calls.',
+  inputSchema: z.object({
+    items: z.array(ContentItemSchema),
+    recency_weight: z.number().default(0.1),
+  }),
+};
+```
+
+## Key Design Rules
+
+### 1. Graceful Degradation (Non-Negotiable)
+- Missing API keys = tool is skipped, NOT a server crash
+- Server MUST boot with 0 API keys configured (local-only tools still work)
+- Log skipped tools to stderr (not stdout — MCP uses stdout for protocol)
+
+### 2. Adding New Tools = Zero Core Changes
+- Create `tools/<name>/index.ts` with the module contract
+- Export `definition`, `handler`, and optionally `requiredEnvVars`
+- Registry auto-discovers at next startup
+
+### 3. Provider Fallback (Optional, Recommended)
+For tools with multiple data sources, support tiered fallback:
+
+```typescript
+export const requiredEnvVars = []; // none required — has fallback chain
+
+export async function handler(params) {
+  // Tier 1: Dedicated API (best quality)
+  if (process.env.GETX_API_KEY) {
+    return await fetchFromGetXAPI(params);
+  }
+  // Tier 2: RapidAPI (good quality, shared key)
+  if (process.env.RAPIDAPI_KEY) {
+    return await fetchFromRapidAPI(params);
+  }
+  // Tier 3: Web search fallback (approximate)
+  return await fetchViaWebSearch(params);
+}
+```
+
+Mark output with `data_source: "api" | "web_search" | "mixed"` so downstream consumers know the reliability level.
+
+### 4. Status Endpoint
+Expose a `server_status` tool (or MCP resource) that reports which tools are active, which are skipped, and why:
+
+```json
+{
+  "registered": ["web_search", "content_scorer", "reddit_search"],
+  "skipped": [
+    { "tool": "youtube_search", "reason": "Missing YOUTUBE_API_KEY" },
+    { "tool": "linkedin_search", "reason": "Missing RAPIDAPI_KEY" }
+  ],
+  "total": 5,
+  "active": 3
+}
+```
+
+## When to Use This Pattern
+
+| Server Type | Use Auto-Discovery? |
+|-------------|-------------------|
+| Single-API wrapper (1-3 tools) | NO — overkill, just require the key |
+| Multi-source aggregator (5+ tools, 3+ APIs) | YES — users rarely have ALL keys |
+| Internal tools (no external APIs) | NO — no env vars to gate on |
+| Plugin system (user adds custom tools) | YES — extensibility is the point |
+
+## Anti-Patterns
+
+- **Crashing on missing keys** — kills adoption for users who only need 2 of 10 tools
+- **Requiring all keys in .env** — users give up during setup
+- **Silent skip without logging** — users don't know why a tool isn't available
+- **Dynamic import without validation** — malformed tool modules crash the entire server

package/skills/plan/SKILL.md

@@ -3,13 +3,13 @@ name: plan
 description: Create structured implementation plans from requirements. Produces master plan + phase files for enterprise-scale project management. Master plan = overview (<80 lines). Phase files = execution detail (<150 lines each). Each session handles 1 phase. Uses opus for deep reasoning.
 metadata:
   author: runedev
-  version: "1.2.0"
+  version: "1.4.0"
   layer: L2
   model: opus
   group: creation
   tools: "Read, Write, Edit, Glob, Grep"
   emit: plan.ready
-  listen: codebase.scanned
+  listen: codebase.scanned, project.onboarded, security.blocked
 ---
 
 # plan
@@ -111,6 +111,7 @@ High-level multi-feature planning — organize features into milestones.
 - `ba` (L2): Requirements Document → plan's primary input (locked decisions, user stories)
 - `scout` (L2): codebase analysis → plan's convention/pattern awareness
 - `neural-memory` (external): past architectural decisions → plan's precedent context
+- `sentinel` (L2): repeated security blocks → plan's constraint awareness for future features
 
 ### Feedback Loops ↻
 
@@ -123,8 +124,12 @@ High-level multi-feature planning — organize features into milestones.
 
 Check for `.rune/features/*/requirements.md` via `Glob`. If a Requirements Document exists (from `rune:ba`), read it — it contains user stories, acceptance criteria, scope, constraints. Do NOT re-gather what BA already elicited.
 
+If `project.onboarded` signal was received, scout output is already available in session context — skip re-invoking scout.
+
 Invoke `rune:scout` if not already done — plans without context produce wrong file paths. Call `neural-memory` (Recall Mode) to surface past architecture decisions before making new ones.
 
+**Feature Map**: Check for `.rune/features.md` via `Glob`. If it exists, read it — understand the existing feature landscape, dependencies, and known gaps BEFORE planning. Cross-reference: does the new feature overlap, conflict with, or depend on existing features? If `.rune/features.md` does not exist, note this — Step 6.5 will create it.
+
 ### Step 2 — Classify Complexity
 
 Determine inline plan vs master + phase files:
@@ -201,6 +206,25 @@ When presenting alternatives (from brainstorm or Step 3), rate each **Completene
 
 Present the **master plan** to user (NOT all phase files). User reviews: phase breakdown, key decisions, risks, completeness scores. Wait for explicit approval ("go", "proceed", "yes") before writing phase files.
 
+### Step 6.5 — Update Feature Map (Always)
+<MUST-READ path="references/feature-map.md" trigger="every plan invocation"/>
+
+After plan approval, update `.rune/features.md`:
+
+**If `.rune/features.md` does NOT exist** (first run):
+1. Reverse-engineer features from scout output — each top-level module = 1 feature
+2. Map inter-feature dependencies from imports and shared types
+3. Assess status per feature (complete, partial, planned)
+4. Generate `.rune/features.md` with Features table, Dependency Graph, Detected Gaps
+
+**If `.rune/features.md` exists** (subsequent runs):
+1. Add or update the current feature's row (status, deps, key files)
+2. Cross-reference: new feature resolves existing gaps? Creates new ones?
+3. Validate dependency graph — flag missing features, orphans, circular deps, dead signals
+4. Write updated `.rune/features.md`
+
+**Skip if**: Inline plan for trivial task (no feature-level impact).
+
 ### Step 7 — Execution Handoff
 
 ```
@@ -299,6 +323,7 @@ When producing phase files with wave-based task grouping, every task MUST declar
 11. MUST include failure scenarios table — what happens when things go wrong
 12. MUST include rejection criteria — explicit "DO NOT" anti-patterns to prevent common mistakes
 13. MUST include cross-phase context — what's assumed from prior phases, what's exported for future
+14. MUST update `.rune/features.md` after every non-trivial plan — feature map is a living artifact
 
 ## Returns
 
@@ -308,8 +333,35 @@ When producing phase files with wave-based task grouping, every task MUST declar
 | Phase files | Markdown | `.rune/plan-<feature>-phase<N>.md` (one per phase) |
 | Feature spec | Markdown | `.rune/features/<name>/spec.md` (Feature Spec Mode only) |
 | Roadmap | Markdown | `.rune/roadmap.md` (Roadmap Mode only) |
+| Feature map | Markdown | `.rune/features.md` (auto-maintained) |
 | Inline plan | Markdown (inline) | Emitted directly for trivial tasks |
 
+## Chain Metadata
+
+Append to plan output when invoked standalone. Suppress when called as sub-skill inside an L1 orchestrator (cook, team, etc.) — the orchestrator emits a consolidated block. See `docs/references/chain-metadata.md`.
+
+```yaml
+chain_metadata:
+  skill: "rune:plan"
+  version: "1.4.0"
+  status: "[DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED]"
+  domain: "[area planned]"
+  files_changed:
+    - "[.rune/plan-*.md files created]"
+  exports:
+    plan_file: "[.rune/plan-<feature>.md path]"
+    phase_count: [N]
+    estimated_complexity: "[low | medium | high]"
+    risk_areas: ["[domains with identified risks]"]
+  suggested_next:
+    - skill: "rune:adversary"
+      reason: "[grounded in plan — e.g., 'Plan touches auth + payments — stress-test assumptions']"
+      consumes: ["plan_file", "risk_areas"]
+    - skill: "rune:cook"
+      reason: "Plan ready for execution"
+      consumes: ["plan_file", "phase_count"]
+```
+
 ## Sharp Edges
 
 | Failure Mode | Severity | Mitigation |
@@ -335,6 +387,8 @@ When producing phase files with wave-based task grouping, every task MUST declar
 | Outcome Block "Next Action" is a list, not one action | LOW | One action only — ambiguity about where to start causes re-analysis and lost context |
 | Overlapping file ownership across parallel phases/streams | HIGH | Change Stacking: every task declares `touches[]` — overlap detection flags same file in 2+ tasks before execution |
 | Missing dependency between tasks that share artifacts | HIGH | Every task declares `provides[]` and `requires[]` — cycle detection + missing dep check before dispatch |
+| New feature planned without checking existing feature map | HIGH | Step 1 reads `.rune/features.md` — catches overlaps, conflicts, and missing dependencies before planning begins |
+| Feature map never created — gaps accumulate silently | MEDIUM | Step 6.5 always runs (create or update) — feature map grows organically with each plan invocation |
 
 ## Self-Validation
 
@@ -346,6 +400,8 @@ SELF-VALIDATION (run before presenting plan to user):
 - [ ] Phase files have ALL Amateur-Proof sections (data flow, code contracts, failure scenarios, rejection criteria)
 - [ ] Locked decisions from BA are reflected in plan — none contradicted or ignored
 - [ ] Every BA requirement has a corresponding Req ID in at least one phase's Traceability Matrix
+- [ ] `.rune/features.md` updated with current feature (or created if first run)
+- [ ] No cross-feature conflicts detected (or flagged to user if found)
 ```
 
 ## Done When
@@ -364,6 +420,8 @@ SELF-VALIDATION (run before presenting plan to user):
 - Self-Validation: all checks passed
 - Outcome Block present in every plan output (master plan, phase files, inline plan)
 - Outcome Block contains: What Was Planned + Immediate Next Action (single action) + How to Measure table
+- `.rune/features.md` created (first run) or updated (subsequent) with current feature
+- Cross-feature dependencies validated — no conflicts or orphans left unaddressed
 
 ## Cost Profile
 

package/skills/plan/references/feature-map.md

@@ -0,0 +1,84 @@
+# Feature Map
+
+Living document that grows with each plan invocation. Provides bird's-eye view of all features, their dependencies, and detected gaps.
+
+## Location
+
+`.rune/features.md` — auto-created on first plan run, updated on every subsequent run.
+
+## Format
+
+```markdown
+# Feature Map
+<!-- Auto-maintained by rune:plan. Do not edit manually. -->
+<!-- Last updated: YYYY-MM-DD -->
+
+## Features
+
+| Feature | Status | Depends On | Consumed By | Key Files | Gaps |
+|---------|--------|-----------|-------------|-----------|------|
+| Auth | ✅ | Database, Email | Dashboard, API | src/auth/* | No 2FA |
+| Dashboard | 🔄 70% | Auth, Analytics | — | src/dashboard/* | No export |
+
+## Dependency Graph
+
+<!-- ASCII or mermaid — keep under 20 lines -->
+Auth ──→ Dashboard
+  │         ↑
+  └──→ API ─┘
+Database ──→ Auth
+
+## Detected Gaps
+
+- [ ] Auth → Payments: dependency missing (payments needs auth but not wired)
+- [ ] Dashboard depends on Analytics but Analytics not in feature map
+- [ ] Email: single consumer — fragile if auth changes notification strategy
+
+## Signals
+
+- [ ] Feature X emits event.Y but no feature listens
+- [ ] Feature Z listens for event.W but no feature emits it
+```
+
+## Feature Detection (First Run)
+
+When `.rune/features.md` does not exist, reverse-engineer from codebase:
+
+1. **Read scout output** — directory structure, modules, entry points
+2. **Identify features** — each top-level module or bounded context = 1 feature
+3. **Map dependencies** — imports between modules, shared types, API calls
+4. **Assess status** — has tests? has docs? complete or partial?
+5. **Write `.rune/features.md`** with detected features
+
+Detection heuristics:
+- `src/<name>/` or `app/<name>/` directories → likely features
+- Route files (pages/, routes/, api/) → user-facing features
+- Shared directories (utils/, lib/, shared/) → NOT features, but dependencies
+- Package.json workspaces → monorepo features
+
+## Feature Update (Subsequent Runs)
+
+When `.rune/features.md` exists, update incrementally:
+
+1. **Read existing map** — current features, deps, gaps
+2. **Check new feature** — does the feature being planned already exist in map?
+   - Yes → update status, deps, gaps
+   - No → add new row
+3. **Cross-reference** — does new feature create/resolve any gaps?
+   - New dependency on existing feature → add to Depends On
+   - New feature fills a gap → mark gap resolved
+   - New feature creates orphan → add to Detected Gaps
+4. **Write updated `.rune/features.md`**
+
+## Gap Detection Rules
+
+| Pattern | Gap Type | Severity |
+|---------|----------|----------|
+| Feature A depends on B, but B not in map | Missing feature | HIGH |
+| Feature A has no consumers (nothing depends on it) | Orphan feature | MEDIUM |
+| Feature A emits signal but nothing listens | Dead signal | MEDIUM |
+| Feature A listens for signal but nothing emits | Missing producer | HIGH |
+| Two features both write to same data store | Write conflict | HIGH |
+| Feature has no tests | Quality gap | MEDIUM |
+| Feature depends on deprecated module | Tech debt | LOW |
+| Circular dependency: A → B → A | Coupling issue | HIGH |

package/skills/preflight/SKILL.md

@@ -3,7 +3,7 @@ name: preflight
 description: Pre-commit quality gate that catches "almost right" code. Goes beyond linting — checks logic correctness, error handling, regressions, and completeness.
 metadata:
   author: runedev
-  version: "0.7.0"
+  version: "0.8.0"
   layer: L2
   model: sonnet
   group: quality
@@ -208,6 +208,7 @@ If a domain hook flags BLOCK, the overall preflight verdict is BLOCK regardless
 | `openapi.*`, `*.graphql`, `*.proto` | API Contract | Breaking changes flagged, version bumped, deprecated fields documented |
 | `docs/policies/*`, `PRIVACY*`, `TERMS*` | Legal/Compliance | No placeholder text, review date current, practice matches policy |
 | `**/billing*`, `**/payment*`, `**/invoice*` | Financial | Decimal precision correct, currency locale-aware, no hardcoded rates |
+| `*.tsx`, `*.jsx`, `*.svelte`, `*.vue`, `components/*` | UI/Frontend | Design token compliance, animation a11y, touch targets, visual hierarchy |
 | `skills/*/SKILL.md`, `extensions/*/PACK.md` | Rune Skill | Frontmatter valid, all required sections present, word count within layer budget |
 | `*.test.*`, `*.spec.*`, `__tests__/*` | Test Quality | No `.skip`/`.only` left in, assertions present (not empty tests), no hardcoded timeouts |
 
@@ -221,6 +222,24 @@ For each detected domain, run its checks on the relevant files in the diff:
 4. **Classify** findings: BLOCK (data loss risk, breaking contract) or WARN (best practice, incomplete)
 5. **Append** to preflight report under `### Domain Quality` section
 
+#### UI/Frontend Domain Checks
+
+When UI/Frontend hook is triggered, run these checks on all `.tsx`/`.jsx`/`.svelte`/`.vue` files in the diff:
+
+| Check | What to Scan | Severity |
+|-------|-------------|----------|
+| **Design token compliance** | Hardcoded colors (`#fff`, `rgb(`, `hsl(`) instead of CSS variables or Tailwind tokens | WARN: "Hardcoded color at {file}:{line} — use design token" |
+| **UI-SPEC drift** | If `.rune/ui-spec.md` exists, compare component decisions (card style, form layout, nav type) against spec | BLOCK: "Component at {file} uses bordered cards but UI-SPEC locks elevated cards" |
+| **Animation accessibility** | Animations/transitions without `prefers-reduced-motion` guard | WARN: "Animation at {file}:{line} missing reduced-motion check" |
+| **Touch target size** | Interactive elements with explicit small sizing (`w-5 h-5`, `p-0.5` on buttons/links) < 44×44px | WARN: "Touch target too small at {file}:{line}" |
+| **Missing states** | Components fetching data without loading/error/empty states | WARN: "Async component at {file} missing [loading|error|empty] state" |
+| **Icon accessibility** | Decorative icons without `aria-hidden="true"`, functional icons without `aria-label` | WARN: "Icon at {file}:{line} missing aria attribute" |
+| **Inline styles** | `style={{` or `style=` attribute usage instead of classes/tokens | WARN: "Inline style at {file}:{line} — use CSS class or Tailwind" |
+| **Font loading** | Custom font imports without `font-display: swap` or Next.js font optimization | WARN: "Font at {file} may cause layout shift — add font-display: swap" |
+| **Placeholder content** | Strings like "Lorem ipsum", "TODO", "placeholder", "test text" in JSX/template | BLOCK: "Placeholder content at {file}:{line} — replace before shipping" |
+
+**Skip if**: Diff contains only test files, config files, or non-UI code (detected by absence of JSX/template syntax).
+
 #### Pack Integration
 
 When a domain pack is installed (e.g., `@rune-pro/finance`, `@rune-pro/legal`), preflight checks the pack's **Hard-Stop Thresholds** table and applies matching rules to staged files. This means:

package/skills/rescue/SKILL.md

@@ -5,7 +5,7 @@ context: fork
 agent: general-purpose
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L1
   model: sonnet
   group: orchestrator
@@ -34,6 +34,7 @@ Legacy refactoring orchestrator for safely modernizing messy codebases. Rescue r
 - `autopsy` (L2): Phase 0 RECON — full codebase health assessment
 - `safeguard` (L2): Phase 1 SAFETY NET — characterization tests and protective measures
 - `surgeon` (L2): Phase 2-N SURGERY — incremental refactoring (1 module per session)
+- `retro` (L2): post-rescue retrospective — capture lessons learned
 - `journal` (L3): state tracking across rescue sessions
 - `plan` (L2): create refactoring plan based on autopsy findings
 - `review` (L2): verify each surgery phase
@@ -424,6 +425,29 @@ Rollback point: git tag rune-rescue-baseline (set in Phase 0)
 | Health score comparison | Inline (Rescue Report) | Baseline vs final autopsy scores |
 | Rescue Report | Markdown (inline) | Emitted at session end (per module and final) |
 
+## Document Ownership
+
+| Scope | Access | Files |
+|-------|--------|-------|
+| **Owns** (read + write) | `RESCUE-STATE.md`, `.rune/rescue-*.md`, git tags (`rune-rescue-*`), refactored source files (one module per session) |
+| **Reads** (never writes) | `CLAUDE.md`, autopsy reports, safeguard test files, `.rune/contract.md` |
+| **Never modifies** | Test files written by `safeguard` (characterization tests are the safety net — rescue reads them, never edits), `compiler/**`, `SKILL.md` files |
+
+Rescue delegates to `surgeon` for actual code changes and `safeguard` for test creation. Rescue owns the orchestration state, not the artifacts.
+
+## Anti-Patterns
+
+Common legacy refactoring failures. These turn "rescue" into "make it worse."
+
+| Anti-Pattern | Why It Fails | Correct Approach |
+|---|---|---|
+| **Big bang refactor** — rewriting everything at once | No rollback path. One bug = entire refactor is broken | One module per session. Commit + verify after each module |
+| **Surgery without safety net** — refactoring before characterization tests exist | No way to verify behavior is preserved. "It compiles" ≠ "it works" | HARD-GATE: safeguard tests must pass BEFORE any surgery begins |
+| **Coupled module surgery** — refactoring two interdependent modules simultaneously | Changes in module A break module B mid-surgery. Neither is stable | One module per session. Stabilize A completely before touching B |
+| **Ignoring the autopsy** — starting refactoring without understanding current health | Fixes symptoms not causes. Wastes effort on low-impact modules | Phase 0 autopsy is mandatory. Surgery queue ordered by impact, not convenience |
+| **Prototype patterns in production** — replacing legacy code with quick-and-dirty rewrites | Creates new legacy. The "rescue" becomes the next rescue target | Apply proven refactoring patterns from autopsy recommendations. Clean code, not fast code |
+| **No rollback point** — surgery without a tagged baseline | If surgery goes wrong, no safe state to return to | `git tag rune-rescue-baseline` before ANY code changes |
+
 ## Sharp Edges
 
 Known failure modes for this skill. Check these before declaring done.

package/skills/retro/SKILL.md

@@ -41,6 +41,8 @@ Retro is ENCOURAGING but CANDID. Every critique is anchored in specific commits,
 
 - `audit` (L2): engineering velocity and health dimension
 - `cook` (L1): optional — after completing a multi-phase feature, suggest retro
+- `rescue` (L1): post-rescue retrospective
+- `launch` (L1): post-launch retrospective
 - User: `/rune retro` direct invocation
 
 ## Data Flow

package/skills/review/SKILL.md

@@ -3,13 +3,13 @@ name: review
 description: Code quality review — patterns, security, performance, correctness. Finds bugs, suggests improvements, triggers fix for issues found. Escalates to opus for security-critical code.
 metadata:
   author: runedev
-  version: "0.6.0"
+  version: "0.8.0"
   layer: L2
   model: sonnet
   group: development
   tools: "Read, Glob, Grep"
   emit: review.complete, review.issues
-  listen: code.changed
+  listen: code.changed, docs.updated
 ---
 
 # review
@@ -204,6 +204,36 @@ Identify gaps in test coverage.
 - If untested code found: call `rune:test` with specific instructions on what to test
 - Flag as HIGH if business logic is untested, MEDIUM if utility code is untested
 
+#### Per-Function Test Gap Analysis
+
+Go beyond "test file exists" — check coverage at function granularity:
+
+1. **Extract changed functions** — from the diff, list every function/method that was added or modified (name + file:line)
+2. **Map to test assertions** — for each changed function, Grep the test file for its name. Count distinct test cases (look for `it(`, `test(`, `describe(` blocks that reference the function)
+3. **Classify gap severity**:
+
+| Function Type | 0 tests | 1 test | 2+ tests |
+|--------------|---------|--------|----------|
+| Business logic (money, auth, state) | BLOCK | WARN: "only happy path" | PASS |
+| Data transform (parse, format, map) | HIGH | PASS | PASS |
+| Event handler (onClick, onSubmit) | MEDIUM | PASS | PASS |
+| Pure utility (string, math, date) | MEDIUM | PASS | PASS |
+
+4. **Output per-function table** in review report:
+
+```
+### Test Gap Analysis
+| Function | File | Tests Found | Verdict |
+|----------|------|-------------|---------|
+| calculateTotal | src/billing.ts:42 | 3 (happy, zero, overflow) | PASS |
+| processRefund | src/billing.ts:89 | 0 | BLOCK — business logic untested |
+| formatCurrency | src/utils.ts:12 | 1 | PASS |
+```
+
+5. **Flag untested edge cases** — for functions with only 1 test, check if the test covers: empty/null input, boundary values, error path. If only happy path → WARN: "only happy path tested for {function}"
+
+**Skip if**: Diff only touches config, docs, styles, or test files themselves.
+
 ### Step 5.5: Two-Stage Review Gate
 
 Separate spec compliance from code quality. Most reviews conflate both — this gate forces the distinction.
@@ -503,6 +533,29 @@ When `cook` or `ship` checks review status: compare review commit hash with curr
 | Composite quality score | Markdown table | inline (when `mode: "scored"`) |
 | Blast radius assessment | Markdown table | inline |
 
+## Chain Metadata
+
+Append to Code Review Report when invoked standalone. Suppress when called as sub-skill inside an L1 orchestrator (cook, team, etc.) — the orchestrator emits a consolidated block. See `docs/references/chain-metadata.md`.
+
+```yaml
+chain_metadata:
+  skill: "rune:review"
+  version: "0.8.0"
+  status: "[DONE | DONE_WITH_CONCERNS]"
+  domain: "[area reviewed]"
+  files_changed: []  # review doesn't change files
+  exports:
+    findings_count: { critical: [N], high: [N], medium: [N], low: [N] }
+    findings:
+      - { severity: "[level]", file: "[path]", line: [N], message: "[issue]" }
+    verdict: "[APPROVE | REQUEST_CHANGES | NEEDS_DISCUSSION]"
+    quality_score: [0-100]  # when mode: "scored"
+  suggested_next:
+    - skill: "rune:fix"
+      reason: "[grounded in findings — e.g., '2 HIGH findings in api/users.ts need remediation']"
+      consumes: ["findings"]
+```
+
 ## Sharp Edges
 
 | Failure Mode | Severity | Mitigation |

package/skills/scaffold/SKILL.md

@@ -33,6 +33,7 @@ Generated projects MUST build and pass tests. A scaffold that produces broken co
 - `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)
+- `skill-forge` (L2): when scaffolded project includes custom skills or plugin structure
 - `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