@rune-kit/rune 2.2.3 → 2.2.6

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.2.0"
+  version: "0.3.0"
   layer: L2
   model: sonnet
   group: quality
@@ -158,6 +158,52 @@ Verify that new code ships complete:
 
 If any completeness item is missing, flag as **WARN** with: what is missing, which file needs it.
 
+### Step 4.5 — Domain Quality Hooks
+
+Apply domain-specific quality checks based on detected file types in the diff. These extend the generic completeness checks in Step 4 with deeper domain validation.
+
+<HARD-GATE>
+Domain hooks are additive — they add checks, never remove generic ones from Steps 1-4.
+If a domain hook flags BLOCK, the overall preflight verdict is BLOCK regardless of other steps.
+</HARD-GATE>
+
+#### Hook Selection (auto-detect from diff)
+
+| Detected Pattern | Domain Hook | Key Checks |
+|-----------------|-------------|------------|
+| `migrations/*.sql`, `*.migration.*` | Database | Rollback script present, no bare DROP/DELETE, migration tested |
+| `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 |
+| `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 |
+
+#### Domain Hook Execution
+
+For each detected domain, run its checks on the relevant files in the diff:
+
+1. **Identify** which domain hooks apply based on changed file patterns
+2. **Load** domain-specific check rules (inline above, or from pack reference files if a pack is installed)
+3. **Scan** each relevant file for domain violations
+4. **Classify** findings: BLOCK (data loss risk, breaking contract) or WARN (best practice, incomplete)
+5. **Append** to preflight report under `### Domain Quality` section
+
+#### 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:
+- Installing `@rune-pro/finance` automatically adds financial quality gates to preflight
+- Installing `@rune-pro/legal` automatically adds compliance checks to preflight
+- No manual configuration needed — pack presence = hooks active
+
+#### Output Section
+
+```
+### Domain Quality
+- **Domains detected**: [Database, Financial]
+- `migrations/003-add-billing.sql` — BLOCK: DROP TABLE without rollback script
+- `src/billing/invoice.ts:42` — WARN: price calculation uses `toFixed(2)` instead of `Intl.NumberFormat`
+```
+
 ### Step 5 — Security Sub-Check
 Invoke `rune:sentinel` on the changed files. Attach sentinel's output verbatim under the "Security" section of the preflight report. If sentinel returns BLOCK, preflight verdict is also BLOCK.
 
@@ -216,6 +262,9 @@ WARN — 3 issues found (0 blocking, 3 must-acknowledge). Resolve before commit
 | Skipping sentinel sub-check because "this file doesn't look security-relevant" | HIGH | MUST invoke sentinel — security relevance is sentinel's job to determine, not preflight's |
 | Skipping Stage A (spec compliance) when plan is available | HIGH | If cook provides an approved plan, Stage A is mandatory — catches incomplete implementations |
 | Agent modified files not in plan without flagging | MEDIUM | Stage A flags unplanned file changes as WARN — scope creep detection |
+| Domain hooks not triggered when pack is installed | HIGH | Step 4.5 auto-detects file patterns — if pack is installed but hooks don't fire, check file pattern matching |
+| Domain hooks overriding generic checks | HIGH | HARD-GATE: domain hooks are ADDITIVE — they never replace Steps 1-4 |
+| Pack Hard-Stop Thresholds ignored in preflight | MEDIUM | Step 4.5 Pack Integration must read installed pack thresholds — test with each new pack |
 
 ## Done When
 

package/skills/research/SKILL.md

@@ -3,7 +3,7 @@ name: research
 description: Web search and external knowledge lookup. Gathers data on technologies, libraries, best practices, and competitor solutions.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: knowledge
@@ -44,25 +44,51 @@ Generate 2-3 targeted search queries from the research question. Vary phrasing t
 - Secondary: "[topic] best practices 2026" or "[topic] vs alternatives"
 - Tertiary: "[topic] example" or "[topic] tutorial" if implementation detail needed
 
-### Step 2 — Search
+### Step 2 — Search (Minimum 3 Complementary Sources)
 
-Call `WebSearch` for each query. Collect result titles, URLs, and snippets. Identify the top 3-5 most relevant URLs based on:
-- Source authority (official docs, major blogs, GitHub repos)
+<HARD-GATE>
+Every research conclusion MUST be backed by at minimum 3 complementary sources from DIFFERENT source types.
+Single-source conclusions are flagged as `low` confidence regardless of source authority.
+</HARD-GATE>
+
+Call `WebSearch` for each query. Collect result titles, URLs, and snippets. Identify the top 3-5 most relevant URLs prioritizing **source diversity**:
+
+| Source Type | Examples | Why |
+|-------------|----------|-----|
+| **Official docs** | Framework docs, API reference, RFC | Authoritative but may lag behind reality |
+| **Community** | Stack Overflow, GitHub Issues, Reddit | Real-world pain points, edge cases |
+| **Technical blogs** | Dev.to, Medium engineering blogs, personal blogs | Practical experience, tutorials |
+| **Repositories** | GitHub repos, npm packages, example code | Working implementations |
+
+**Selection rules:**
+- Source authority (official docs > major blogs > personal blogs)
 - Recency (prefer 2025-2026)
 - Relevance to the query
+- **Diversity: never select 3+ URLs from the same domain** — spread across source types
+
+> Source: K-Dense claude-scientific-skills (literature-review "minimum 3 complementary databases" pattern), adapted for software research.
 
 ### Step 3 — Deep Dive
 
 Call `WebFetch` on the top 3-5 URLs identified in Step 2. Hard limit: **max 5 WebFetch calls** per research invocation. For each fetched page:
 - Extract key facts, API signatures, code examples
 - Note the source URL and publication date if visible
+- Tag the source type (official/community/blog/repo) for Step 4 triangulation
 
-### Step 4 — Synthesize
+### Step 4 — Synthesize (Triangulation)
 
-Across all fetched content:
-- Identify points of consensus across sources
+Across all fetched content, **triangulate** — don't just aggregate:
+- Identify points of consensus across sources (≥3 sources = strong signal)
 - Flag any conflicting information explicitly (e.g., "Source A says X, Source B says Y")
-- Assign confidence: `high` (3+ sources agree), `medium` (1-2 sources), `low` (single source or unclear)
+- Check if conflicts are temporal (old vs new info) or genuine disagreement
+- Assign confidence using source diversity:
+
+| Confidence | Criteria |
+|------------|----------|
+| `high` | 3+ sources from different types agree |
+| `medium` | 2 sources agree, or 3+ from same type |
+| `low` | Single source, or sources conflict without resolution |
+| `unverified` | No sources found — report this explicitly, NEVER fabricate |
 
 ### Step 5 — Report
 
@@ -108,6 +134,8 @@ Known failure modes for this skill. Check these before declaring done.
 | Reporting conflicting sources without flagging the conflict | HIGH | Constraint: flag conflicting information explicitly, never silently pick one side |
 | Assigning "high" confidence from a single source | MEDIUM | High = 3+ sources agree; 1-2 sources = medium confidence |
 | Exceeding 5 WebFetch calls per invocation | MEDIUM | Hard limit: prioritize top 3-5 URLs from search, fetch only the most relevant |
+| Single-source conclusions presented as fact | HIGH | HARD-GATE: minimum 3 complementary sources from different source types. Single source = `low` confidence |
+| All sources from same domain (e.g., 3 Stack Overflow links) | MEDIUM | Source diversity rule: never 3+ URLs from the same domain. Spread across official/community/blog/repo |
 
 ## Done When
 

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/review/SKILL.md

@@ -380,6 +380,7 @@ LOW       — style inconsistency, naming suggestion, minor refactor opportunity
 | Treating purple/indigo accent as "just a color choice" | MEDIUM | It is a documented AI-generated UI signature — always flag for domain justification |
 | Suggesting "add X" without checking if X is used | MEDIUM | YAGNI pushback: grep codebase for the suggested feature → if uncalled anywhere → respond "Not called anywhere. Remove? (YAGNI)". Valid pushback, not laziness |
 | Adding abstractions "for future flexibility" | MEDIUM | Three similar lines > premature abstraction. Only abstract when there are 3+ concrete callers today |
+| Missing cross-phase integration check at phase boundary | MEDIUM | When reviewing a phase completion: check orphaned exports, uncalled routes, auth gaps, E2E flow continuity. Delegate to completion-gate Step 4.5 |
 
 ## Done When
 

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/sentinel-env/SKILL.md

@@ -3,7 +3,7 @@ name: sentinel-env
 description: Environment-aware pre-flight check. Validates OS, runtime versions, installed tools, port availability, env vars, and disk space BEFORE coding starts. Prevents "works on my machine" failures. Like sentinel but for the environment, not the code.
 metadata:
   author: runedev
-  version: "0.1.0"
+  version: "0.2.0"
   layer: L3
   model: haiku
   group: validation
@@ -111,6 +111,34 @@ Detect and verify tools the project depends on:
 4. **Database tools**: Check if `prisma`, `drizzle`, `alembic`, `django` migrations exist → verify DB client installed
 5. **Build tools**: Check for `turbo.json` (turborepo), `nx.json` (Nx), `Makefile`, etc.
 
+6. **Hard dependencies** — tools the project WRAPS (not just uses as dev dependency):
+   > From CLI-Anything (HKUDS/CLI-Anything, 17.4k★): "The software is a required dependency, not optional."
+
+   Scan for evidence that the project wraps an external tool:
+   - `Grep` for `shutil.which(`, `which `, `command -v ` → project looks up an executable at runtime
+   - `Grep` for `subprocess.run(`, `child_process.exec(`, `Deno.Command(` → project invokes external CLI
+   - `Read` README/docs for "requires X installed" or "depends on X"
+
+   For each detected hard dependency:
+   ```bash
+   # Verify the tool exists on PATH
+   which <tool-name> 2>/dev/null || echo "MISSING: <tool-name>"
+   # If found, check version
+   <tool-name> --version 2>/dev/null
+   ```
+
+   **Verdict:**
+   - Tool found on PATH → PASS (log version)
+   - Tool NOT found → **BLOCK** with clear install instructions per OS:
+     ```
+     [ENV-XXX] Required tool '<tool>' not found on PATH
+       → Debian/Ubuntu: sudo apt install <tool>
+       → macOS: brew install <tool>
+       → Windows: winget install <tool> (or choco install <tool>)
+       → Manual: <download URL if known>
+     ```
+   - This prevents the entire class of "it worked in CI but not locally" failures where `subprocess.run()` silently fails
+
 ### Step 4: Port Availability Check
 
 Detect which ports the project needs and check if they're available:
@@ -210,6 +238,8 @@ For each finding, include a specific remediation command the developer can copy-
 | .env file contains secrets — accidentally logged | CRITICAL | NEVER read .env values, only check key existence via grep for key names |
 | Platform detection wrong — WSL vs native Windows | MEDIUM | Check for WSL explicitly (`uname -r` contains "microsoft") |
 | Over-checking — flagging optional tools as required | MEDIUM | Only check tools evidenced by config files, not speculative |
+| Missing hard dependency — project wraps external CLI but tool not checked | HIGH | Step 3.6: scan for `shutil.which`, `subprocess.run`, `child_process.exec` → verify tool exists on PATH |
+| Hard dep found but wrong version — tool exists but API changed | MEDIUM | Log version for manual review. Version compatibility is project-specific — don't guess |
 
 ## Done When