@rune-kit/rune 2.2.4 → 2.2.6

package/skills/retro/SKILL.md

@@ -0,0 +1,314 @@
+---
+name: retro
+description: Engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with trend tracking. Per-person breakdowns, shipping streaks, and actionable improvements. Use when asked for "retro", "weekly review", "what did we ship", or "engineering retrospective".
+metadata:
+  author: runedev
+  version: "0.1.0"
+  layer: L2
+  model: sonnet
+  group: knowledge
+  tools: "Read, Bash, Glob, Grep"
+---
+
+# retro
+
+## Purpose
+
+Engineering retrospective engine. Analyzes git history, work patterns, and code quality signals to produce actionable retrospectives with per-person breakdowns, shipping streaks, and concrete improvement habits. Fills a gap in the Rune ecosystem — cook builds, review checks, but nothing reflects on HOW the team works.
+
+<HARD-GATE>
+Retro is READ-ONLY. It analyzes and reports — it does NOT modify code, create PRs, or change any files except its own output artifacts (.rune/retros/).
+Retro is ENCOURAGING but CANDID. Every critique is anchored in specific commits, not vague impressions.
+</HARD-GATE>
+
+## Triggers
+
+- `/rune retro` — default 7-day retrospective
+- `/rune retro 24h` — daily standup review
+- `/rune retro 14d` — sprint retro (2 weeks)
+- `/rune retro 30d` — monthly review
+- `/rune retro compare` — current vs previous period side-by-side
+- Called by `audit` (L2) for engineering health dimension
+- Auto-suggest: end of work week (Friday sessions)
+
+## Calls (outbound)
+
+- `scout` (L2): scan codebase for test file counts, project structure
+- `neural-memory` (L3): recall past retro insights for trend comparison
+
+## Called By (inbound)
+
+- `audit` (L2): engineering velocity and health dimension
+- `cook` (L1): optional — after completing a multi-phase feature, suggest retro
+- User: `/rune retro` direct invocation
+
+## Data Flow
+
+### Feeds Into →
+
+- `plan` (L2): retro insights inform future sprint planning (e.g., "fix ratio too high → allocate debugging time")
+- `journal` (L3): retro findings → ADR entries for team patterns
+- `neural-memory` (external): retro insights → persistent cross-session memory
+
+### Fed By ←
+
+- `git` history: commits, authors, timestamps, file changes
+- `.rune/retros/` history: previous retro JSON for trend comparison
+- `neural-memory` (external): past retro insights for pattern recognition
+
+### Feedback Loops ↻
+
+- `retro` ↔ `plan`: retro identifies bottlenecks → plan adjusts estimation and phase sizing → next retro measures improvement
+
+## Execution
+
+### Step 1 — Gather Raw Data
+
+Run these git commands to collect metrics for the specified time window:
+
+```bash
+# Core metrics (run in parallel)
+git log --since="<window-start>" --format="%H|%an|%ae|%aI|%s" --shortstat
+git log --since="<window-start>" --format="%H" --numstat
+git log --since="<window-start>" --format="%aI" # timestamps for session detection
+git log --since="<window-start>" --format="%an" | sort | uniq -c | sort -rn  # per-author
+git shortlog --since="<window-start>" -sn  # author leaderboard
+```
+
+**Time window alignment**: For day/week units, align to midnight: `--since="YYYY-MM-DDT00:00:00"`. This prevents partial-day skew.
+
+**Identify "You"**: `git config user.name` = current user. All others are teammates.
+
+Also gather:
+- Test file count: `find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" | wc -l`
+- `.rune/retros/` for prior retro history (if exists)
+- TODOS.md for backlog health
+
+### Step 2 — Compute Summary Metrics
+
+| Metric | How to compute |
+|--------|---------------|
+| Commits | Count from git log |
+| Contributors | Unique authors |
+| LOC added/removed | Sum from numstat |
+| Test LOC ratio | test files LOC / total LOC changed |
+| Active days | Unique dates with commits |
+| Sessions | Detected via 45-min gap threshold (Step 4) |
+| LOC/session-hour | Total LOC / total session hours |
+| Fix ratio | `fix:` commits / total commits |
+
+### Step 3 — Hourly Activity Histogram
+
+Build an ASCII bar chart showing commit distribution by hour (local timezone):
+
+```
+Hour  Commits
+ 06   ██ 3
+ 07   ████ 7
+ 08   ██████ 12
+ ...
+```
+
+Identify: peak hours, dead zones, bimodal patterns (morning + evening coder).
+
+### Step 4 — Session Detection
+
+Group commits into sessions using a **45-minute gap threshold**:
+
+- Commits within 45 min of each other = same session
+- Gap > 45 min = new session
+
+Classify sessions:
+- **Deep** (50+ min): focused work blocks
+- **Medium** (20-50 min): moderate focus
+- **Micro** (<20 min): quick fixes, drive-bys
+
+### Step 5 — Commit Type Breakdown
+
+Parse conventional commit prefixes and show percentage bar:
+
+```
+feat ████████████████ 45%
+fix  ████████         22%
+ref  ████             11%
+test ████             11%
+docs ██                5%
+chore██                6%
+```
+
+**Flag**: if `fix` ratio > 50% → "High fix ratio suggests reactive mode. Consider investing in test coverage."
+
+### Step 6 — Hotspot Analysis
+
+Top 10 most-changed files in the window:
+
+| File | Changes | Test Coverage |
+|------|---------|--------------|
+| src/auth/login.ts | 8 | ✅ |
+| src/api/users.ts | 6 | ❌ |
+
+**Flag**: files with 5+ changes = **churn hotspot** — candidate for refactoring.
+**Flag**: hotspot files without test coverage = **risk**.
+
+### Step 7 — Focus Score & Ship of the Week
+
+- **Focus Score** = % of commits in top-changed directory. High focus (>60%) = deep work. Low focus (<30%) = context switching.
+- **Ship of the Week** = highest-LOC commit/PR with feat: prefix. Celebrate it.
+
+### Step 8 — Per-Person Breakdown
+
+For each contributor:
+
+**Current user (deepest treatment):**
+- Commits, LOC, areas of focus
+- Commit type mix (builder vs fixer vs maintainer)
+- Session patterns (deep vs micro ratio)
+- Test discipline (% of feat commits with corresponding test commits)
+- Biggest ship
+
+**Teammates (2-3 sentences each):**
+- Summary of work areas and volume
+- **Specific praise** — anchored in actual commits (e.g., "Your auth refactor in 3 commits was surgically clean")
+- **One growth opportunity** — constructive, based on patterns (e.g., "8 of 12 commits were fixes — consider adding tests alongside features")
+
+### Step 9 — Trend Tracking (if prior retros exist)
+
+Read most recent `.rune/retros/*.json`. Compute deltas:
+
+| Metric | Previous | Current | Delta |
+|--------|----------|---------|-------|
+| Commits | 45 | 52 | +15% ↑ |
+| Test ratio | 0.18 | 0.24 | +33% ↑ |
+| Fix ratio | 0.55 | 0.38 | -31% ↓ (improving) |
+| Deep sessions | 8 | 12 | +50% ↑ |
+
+### Step 10 — Shipping Streak
+
+Query full history for consecutive days with at least 1 commit:
+- **Team streak**: any contributor committed
+- **Personal streak**: current user committed
+
+### Step 11 — Save Retro History
+
+Write JSON snapshot to `.rune/retros/{YYYY-MM-DD}.json`:
+
+```json
+{
+  "date": "2026-03-20",
+  "window": "7d",
+  "metrics": {
+    "commits": 52, "contributors": 3, "loc_added": 1850,
+    "loc_removed": 620, "test_ratio": 0.24, "fix_ratio": 0.38,
+    "active_days": 5, "sessions": 14, "deep_sessions": 8
+  },
+  "authors": ["user1", "user2"],
+  "streak": { "team": 12, "personal": 5 },
+  "summary": "Shipped auth overhaul + 3 bug fixes. Test ratio improving."
+}
+```
+
+### Step 12 — Write Narrative Report
+
+Structure (~800-1500 words — concise, not a novel):
+
+1. **Tweetable summary** (1 sentence, <280 chars)
+2. **Summary table** (Step 2 metrics)
+3. **Time & session patterns** (Steps 3-4)
+4. **Shipping velocity** (Step 5 commit types)
+5. **Code quality signals** (Step 6 hotspots, test ratio)
+6. **Focus & highlights** (Step 7)
+7. **Your week** (current user deep dive from Step 8)
+8. **Team breakdown** (Step 8 teammates)
+9. **Top 3 wins** (specific, anchored in commits)
+10. **3 things to improve** (specific, actionable)
+11. **3 habits for next week** (concrete daily practices)
+12. **Trends** (Step 9, if available)
+
+**Tone**: Encouraging but candid. Specific and concrete. Anchored in actual commits, not vague impressions. Every critique paired with a specific suggestion.
+
+## Compare Mode
+
+When invoked as `/rune retro compare`:
+
+1. Compute current period metrics (same as above)
+2. Compute previous same-length period (e.g., if current = 7d, previous = 7d before that)
+3. Side-by-side delta table
+4. Highlight biggest improvements and regressions
+5. Save only current-period snapshot
+
+## Self-Validation
+
+```
+SELF-VALIDATION (run before emitting report):
+- [ ] All metrics computed from actual git data — no assumptions or estimates
+- [ ] Per-person praise is anchored in specific commits (not generic "great work")
+- [ ] Improvement suggestions are actionable (not "write more tests" but "add tests for the 3 hotspot files without coverage")
+- [ ] Retro JSON saved to .rune/retros/ for trend tracking
+- [ ] No code was modified — retro is read-only
+```
+
+## Constraints
+
+1. MUST NOT modify any code — retro is read-only analysis
+2. MUST anchor all observations in specific commits — no vague impressions
+3. MUST include per-person breakdown for teams with 2+ contributors
+4. MUST save JSON snapshot for trend tracking across retros
+5. MUST flag churn hotspots (5+ changes to same file)
+6. MUST flag high fix ratio (>50%) as reactive mode signal
+7. MUST include actionable habits — "test the hotspots" not "write more tests"
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Generic praise not anchored in commits | HIGH | Every praise MUST reference a specific commit or PR — "great auth refactor in 3 commits" not "good job this week" |
+| Vague improvement suggestions | HIGH | "Add tests for src/api/users.ts (6 changes, 0 tests)" not "consider writing more tests" |
+| Counting merge commits as real work | MEDIUM | Use `--no-merges` flag to exclude merge commits from metrics |
+| Timezone skew in hourly histogram | MEDIUM | Convert all timestamps to local timezone before bucketing |
+| Retro on empty window (no commits) | LOW | Detect early and report: "No commits in the last {window}. Nothing to retro." |
+| Discouraging tone for struggling weeks | HIGH | Even bad weeks have wins. Find the smallest positive signal and lead with it |
+
+## Output Format
+
+```
+## Engineering Retro: [date range]
+
+> [tweetable summary]
+
+### Summary
+| Metric | Value |
+|--------|-------|
+| Commits | N |
+| ...     | ... |
+
+### [remaining sections per Step 12]
+
+### Top 3 Wins
+1. [specific win anchored in commit]
+2. [specific win]
+3. [specific win]
+
+### 3 Things to Improve
+1. [specific, actionable]
+2. [specific, actionable]
+3. [specific, actionable]
+
+### 3 Habits for Next Week
+1. [concrete daily practice]
+2. [concrete daily practice]
+3. [concrete daily practice]
+```
+
+## Done When
+
+- All git metrics gathered for specified time window
+- Summary metrics computed (commits, LOC, test ratio, fix ratio, sessions)
+- Per-person breakdown with specific praise and growth areas
+- Top 3 wins and 3 improvements identified (commit-anchored)
+- Retro JSON saved to `.rune/retros/` for trend tracking
+- Narrative report emitted
+- No code was modified
+
+## Cost Profile
+
+~3000-5000 tokens input (git history parsing), ~2000-4000 tokens output (narrative). Sonnet for analysis quality. Runs infrequently (weekly/sprint cadence).

package/skills/sentinel/SKILL.md

@@ -3,7 +3,7 @@ name: sentinel
 description: Automated security gatekeeper. Blocks unsafe code before commit — secret scanning, OWASP top 10, dependency audit, permission checks. A GATE, not a suggestion.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.4.0"
   layer: L2
   model: sonnet
   group: quality
@@ -150,14 +150,43 @@ app.post('/users', async (req, res) => {
 });
 ```
 
-### Step 4 — Permission Check
-Use `Grep` to scan for:
+### Step 4 — Destructive Command Guard
+
+Scan for destructive operations in code AND detect real-time destructive commands during agent execution.
+
+**4a. Static scan** — Use `Grep` to scan changed files for:
 - Destructive shell commands in scripts: `rm -rf /`, `DROP TABLE`, `DELETE FROM` without `WHERE`, `TRUNCATE`
 - File operations using absolute paths outside the project root (e.g., `/etc/`, `/usr/`, `C:\Windows\`)
 - Direct production database connection strings (e.g., `prod`, `production` in DB host names)
 
 Destructive command on production path = **BLOCK**. Suspicious path = **WARN**.
 
+**4b. Real-Time Command Guard** (advisory for agent workflows)
+
+When sentinel is invoked by `cook` or `fix`, include this destructive command pattern table in the report. Any skill executing Bash commands SHOULD check against these patterns before execution:
+
+| Pattern | Risk | Action |
+|---------|------|--------|
+| `rm -rf` / `rm -r` / `rm --recursive` | Recursive delete | WARN — confirm target is expected |
+| `DROP TABLE` / `DROP DATABASE` / `TRUNCATE` | Data loss | BLOCK — require explicit confirmation |
+| `git push --force` / `git push -f` | History rewrite | WARN — confirm branch is correct |
+| `git reset --hard` | Uncommitted work loss | WARN — verify no unsaved changes |
+| `git checkout .` / `git restore .` | Working tree wipe | WARN — verify intent |
+| `kubectl delete` / `docker system prune` | Production impact | BLOCK — require namespace/context confirmation |
+| `chmod 777` / `chmod -R 777` | Permission escalation | WARN — almost never correct |
+
+**Safe exceptions** (do NOT warn):
+- `rm -rf node_modules`, `.next`, `dist`, `__pycache__`, `.cache`, `build`, `.turbo`, `coverage`, `target`
+- `git push --force-with-lease` (safe force push)
+- `docker rm` on explicitly named test containers
+
+**Composable modes** (future — advisory only for now):
+- **Careful mode**: warn before any destructive command (all patterns above)
+- **Freeze mode**: restrict file edits to a specific directory (scope lock)
+- **Guard mode**: careful + freeze combined
+
+> Source: garrytan/gstack v0.9.0 (careful/freeze/guard skills) — real-time command safety, composable with edit scope lock.
+
 ### Step 4.5 — Framework-Specific Security Patterns
 
 Apply only if the framework is detected in changed files:
@@ -265,6 +294,78 @@ Silent continuation past WARN = VIOLATION.
 The calling skill (cook) must present WARNs and wait for acknowledgment.
 ```
 
+### Step 5 — Domain Hook Templates
+
+Generate domain-specific pre-commit hook scripts when requested. These hooks run as git pre-commit hooks and enforce domain-level quality gates BEFORE code enters the repository.
+
+#### Hook Architecture
+
+```
+hooks/
+├── pre-commit-security.sh      # Always — secret scan, OWASP basics (generated by sentinel)
+├── pre-commit-<domain>.sh      # Domain-specific — generated on request
+└── validate-<domain>.py        # Complex validation scripts (Python for portability)
+```
+
+#### Hook Generation Rules
+
+1. **Exit 0 if no relevant files staged** — prevents false positives when committing unrelated changes
+2. **ERRORS block commit** (exit 1) — critical violations that must be fixed
+3. **WARNINGS alert but allow** (exit 0 with stderr) — non-critical issues the developer should review
+4. **List specific files and line numbers** — actionable output, not vague warnings
+5. **Fast execution** (<5 seconds) — hooks that slow down commits get disabled by developers
+
+#### Domain Hook Template
+
+```bash
+#!/usr/bin/env bash
+# Pre-commit hook: <domain> quality gate
+# Generated by rune:sentinel — do not edit manually
+
+STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)
+DOMAIN_FILES=$(echo "$STAGED_FILES" | grep -E '<file-pattern>')
+
+# Exit early if no relevant files staged
+if [ -z "$DOMAIN_FILES" ]; then
+  exit 0
+fi
+
+ERRORS=0
+WARNINGS=0
+
+for file in $DOMAIN_FILES; do
+  # ERROR checks (block commit)
+  # <domain-specific-error-patterns>
+
+  # WARNING checks (alert only)
+  # <domain-specific-warning-patterns>
+done
+
+if [ $ERRORS -gt 0 ]; then
+  echo "❌ $ERRORS error(s) found — commit blocked. Fix before retrying."
+  exit 1
+fi
+
+if [ $WARNINGS -gt 0 ]; then
+  echo "⚠️  $WARNINGS warning(s) found — review recommended."
+fi
+
+exit 0
+```
+
+#### Built-in Domain Hook Patterns
+
+| Domain | File Pattern | ERROR Checks | WARNING Checks |
+|--------|-------------|-------------|----------------|
+| **Schema/API** | `*.graphql`, `*.proto`, `openapi.*` | Breaking field removal, type changes | Deprecated field usage |
+| **Database** | `migrations/*.sql`, `*.migration.*` | DROP TABLE without backup, DELETE without WHERE | Missing rollback script |
+| **Config** | `*.env*`, `*config*`, `tsconfig*` | Secrets in config, strict mode disabled | New env var without docs |
+| **Dependencies** | `package.json`, `requirements.txt`, `Cargo.toml` | Known vulnerable version pinned | Major version bump without changelog |
+| **Legal/Compliance** | `docs/policies/*`, `PRIVACY*`, `TERMS*` | Placeholder text ([Company Name], [Date]) | Review date >12 months old |
+| **Financial** | `**/invoice*`, `**/billing*`, `**/payment*` | Hardcoded prices/rates, missing decimal precision | Currency without locale formatting |
+
+When a pack or skill requests domain hooks (via `sentinel` integration), generate the appropriate hook script using the template above, customized with domain-specific patterns.
+
 ## Output Format
 
 ```
@@ -306,6 +407,10 @@ BLOCKED — 2 critical findings must be resolved before commit.
 | Dependency audit tool missing → silently skipped | LOW | Report INFO "tool not found, skipping" — never skip silently |
 | Stopping after first BLOCK without aggregating all findings | MEDIUM | Complete ALL steps, aggregate ALL findings, then report — developer needs the full list |
 | Missing agentic security scan when .rune/ exists | HIGH | Step 4.7 is mandatory when .rune/ directory detected — never skip |
+| Domain hook too slow (>5s) → developers disable it | MEDIUM | Keep hooks fast — grep-based patterns only, no network calls. Complex validation goes in CI, not pre-commit |
+| Domain hook blocks on test fixtures / mock data | MEDIUM | Check file path context — `test/`, `fixtures/`, `__mocks__/` directories get relaxed rules |
+| Agent runs destructive command without checking pattern table | HIGH | Step 4b: real-time command guard patterns MUST be checked before Bash execution. Safe exceptions prevent false positives on `rm -rf node_modules` |
+| False positive on `rm -rf` in build cleanup scripts | MEDIUM | Safe exceptions list (node_modules, dist, .next, etc.) — build cleanup is NOT destructive |
 
 ## Done When
 

package/skills/skill-forge/SKILL.md

@@ -3,7 +3,7 @@ name: skill-forge
 description: Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.
 metadata:
   author: runedev
-  version: "1.2.0"
+  version: "1.4.0"
   layer: L2
   model: opus
   group: creation
@@ -97,11 +97,13 @@ Follow `docs/SKILL-TEMPLATE.md` format. Required sections:
 | Frontmatter | YES | Name, description, metadata |
 | Purpose | YES | One paragraph, ecosystem role |
 | Triggers | YES | When to invoke |
-| Calls / Called By | YES | Mesh connections |
+| Calls / Called By | YES | Mesh connections (control flow) |
+| Data Flow | YES | Feeds Into / Fed By / Feedback Loops (data flow) |
 | Workflow | YES | Step-by-step execution |
 | Output Format | YES | Structured, parseable output |
 | Constraints | YES | 3-7 MUST/MUST NOT rules |
 | Sharp Edges | YES | Known failure modes |
+| Self-Validation | YES | Domain-specific QA checklist (per-skill, not centralized) |
 | Done When | YES | Verifiable completion criteria |
 | Cost Profile | YES | Token estimate |
 | Mesh Gates | L1/L2 only | Progression guards |
@@ -277,7 +279,72 @@ Wire the skill into the mesh:
 1. **Update `docs/ARCHITECTURE.md`** — add to correct layer/group table
 2. **Update `CLAUDE.md`** — increment skill count, add to layer list
 3. **Add mesh connections** — update SKILL.md of skills that should call/be called by this one
-4. **Verify no conflicts** — new skill's output format compatible with consumers?
+4. **Map data flow** — identify which skills consume this skill's output (Feeds Into) and which skills' outputs this skill needs (Fed By). Look for feedback loops where two skills refine each other's work
+5. **Write Self-Validation** — 3-5 domain-specific checks unique to this skill's output. Ask: "What quality issues can ONLY this skill catch?"
+6. **Verify no conflicts** — new skill's output format compatible with consumers?
+
+### Phase 6.5 — EXTENSION AUTHORING (if building an extension, not a skill)
+
+Extensions augment existing skills with optional capabilities. Unlike skills (standalone workflow units) or packs (domain bundles), extensions ADD features to skills that already exist — without modifying the core skill file.
+
+#### Extension vs Skill vs Pack
+
+| Concept | Purpose | Modifies Core? | Self-contained? |
+|---------|---------|----------------|-----------------|
+| **Skill** | Standalone workflow unit (SKILL.md) | N/A — IS core | Yes |
+| **Pack** | Domain bundle of skills (PACK.md) | No — bundles existing | Yes |
+| **Extension** | Augments existing skill with new capability | No — additive only | Yes — own dir with install/uninstall |
+
+#### Extension Directory Structure
+
+```
+extensions/<extension-name>/
+├── EXTENSION.md           # Manifest: what it extends, how, dependencies
+├── install.sh             # Unix installer (non-destructive MCP merge)
+├── install.ps1            # Windows installer
+├── uninstall.sh           # Clean removal
+├── uninstall.ps1          # Clean removal (Windows)
+├── skills/
+│   └── <skill-name>/
+│       └── SKILL.md       # New skill added by extension
+├── agents/                # Optional subagent definitions
+│   └── <agent-name>.md
+├── references/            # Domain knowledge loaded by extension skills
+│   └── <topic>.md
+├── scripts/               # Executable utilities
+│   └── <script>.py|.sh
+└── docs/
+    └── SETUP.md           # Extension-specific configuration guide
+```
+
+#### EXTENSION.md Manifest
+
+```yaml
+---
+name: "<extension-name>"
+extends: "<target-skill-or-pack>"
+description: "What capability this extension adds"
+requires:
+  - mcp: "<mcp-server-name>"        # Optional: MCP server dependency
+  - skill: "<required-skill-name>"   # Required core skill
+install_method: "non-destructive"    # MUST be non-destructive
+---
+```
+
+#### Extension Rules
+
+1. **Non-destructive install** — extension MUST NOT modify existing skill files. It adds new files alongside.
+2. **Self-contained** — removing the extension directory restores the system to its pre-install state.
+3. **MCP merge** — if the extension adds MCP tools, install script MUST merge into settings.json without overwriting existing entries.
+4. **Fallback graceful** — if the MCP server or external dependency is unavailable, the extension skill MUST degrade gracefully (report unavailability, don't crash).
+5. **Cost awareness** — if the extension calls paid APIs, the extension skill MUST warn before expensive operations and track usage.
+6. **Pre-flight check** — extension skill Step 1 MUST verify dependencies are available before executing.
+
+#### When to Build an Extension (vs a Skill or Pack)
+
+- Build an **extension** when: the capability requires an external API/MCP, is optional, and augments an existing skill
+- Build a **skill** when: the capability is self-contained and fits a layer in the mesh
+- Build a **pack** when: you're bundling multiple related skills for a domain
 
 ### Phase 7 — SHIP
 
@@ -302,6 +369,8 @@ git commit -m "feat: add [skill-name] — [one-line purpose]"
 - [ ] At least one observed failure documented
 - [ ] Anti-rationalization table from real test failures
 - [ ] Mesh connections bidirectional (calls AND called-by both updated)
+- [ ] Data flow mapped (Feeds Into / Fed By / Feedback Loops)
+- [ ] Self-Validation has 3-5 domain-specific checks (not generic)
 - [ ] Output format is structured and parseable by other skills
 
 **Architecture:**
@@ -311,6 +380,14 @@ git commit -m "feat: add [skill-name] — [one-line purpose]"
 - [ ] ARCHITECTURE.md updated
 - [ ] CLAUDE.md updated
 
+**Extension-specific (if building an extension):**
+- [ ] EXTENSION.md manifest present with extends, requires, install_method
+- [ ] install.sh + install.ps1 tested (non-destructive merge)
+- [ ] uninstall.sh + uninstall.ps1 tested (clean removal)
+- [ ] Extension skill has dependency pre-flight check (Step 1)
+- [ ] Fallback behavior documented when external dependency unavailable
+- [ ] Cost warning present if extension calls paid APIs
+
 ## Adapting Existing Skills
 
 When editing, not creating:
@@ -368,6 +445,8 @@ Techniques:
 ### Mesh Impact
 - New connections: [count] ([list of skills])
 - Bidirectional check: PASS | FAIL
+- Data flow mapped: [count] feeds-into, [count] fed-by, [count] feedback loops
+- Self-Validation: [count] domain-specific checks written
 ```
 
 ## Constraints
@@ -393,6 +472,9 @@ Techniques:
 | Code blocks in SKILL.md bloat every invocation | HIGH | WHY vs HOW split: SKILL.md ≤10-line code blocks, extract rest to references/ |
 | Writing skill without TDD (no observed failures first) | CRITICAL | Skill TDD: RED (run scenario WITHOUT skill → document failures) → GREEN (write skill targeting failures) → REFACTOR (find bypasses → add blocks) |
 | Description leaks workflow → agent skips full content | HIGH | CSO Discipline: description = triggers only. Test: can you execute from description alone? If yes, it leaks too much |
+| Self-Validation copies completion-gate checks | HIGH | Self-Validation is DOMAIN-specific: "assertions per test", "dependency ordering". NOT generic: "tests pass", "build succeeds" — those belong to completion-gate |
+| Data Flow confused with Calls | MEDIUM | Calls = runtime invocation (skill A calls skill B). Feeds Into = artifact persistence (skill A writes .rune/X.md, skill B reads it later). If it's a direct function call → Calls. If it's via files/context → Data Flow |
+| Feedback Loop missing one direction | MEDIUM | Every Feedback Loop ↻ must document BOTH directions: what A sends to B AND what B sends back to A. One-way = Feeds Into, not a loop |
 
 ## Done When