@rune-kit/rune 2.2.0 → 2.2.1

package/skills/skill-router/SKILL.md

@@ -4,7 +4,7 @@ description: "Meta-enforcement layer that routes EVERY agent action through the
 user-invocable: false
 metadata:
   author: runedev
-  version: "1.1.0"
+  version: "1.2.0"
   layer: L0
   model: haiku
   group: orchestrator
@@ -64,14 +64,33 @@ Before standard routing, check if adaptive routing rules exist:
 - Model hints are written by cook Phase 8 when debug-fix loops hit max retries on the same error pattern
 - Model hints do NOT override explicit user model preferences
 
+### Step 0.25 — Request Classifier (Fast-Path Filter)
+
+Before intent classification, categorize the request into one of 5 types. This determines the **enforcement level** — how strictly routing must be followed.
+
+| Request Type | Keywords / Signals | Enforcement | Action |
+|---|---|---|---|
+| `CODE_CHANGE` | "build", "implement", "add", "create", "fix", "refactor", "update code" | **FULL** | cook mandatory, no exceptions |
+| `QUESTION` | "what is", "how does", "explain", "why" | **LITE** | Check if a skill has domain knowledge first; answer directly if no skill matches |
+| `DEBUG_REQUEST` | "error", "bug", "not working", "broken", "crash", "fails" | **FULL** | debug skill mandatory |
+| `REVIEW_REQUEST` | "review", "check", "audit", "look at this code" | **FULL** | review skill mandatory |
+| `EXPLORE` | "find", "search", "where is", "show me", "list" | **LITE** | scout if codebase-related; answer directly if general |
+
+**Enforcement levels:**
+- **FULL** → MUST route through a skill. Writing code without skill invocation = protocol violation.
+- **LITE** → SHOULD check if a skill applies. Can answer directly if no skill matches and the response involves no code changes.
+
+**Escape hatch**: If request is clearly trivial (< 5 LOC change, single-line fix, user says "just do it"), classify as CODE_CHANGE but cook activates Fast Mode automatically.
+
 ### Step 0.5 — STOP before responding
 
 Before generating ANY response (including clarifying questions), the agent MUST:
 
-1. **Classify the user's intent** using the routing table below
-2. **Identify which skill(s) match** — if even 1% chance a skill applies, invoke it
-3. **Invoke the skill** via the Skill tool
-4. **Follow the skill's instructions** — the skill dictates the workflow, not the agent
+1. **Check the request type** from Step 0.25 — if FULL enforcement, routing is mandatory
+2. **Classify the user's intent** using the routing table below
+3. **Identify which skill(s) match** — if even 1% chance a skill applies, invoke it
+4. **Invoke the skill** via the Skill tool
+5. **Follow the skill's instructions** — the skill dictates the workflow, not the agent
 
 ### Step 1 — Intent Classification (Progressive Disclosure)
 
@@ -143,7 +162,11 @@ These are rarely invoked directly — they're called by Tier 1/2 skills:
 
 #### Tier 4 — Domain Extension Packs (L4)
 
-When user intent matches a domain-specific pattern or user explicitly invokes an L4 trigger command, route to the L4 pack. The agent reads the pack's PACK.md and follows the matching skill's workflow.
+When user intent matches a domain-specific pattern or user explicitly invokes an L4 trigger command, route to the L4 pack.
+
+**Split pack loading** (context-efficient): First `Read` the pack's PACK.md index. If the index contains `format: split` in its frontmatter metadata, it is a split pack — the index lists skills in a table but skill content lives in separate files under `skills/`. Match user intent to the specific skill name in the table, then `Read` only that skill file (e.g., `extensions/backend/skills/api-design.md`). This loads ~100-200 lines instead of ~1000+.
+
+**Monolith pack loading** (legacy): If no `format: split` marker, the PACK.md contains all skills inline — read it fully and extract the matching `### skill-name` section.
 
 | User Intent / Domain Signal | Route To | Pack File |
 |---|---|---|
@@ -159,13 +182,41 @@ When user intent matches a domain-specific pattern or user explicitly invokes an
 | Three.js, WebGL, game loop, physics | `@rune/gamedev` | `extensions/gamedev/PACK.md` |
 | Blog, CMS, MDX, i18n, SEO | `@rune/content` | `extensions/content/PACK.md` |
 | Analytics, A/B testing, funnels, dashboards | `@rune/analytics` | `extensions/analytics/PACK.md` |
+| Chrome extension, manifest, service worker | `@rune/chrome-ext` | `extensions/chrome-ext/PACK.md` |
+| PRD, roadmap, KPI, release notes, product spec | `@rune-pro/product` | `extensions/pro-product/PACK.md` |
+| Sales outreach, pipeline, call prep, prospecting | `@rune-pro/sales` | `extensions/pro-sales/PACK.md` |
+| Data science, SQL, dashboards, statistical analysis | `@rune-pro/data-science` | `extensions/pro-data-science/PACK.md` |
+| Support tickets, KB, escalation, SLA tracking | `@rune-pro/support` | `extensions/pro-support/PACK.md` |
+| Budget, expense, revenue forecast, P&L, cash flow | `@rune-pro/finance` | `extensions/pro-finance/PACK.md` |
+| Contract review, NDA, compliance, GDPR, IP audit | `@rune-pro/legal` | `extensions/pro-legal/PACK.md` |
 
 **L4 routing rules:**
-1. If user explicitly invokes an L4 trigger (e.g., `/rune rag-patterns`), read the PACK.md and follow the skill workflow directly
+1. If user explicitly invokes an L4 trigger (e.g., `/rune rag-patterns`), read the PACK.md index first, then load only the matching skill file (split packs) or extract the matching section (monolith packs)
 2. If the intent also involves implementation, route to `cook` (L1) first — cook will detect L4 context in Phase 1.5
 3. L4 packs supplement L1/L2 workflows — they are domain knowledge, not standalone orchestrators
 4. L4 packs can call L3 utilities (scout, verification) but CANNOT call L1 or L2 skills
 5. If the L4 pack file is not found on disk, skip silently and proceed with standard routing
+6. **NEVER load an entire split pack** — always load index first, then only the specific skill file needed
+
+### Step 1.5 — File Ownership Matrix (Constraint Inheritance)
+
+When the routed skill produces file changes, the **owner skill's constraints** apply to those files — even if a different skill (e.g., cook) is the orchestrator.
+
+| File Pattern | Owner Skill | Constraints Applied |
+|---|---|---|
+| `*.test.*`, `*.spec.*`, `__tests__/` | `rune:test` | Test patterns, assertions, no `test.skip`, coverage rules |
+| `migrations/`, `schema.*`, `*.prisma` | `rune:db` | Migration safety, rollback script, parameterized queries |
+| `Dockerfile`, `*.yml` (CI/CD), `terraform/` | `rune:deploy` | Deployment checklist, no hardcoded secrets |
+| `docs/*.md`, `README.md`, `CHANGELOG.md` | `rune:docs` | Documentation patterns, no stale references |
+| `SKILL.md`, `PACK.md` | `rune:skill-forge` | Skill template compliance, frontmatter validation |
+| `.env*`, `*secret*`, `*credential*` | `rune:sentinel` | Security scan mandatory, never commit secrets |
+| `*.css`, `*.scss`, `tailwind.config.*` | `@rune/ui` | Design system patterns (if L4 pack installed) |
+
+**Ownership rules:**
+1. Ownership = **constraints apply**, NOT exclusive access. cook can modify test files during Phase 4 as long as test constraints are honored.
+2. If a file matches multiple patterns, ALL matching constraints apply (union, not exclusive).
+3. If no pattern matches, the routed skill's own constraints apply (default behavior).
+4. File ownership is checked DURING implementation, not at routing time — it augments, not replaces, skill routing.
 
 ### Step 2 — Compound Intent Resolution
 
@@ -235,9 +286,22 @@ These DO NOT need skill routing:
 
 ## Output Format
 
+### Routing Proof (Required in Every Code Response)
+
+Every response that involves code changes MUST begin with a routing proof line:
+
+```
+> Routed: rune:<skill> | Type: CODE_CHANGE | Confidence: HIGH
+```
+
+This is NOT optional formatting. It is evidence that routing occurred. If this line is missing from a code response, the response violated skill-router compliance. For LITE enforcement (QUESTION, EXPLORE), the proof line is optional.
+
+### Full Routing Decision (when announcing route)
+
 ```
 ## Routing Decision
 - **Intent**: [classified user intent]
+- **Type**: CODE_CHANGE | QUESTION | DEBUG_REQUEST | REVIEW_REQUEST | EXPLORE
 - **Skill**: rune:[skill-name]
 - **Confidence**: HIGH | MEDIUM | LOW
 - **Override**: [routing override applied, if any]
@@ -278,6 +342,24 @@ For multi-skill chains:
 - Success = every agent response passes through routing check
 - Failure = any code written without skill invocation
 
+## Self-Verification Trigger (MANDATORY)
+
+<HARD-GATE>
+Before EVERY response, complete this 3-point self-check:
+
+1. **Did I classify this request?** (Step 0.25 — what type is it?)
+2. **Did I route through a skill?** (Step 1-2 — which skill handles this?)
+3. **Am I about to write code without a skill invocation?** → **STOP. Route first.**
+
+If the request type is `CODE_CHANGE` or `DEBUG_REQUEST` (FULL enforcement) and ANY answer is "no":
+→ DO NOT RESPOND. Complete routing first.
+
+If the request type is `QUESTION` or `EXPLORE` (LITE enforcement):
+→ Check if a skill has relevant domain knowledge. If yes, route. If no, respond directly.
+
+**User override**: If user explicitly says "skip routing", "just write it", "no process" → respect the override. Log: "User override: routing skipped per explicit request."
+</HARD-GATE>
+
 ## Cost Profile
 
 ~0 tokens (routing logic is internalized from this document). Cost comes from the skills it routes to, not from skill-router itself. The routing table is loaded once and cached in context.

package/skills/team/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: opus
   group: orchestrator
@@ -250,6 +250,29 @@ Error recovery:
     → Present to user for decision before continuing
 ```
 
+**3c. Evaluate subagent status per stream.**
+
+Each cook instance MUST have returned one of four statuses. Team handles them as follows:
+
+| Cook Status | Team Action |
+|-------------|-------------|
+| `DONE` | Stream cleared for merge — proceed normally |
+| `DONE_WITH_CONCERNS` | Stream cleared for merge, BUT trigger **cross-workstream review**: check if the concern impacts any other stream's files or contracts before merging ALL streams. Log concern in Team Report. |
+| `NEEDS_CONTEXT` | Stream paused — present the specific question to user. Resume that stream after answer. Other independent streams may continue in parallel. |
+| `BLOCKED` | Stream blocked from merge. If stream has no dependents → continue with remaining streams and report partial completion. If stream has dependents → STOP all dependent streams, present to user with full blocker details. |
+
+**Cross-workstream review (triggered by any DONE_WITH_CONCERNS)**:
+
+```
+1. Read the concern from the cook report
+2. Check if the concern touches shared contracts, interfaces, or shared files
+   → Use Grep to find the concern's affected symbols/files across all worktrees
+3. If concern is isolated to stream's own files → proceed to merge (concern logged only)
+4. If concern crosses stream boundaries → resolve before merge:
+   → Present to user with: affected streams, concern details, two remediation options
+   → Do NOT merge any stream until user decides
+```
+
 Mark todo[2] `completed`.
 
 ---

package/skills/test/SKILL.md

@@ -144,6 +144,23 @@ After GREEN phase, call `verification` to check coverage threshold (80% minimum)
 - If coverage drops below 80%: identify uncovered lines, write additional tests
 - Report coverage gaps with file:line references
 
+### Phase 6.5: Diff-Aware Mode (optional)
+
+When invoked with `mode: "diff-aware"` or by `cook` after implementation:
+
+1. Run `git diff main --name-only` to get changed files
+2. For each changed file, trace its **blast radius**: what imports it? what routes does it serve? what components render it?
+3. Map changed files → affected routes/endpoints/pages
+4. Prioritize tests: files with most downstream dependents get tested first
+5. Generate targeted test commands that cover ONLY affected paths — skip unchanged modules
+
+This mode is valuable for large codebases where running the full suite is slow. It answers: "what could this diff have broken?"
+
+```
+Input:  git diff main --name-only
+Output: Prioritized test plan targeting only affected paths
+```
+
 ## Test Types
 
 | Type | When | Framework | Speed |
@@ -152,6 +169,7 @@ After GREEN phase, call `verification` to check coverage threshold (80% minimum)
 | Integration | API endpoints, DB operations | supertest/httpx/reqwest | Medium |
 | E2E | Critical user flows | Playwright/Cypress via browser-pilot | Slow |
 | Regression | After bug fixes | Same as unit | Fast |
+| Diff-aware | After implementation, large codebases | Same as unit + integration | Fast (targeted) |
 
 ## Error Recovery
 

package/skills/verification/SKILL.md

@@ -3,7 +3,7 @@ name: verification
 description: "Universal verification runner. Runs lint, type-check, tests, and build. Use after any code change to verify nothing is broken."
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: validation
@@ -98,6 +98,44 @@ If build fails: record first 20 lines of build output, mark as FAIL.
 
 Compile all results into the structured report. Update all TodoWrite items to completed.
 
+### Artifact Verification
+
+> Inspired by CLI-Anything (HKUDS/CLI-Anything, 14.5k★): "Never trust exit 0."
+> Many tools exit 0 even when they fail silently. Always verify ACTUAL output.
+
+After each phase command, verify that the expected artifact or indicator is present:
+
+**Test output** — scan stdout for the pass/fail summary line:
+- Vitest/Jest: look for `X passed`, `X failed` — if neither appears, output is incomplete
+- Pytest: look for `X passed` or `X failed` — exit 0 with no summary = runner crashed silently
+- If only exit code available and no summary line found → mark as INCOMPLETE, not PASS
+
+**Build output** — after `npm run build` / `cargo build` / `go build`:
+- Verify the output file exists: `Glob("dist/**/*.js")` or equivalent
+- Verify file size > 0 bytes: a zero-byte output = silent truncation failure
+- If output directory is missing → FAIL even if command exited 0
+
+**Lint output** — parse stdout for counts, not just exit code:
+- ESLint: look for `X problems (Y errors, Z warnings)` — `0 problems` = PASS
+- Ruff/Flake8: zero output lines = PASS; any file:line output = FAIL
+- If linter exits 0 but output contains `error` keyword → log as suspicious, mark WARN
+
+**Generated files** — check magic bytes for binary outputs:
+- PDF: first bytes must be `%PDF` — use `Bash("head -c 4 file.pdf")`
+- ZIP/XLSX/DOCX: first bytes must be `PK` (ZIP magic) — use `Bash("head -c 2 file.zip")`
+- File size must exceed minimum threshold (PDF > 1KB, ZIP > 100 bytes)
+
+**Type check** — do not trust exit code alone:
+- TypeScript `tsc --noEmit`: look for `Found X errors` or absence of error lines
+- `Found 0 errors` = PASS; any other count = FAIL
+- Empty output from `tsc` = PASS (no errors emitted) — note explicitly
+
+<HARD-GATE name="artifact-verification">
+Verification MUST check actual command output for success indicators, not just exit codes.
+Exit 0 without a confirming output artifact or success string = UNVERIFIED.
+Report the specific line that confirmed success (e.g., "3 passed, 0 failed").
+</HARD-GATE>
+
 ## Error Recovery
 
 - If project type cannot be detected: report "Unknown project type" and skip all checks
@@ -187,6 +225,7 @@ Known failure modes for this skill. Check these before declaring done.
 | Marking check as PASS when the tool isn't installed | MEDIUM | Mark as SKIP (not PASS) — PASS means the tool ran and reported clean |
 | Stopping after first failure instead of running remaining checks | MEDIUM | Run all checks; aggregate all failures so developer can fix everything at once |
 | Reporting PASS when output has warnings but zero errors | LOW | PASS is correct but note warning count — caller decides if warnings matter |
+| Trusting exit code 0 without output verification | CRITICAL | Artifact Verification HARD-GATE: always confirm success indicator in stdout (pass count, "0 errors", output file exists) |
 
 ## Done When