@rune-kit/rune 2.7.0 → 2.10.0

package/skills/graft/references/challenge-framework.md

@@ -0,0 +1,98 @@
+# Challenge Framework
+
+5-dimension evaluation gate. Score each dimension before grafting code into your project.
+
+## Scoring
+
+| Score | Meaning | Action |
+|-------|---------|--------|
+| ✅ Pass | No concerns | Proceed |
+| ⚠️ Warn | Minor concerns | Proceed with documented caveats |
+| ❌ Fail | Blocking concern | Requires user override or blocks graft |
+
+**Decision matrix**: 0 ❌ → PROCEED. 1 ❌ → WARN + require explicit user override. 2+ ❌ → BLOCK.
+
+## Dimensions
+
+### 1. License Compatibility
+
+| Source License | Your Project MIT | Your Project Apache-2.0 | Your Project GPL |
+|---------------|-----------------|------------------------|-----------------|
+| MIT | ✅ | ✅ | ✅ |
+| Apache-2.0 | ✅ | ✅ | ✅ |
+| BSD-2/3 | ✅ | ✅ | ✅ |
+| ISC | ✅ | ✅ | ✅ |
+| GPL-2.0/3.0 | ❌ | ❌ | ✅ |
+| AGPL | ❌ | ❌ | ⚠️ |
+| SSPL/BSL | ❌ | ❌ | ❌ |
+| No license | ❌ | ❌ | ❌ |
+| Unlicense | ✅ | ✅ | ✅ |
+
+**Check**: Read LICENSE file in repo root. If missing → ❌ (no license = all rights reserved).
+
+### 2. Stack Fit
+
+| Scenario | Score |
+|----------|-------|
+| Identical stack (same framework + language + version) | ✅ |
+| Same language, different framework (React→Svelte) | ⚠️ — port mode recommended |
+| Same framework, major version gap (Next 13→15) | ⚠️ — API changes likely |
+| Different language entirely (Python→TypeScript) | ❌ — port is a rewrite |
+| Incompatible paradigm (OOP→FP, REST→GraphQL) | ❌ — fundamental rethink needed |
+
+### 3. Scope
+
+| Scenario | Score |
+|----------|-------|
+| ≤5 files, ≤500 LOC | ✅ — manageable |
+| 6-15 files, 500-2000 LOC | ⚠️ — consider narrowing |
+| >15 files or >2000 LOC | ❌ — too broad, must narrow scope |
+| Feature has clear boundaries (self-contained module) | ✅ bonus |
+| Feature is deeply entangled with source codebase | ❌ — extraction risk high |
+
+### 4. Quality
+
+| Signal | Score |
+|--------|-------|
+| Has tests with >60% coverage | ✅ |
+| Has tests but minimal | ⚠️ |
+| No tests | ❌ |
+| TypeScript strict / fully typed | ✅ bonus |
+| Uses `any` extensively or untyped | ⚠️ |
+| Well-documented (JSDoc, README for module) | ✅ bonus |
+| No documentation | ⚠️ |
+| Known anti-patterns (mutations, god classes, deep nesting) | ⚠️ — improve mode recommended |
+
+**Composite**: ≥2 ✅ signals → ✅. 1 ✅ + warnings → ⚠️. No tests + untyped → ❌.
+
+### 5. Maintenance
+
+| Signal | Score |
+|--------|-------|
+| Last commit < 3 months ago | ✅ |
+| Last commit 3-12 months ago | ⚠️ |
+| Last commit > 12 months ago | ❌ |
+| Active issues being addressed | ✅ |
+| 50+ open issues, no response | ⚠️ |
+| Archived or deprecated | ❌ |
+| Multiple contributors | ✅ |
+| Solo maintainer, inactive | ⚠️ |
+
+**Note**: For compare mode, maintenance is informational only — not blocking.
+
+## Presentation Format
+
+```markdown
+## Challenge Gate Results
+
+| # | Dimension | Score | Detail |
+|---|-----------|-------|--------|
+| 1 | License | ✅ | MIT — compatible with your MIT project |
+| 2 | Stack Fit | ⚠️ | React 18 → React 19 — minor API changes |
+| 3 | Scope | ✅ | 4 files, ~350 LOC — well-scoped |
+| 4 | Quality | ✅ | Typed, 12 tests, documented |
+| 5 | Maintenance | ⚠️ | Last commit 5 months ago, but stable |
+
+**Verdict**: PROCEED with caveats (0 ❌, 2 ⚠️)
+Caveats: React 18→19 useEffect changes, verify repo still works with latest deps.
+```

package/skills/graft/references/mode-decision.md

@@ -0,0 +1,44 @@
+# Mode Decision Tree
+
+Auto-select the optimal graft mode when user doesn't specify explicitly.
+
+## Decision Flow
+
+```
+1. User wants analysis only? (says "compare", "vs", "analyze")
+   → YES: compare mode
+   → NO: continue
+
+2. Source and local tech stacks match?
+   → NO (different framework/language): port mode (forced)
+   → YES: continue
+
+3. Source code has quality issues? (anti-patterns, no types, no tests)
+   → YES: improve mode (fix issues during graft)
+   → NO: continue
+
+4. User wants exact replica? (says "exact", "as-is", "copy")
+   → YES: copy mode
+   → NO: improve mode (default for same-stack, good-quality)
+```
+
+## Mode Output Contracts
+
+| Mode | Creates Files? | Modifies Files? | Produces Report? | Calls fix? | Calls review? |
+|------|---------------|----------------|-----------------|-----------|--------------|
+| compare | ❌ | ❌ | ✅ comparison report | ❌ | ❌ |
+| copy | ✅ | ⚠️ minimal (imports) | ❌ | ❌ | ❌ |
+| port | ✅ | ✅ | ❌ | ✅ | ❌ |
+| improve | ✅ | ✅ | ❌ | ✅ | ✅ |
+
+## Examples
+
+| Scenario | Auto Mode | Why |
+|----------|-----------|-----|
+| Next.js auth → your Next.js app | improve | Same stack, default to improving |
+| Django REST → FastAPI | port | Different framework, rewrite needed |
+| "How does Stripe handle webhooks in repo X?" | compare | Analysis intent, no code changes |
+| "Copy their date picker component exactly" | copy | User explicitly wants exact replica |
+| Vue component → React project | port | Different framework |
+| Express middleware, has `any` everywhere | improve | Same stack (Node) but quality issues |
+| "Use their testing approach" | compare | Learning intent, not adoption |

package/skills/incident/SKILL.md

@@ -9,6 +9,7 @@ metadata:
   model: sonnet
   group: delivery
   tools: "Read, Write, Edit, Bash, Glob, Grep"
+  listen: incident.detected
 ---
 
 # incident
@@ -22,6 +23,7 @@ Structured incident response for production issues. Follows a strict order: tria
 - `/rune incident "description of what's broken"` — direct user invocation
 - Called by `launch` (L1): watchdog alerts during Phase 3 VERIFY
 - Called by `deploy` (L2): health check fails post-deploy
+- Signal: auto-triggers when `watchdog` emits `incident.detected` — no manual invocation needed
 
 ## Calls (outbound)
 

package/skills/journal/SKILL.md

@@ -8,6 +8,7 @@ metadata:
   model: haiku
   group: state
   tools: "Read, Write, Edit, Glob, Grep"
+  listen: graft.complete
 ---
 
 # journal
@@ -35,6 +36,7 @@ None — pure L3 state management utility.
 - `audit` (L2): save AUDIT-REPORT.md and record health trend entry
 - `incident` (L2): record incident timeline and postmortem
 - `skill-forge` (L2): record skill creation decisions and rationale
+- `graft` (L2): auto-log graft operations — source URL, mode, challenge score, files changed
 
 ## Files Managed
 

package/skills/launch/SKILL.md

@@ -11,6 +11,7 @@ metadata:
   model: sonnet
   group: orchestrator
   tools: "Read, Write, Edit, Bash, Glob, Grep"
+  listen: audit.complete
 ---
 
 # launch
@@ -34,6 +35,7 @@ Orchestrate the full deployment and marketing pipeline. Launch coordinates testi
 - `audit` (L2): pre-launch health check — full 7-phase quality gate
 - `deploy` (L2): push to target platform
 - `incident` (L2): if post-launch health check fails → triage and contain
+- `retro` (L2): post-launch retrospective — what went well, what didn't
 - `browser-pilot` (L3): verify live site screenshots and performance
 - `marketing` (L2): create launch assets (landing copy, social, SEO)
 - `watchdog` (L3): setup post-deploy monitoring

package/skills/marketing/SKILL.md

@@ -3,7 +3,7 @@ name: marketing
 description: Create marketing assets and execute launch strategy. Generates landing copy, social banners, SEO meta, blog posts, and video scripts.
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L2
   model: sonnet
   group: delivery
@@ -31,6 +31,8 @@ Create marketing assets and execute launch strategy. Marketing generates landing
 - `slides` (L3): generate presentation decks for launches and demos
 - `browser-pilot` (L3): capture screenshots for marketing assets
 - L4 extension packs: domain-specific content when context matches (e.g., @rune/content for blog posts, @rune/analytics for campaign measurement)
+- `@rune-pro/growth/content-scorer` (L4 Pro, optional): 5-dimension content quality gate — if available, score all generated copy for AI phrase contamination and humanity
+- `@rune-pro/growth/cro-analyst` (L4 Pro, optional): psychology-driven CRO analysis for landing pages — if available, audit generated landing copy through 7 behavioral lenses
 
 ## Execution Steps
 
@@ -87,8 +89,15 @@ If `marketing/brand-voice.md` already exists → Read it and apply. Do NOT regen
 
 Using product understanding, market research, and **brand voice contract**, produce:
 
+**Anti-AI Copy Rules** (apply to ALL generated copy):
+- NEVER open with "In today's...", "Are you struggling with...", "Have you ever wondered..."
+- NEVER use: "game-changer", "revolutionary", "seamlessly", "leverage", "unlock the power of", "dive deep into", "delve", "robust", "streamline", "cutting-edge"
+- MUST use one of 5 hook types for headlines: Provocative Question, Specific Scenario, Surprising Statistic, Bold Statement, or Counterintuitive Claim
+- MUST include specific numbers, names, or outcomes — not vague claims ("many users love it")
+- If the copy sounds like it was written by a generic AI → rewrite until it has personality
+
 **Hero section**
-- Headline (under 10 words, outcome-focused)
+- Headline (under 10 words, outcome-focused, uses one of the 5 hook types above)
 - Subheadline (1-2 sentences expanding the promise)
 - Primary CTA button text
 
@@ -147,6 +156,41 @@ If the project already has a deployed site or existing pages, run a technical SE
 7. **Sitemap**: Check for `sitemap.xml` or sitemap generation in build config. Flag if missing.
 8. **Robots**: Check for `robots.txt`. Verify it doesn't accidentally block important pages.
 
+**9. Schema Markup**: Check for `application/ld+json` blocks. Recommend adding relevant types:
+
+| Content Type | Schema Type | Key Properties |
+|-------------|-------------|---------------|
+| Product page | `Product` | name, description, offers, review, aggregateRating |
+| Article/Blog | `Article` | headline, author, datePublished, dateModified, image |
+| FAQ section | `FAQPage` | mainEntity[].name, mainEntity[].acceptedAnswer |
+| How-to guide | `HowTo` | name, step[].name, step[].text, totalTime |
+| Organization | `Organization` | name, url, logo, sameAs[] |
+| Breadcrumbs | `BreadcrumbList` | itemListElement[].name, itemListElement[].item |
+| Software | `SoftwareApplication` | name, operatingSystem, applicationCategory, offers |
+| Review | `Review` | itemReviewed, reviewRating, author, reviewBody |
+| Comparison | `ItemList` | itemListElement[] with individual Product/Review schemas |
+| Local biz | `LocalBusiness` | name, address, telephone, openingHoursSpecification |
+
+Use `@graph` pattern to combine multiple schema types on a single page:
+```json
+{
+  "@context": "https://schema.org",
+  "@graph": [
+    { "@type": "Organization", ... },
+    { "@type": "WebPage", ... },
+    { "@type": "BreadcrumbList", ... }
+  ]
+}
+```
+
+**10. Programmatic SEO awareness**: If the site has repeatable content patterns (product listings, city pages, comparison pages), note the opportunity for template-driven SEO pages. Common playbooks:
+- **Templates**: `best [tool] for [persona]` pages across personas
+- **Comparisons**: `[product A] vs [product B]` for all competitor pairs
+- **Locations**: `[service] in [city]` for local reach
+- **Integrations**: `[product] + [integration]` for every supported integration
+
+Flag programmatic SEO opportunities in the audit report. Execution details are in `@rune-pro/growth` pack.
+
 **Output**: SEO Audit Report with pass/fail per check. Save to `marketing/seo-audit.md`.
 
 Fix critical SEO issues (missing titles, broken heading hierarchy) in the implementation plan. Non-critical issues go to `marketing/seo-backlog.md`.

package/skills/mcp-builder/SKILL.md

@@ -3,7 +3,7 @@ name: mcp-builder
 description: Build Model Context Protocol servers from specifications. Generates tool definitions, resource handlers, and test suites for MCP servers in TypeScript or Python (FastMCP).
 metadata:
   author: runedev
-  version: "0.4.0"
+  version: "0.5.0"
   layer: L2
   model: sonnet
   group: creation
@@ -54,6 +54,8 @@ If user provides a detailed spec or existing API docs → extract answers, confi
 
 ### Step 2 — Architecture Design
 
+<MUST-READ path="references/auto-discovery-pattern.md" trigger="when the server has 5+ tools OR multiple API providers — use auto-discovery registry for graceful degradation"/>
+
 Determine server structure based on spec:
 
 **TypeScript (default):**

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
 
 ```
@@ -262,8 +286,6 @@ Every plan output — master plan, phase file, or inline plan — MUST end with
 
 ## Change Stacking (Overlap Detection)
 
-> From OpenSpec (Fission-AI/OpenSpec, 32.8k★): "Dependencies without metadata create phantom coupling."
-
 When producing phase files with wave-based task grouping, every task MUST declare dependency metadata:
 
 ```markdown
@@ -301,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
 
@@ -310,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 |
@@ -337,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
 
@@ -348,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
@@ -366,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 |