@rune-kit/rune 2.3.3 → 2.6.0

package/docs/VERSIONING.md

@@ -1,91 +0,0 @@
-# Versioning Policy
-
-> **H2 Document** — Semver policy for Rune core and L4 extension packs.
-
----
-
-## Core Plugin Versioning
-
-The Rune plugin uses semantic versioning (`MAJOR.MINOR.PATCH`):
-
-| Version | When to bump | Example |
-|---------|-------------|---------|
-| **PATCH** (`1.0.N`) | Bug fixes, content corrections in SKILL.md | Fixing a wrong command in `verification`, correcting a Sharp Edge |
-| **MINOR** (`1.N.0`) | New features, new connections, new sections added | Adding a new `## Done When` condition, new mesh connection |
-| **MAJOR** (`N.0.0`) | Breaking change to skill interface or output contract | Renaming a skill, changing output format structure, removing a section |
-
-**Current version:** `1.0.0` (H1 complete — 40 skills, full mesh, all constraints)
-
----
-
-## What Counts as a Breaking Change?
-
-A breaking change is any modification that would cause a **calling skill to fail or produce incorrect output** without code changes on its end.
-
-### Breaking (MAJOR bump required)
-- Renaming a skill (e.g., `sentinel` → `security-guard`)
-- Changing the structure of `## Output Format` in a way callers depend on
-- Removing a section that callers parse (e.g., removing `## Calls`)
-- Changing skill layer assignment (L2 → L3 changes invocation context)
-- Removing an existing connection from `## Calls` or `## Called By`
-
-### Non-breaking (MINOR or PATCH)
-- Adding new skills (MINOR)
-- Adding new connections (MINOR)
-- Adding `## Sharp Edges`, `## Done When`, or documentation content (PATCH)
-- Fixing incorrect commands or examples (PATCH)
-- Clarifying constraint wording without changing behavior (PATCH)
-- Updating `## Cost Profile` estimates (PATCH)
-
----
-
-## Skill API Stability Contract
-
-Each skill's **stable API** consists of:
-1. Skill name (used in `## Calls` references across the mesh)
-2. `## Output Format` structure (the contract for calling skills)
-3. Layer assignment (L1/L2/L3)
-4. Required input parameters (documented in `## Executable Steps`)
-
-Everything else (Sharp Edges, Done When, Cost Profile, wording improvements) is non-API and can change freely.
-
----
-
-## L4 Extension Pack Versioning
-
-L4 packs version independently of the core. Each `PACK.md` has its own `metadata.version`.
-
-L4 packs start at `0.1.0` (experimental). When stable:
-- `1.0.0` = skill interface is locked, callers can rely on output format
-- Minor bumps = new skills added to pack (additive, non-breaking)
-- Major bumps = skill renamed, removed, or output format changed
-
-**L4 packs MUST NOT change their mesh connection interface (how they connect to L1-L3 core) in a patch release.** Connection changes are at minimum a minor version bump.
-
----
-
-## Version in SKILL.md Frontmatter
-
-Every `SKILL.md` has a `metadata.version` field:
-
-```yaml
-metadata:
-  version: "0.2.0"
-```
-
-This tracks the individual skill's version, independent of the plugin version. Use it to:
-- Track which skills have been updated in a release
-- Help users identify if their cached version is outdated
-- Signal to CI that a skill's contract changed
-
-**Convention:** When the plugin bumps MAJOR, all skill versions bump to match (e.g., all skills go to `1.0.0`). For MINOR/PATCH, only the modified skills bump.
-
----
-
-## Changelog
-
-| Version | Date | Summary |
-|---------|------|---------|
-| `0.1.0` | 2026-01-15 | Initial release — 36 core skills (Waves 0-4) |
-| `0.2.0` | 2026-02-10 | Add perf, db, incident, design skills. Behavioral constraints. HARD-GATE pattern. |
-| `1.0.0` | 2026-02-25 | H1 complete — 40 skills, Sharp Edges + Done When on all skills, 0 broken mesh connections |

package/docs/VISION.md

@@ -1,263 +0,0 @@
-# Rune Vision
-
-> **"Less skills. Deeper connections."**
->
-> This document is the primary decision-making compass for Rune.
-> When in doubt about a design direction, a new feature, or a skill addition — consult this file first.
-> Last updated: 2026-03-14
-
----
-
-## 1. Why Rune Exists
-
-The problem is not that developers lack AI tools. The problem is that AI tools behave like interns with amnesia — capable, but stateless, siloed, and unable to hand work off cleanly.
-
-Three specific failures motivated Rune:
-
-**Failure 1: Isolation.** Most skill ecosystems are collections, not systems. 500+ skills exist that don't know each other. When `debug` finds a root cause, nothing hands that diagnosis to `fix`. The developer becomes the integration layer — which defeats the purpose of AI tooling.
-
-**Failure 2: Fragility.** Pipeline-based tools (A→B→C) break at every seam. If B fails, everything stops. There's no mesh, no alternative path, no resilience. One broken step means starting over.
-
-**Failure 3: Amnesia.** Each session starts from zero. The AI re-discovers conventions, re-reads the codebase, re-asks questions that were answered two sessions ago. Context dies at the end of every conversation.
-
-**Rune's insight:** the value is in the connections, not the nodes. A mesh of 40 well-connected skills outperforms 500 isolated ones. Resilience comes from redundant paths. Memory comes from structured persistence. The goal is not to give developers more AI tools — it's to give them an AI that behaves like a senior engineer who was actually there last week.
-
----
-
-## 2. What Rune Is
-
-Rune is a **skill mesh** — not a skill collection, not a pipeline, not an AI agent framework.
-
-**Technical definition:**
-
-> **Rune = 59 skills × 200+ bidirectional connections × cross-session memory × multi-platform compiler**
-
-All three components are equally essential:
-- Remove connections → becomes a collection (The Bloat wins)
-- Remove memory → becomes a stateless chatbot
-- Remove skills → nothing remains
-
-**Rune operates on mesh principles:**
-- Every skill knows who to call when it hits the edge of its scope
-- When a skill fails, the mesh finds an alternate path — it does not stop
-- Skills pass structured output to each other; the developer is not the integration layer
-- Context flows in one direction: L1 holds the full picture, L2 gets a relevant slice, L3 gets a minimal query
-
-**Rune serves the complete development lifecycle:** idea → design → code → quality → deploy → rescue. Not a tool for one phase. A system for all of them.
-
-**The mesh is the product.** A new skill that doesn't increase connection density is not a Rune skill — it's a feature that happens to live in the same repo.
-
----
-
-## 3. What Rune Is NOT
-
-*This is where The Bloat gets defeated.*
-
-**The Bloat** is the persistent temptation to add features that seem useful in isolation but erode Rune's identity as a mesh. The Bloat speaks in reasonable-sounding arguments: *"users would love this"*, *"it only takes 50 lines"*, *"it's just one more skill."* The Bloat is not wrong about usefulness. It is wrong about what Rune is for.
-
-### Anti-Goals
-
-**Rune is NOT a general-purpose AI assistant.**
-`email-writer`, `meeting-summarizer`, `travel-planner` — these are not development lifecycle skills. They don't connect to the mesh. A user asking Rune to write an email has the wrong mental model of what Rune is. We do not want to correct that mental model by adding email skills; we want to reinforce the correct one.
-
-**Rune is NOT a skill marketplace.**
-More skills ≠ more value. The benchmark is not "how many skills does Rune have?" It is "what is the average connection depth of each skill?" A skill with 0 inbound and 0 outbound connections is a dead node. Dead nodes dilute the mesh.
-
-**Rune is NOT an IDE or code editor.**
-Rune does not manage files directly, run terminal sessions, or provide a UI. It operates through Claude Code's existing tooling. Rune extends Claude's reasoning — it does not replace the environment.
-
-**Rune is NOT a replacement for the developer.**
-Rune amplifies developer judgment, not replaces it. `cook` presents a plan and waits for approval before writing code. `brainstorm` proposes options, not decisions. The developer remains in the loop at every consequential step. Rune without a developer at the helm is half a system.
-
-**Rune is NOT a pipeline.**
-`cook` is not a rigid A→B→C→D sequence that fails if one step breaks. It's a mesh-orchestrated workflow where each phase can invoke any skill needed, retry via alternatives, and skip phases that don't apply. If someone tries to build a Rune skill as a strict sequential pipeline with no branching — they've misunderstood the architecture.
-
-**Rune is NOT trying to cover every programming language or domain at the core layer.**
-That's what L4 extension packs are for. The core (L1-L3) is language-agnostic. Domain specifics (React patterns, Rust idioms, trading algorithms) belong in L4. Adding language-specific logic to L1-L3 is scope creep disguised as helpfulness.
-
----
-
-## 4. Design Principles
-
-These are the rules that govern every decision in Rune — skill design, connection design, naming, layer assignment, model selection. When two options conflict, these principles break the tie.
-
-### P1 — Connection Density Over Feature Count
-
-Every new skill must increase the total mesh connection density, not just add a node. Before adding a skill, count its inbound + outbound connections. A skill with fewer than 2 connections is a dead node.
-
-**Test:** *"If I remove this skill, how many workflows break?"* If the answer is zero, the skill should not exist.
-
-### P2 — Structured Output Is a Contract
-
-Skills communicate through structured, predictable output formats — not natural language summaries. A skill's `## Output Format` section is a contract with callers. Changing it is a breaking change. Natural language output that cannot be parsed by a calling skill is a design failure.
-
-**Test:** *"Can `cook` consume this skill's output without re-reading the context?"* If no, fix the output format.
-
-### P3 — Fail Loud, Route Around
-
-When a skill fails, it must fail loudly (specific error, not silent empty output) so the mesh can route around it. Silent failures are the most dangerous failure mode — the calling skill proceeds with incomplete data.
-
-**Test:** *"If this skill returns nothing, does the caller know something went wrong?"* If no, add explicit error output.
-
-### P4 — Layer Discipline Is Non-Negotiable
-
-L3 utilities do not call L1 or L2. L1 orchestrators do not implement business logic directly — they delegate to L2. This is not a suggestion; it's what makes the mesh predictable. Violating layer discipline for "just this one case" introduces coupling that spreads.
-
-**Test:** *"Is this skill calling something above its layer?"* If yes, restructure. No exceptions.
-
-### P5 — The Mesh Is More Valuable Than Any Single Skill
-
-No skill is indispensable. If a skill consistently causes issues (wrong model, bad output format, poor connections), replace or remove it. Protecting a skill because it was hard to build is The Bloat thinking. The mesh's health matters more than any individual node.
-
-**Test:** *"Would removing this skill and re-routing its callers make the mesh stronger?"* If yes, remove it.
-
-### P6 — Constraints Block Rationalization
-
-Behavioral constraints (MUST/MUST NOT rules) exist to prevent the most common AI failure mode: rationalization. The AI will always find a reason to skip a step, abbreviate a check, or declare success without verification. Constraints don't suggest — they block. If a constraint can be argued away, it is not a constraint; it's a guideline.
-
-**Test:** *"Can the AI talk itself out of following this constraint?"* If yes, rewrite it to be more specific.
-
-### P7 — Cost Is a Feature
-
-Model selection is a design decision, not an afterthought. Haiku for scans. Sonnet for code. Opus for architecture and security. Using opus for a file glob is waste. Using haiku for a security audit is negligence. Every skill's `## Cost Profile` is a design constraint, not documentation.
-
-**Test:** *"Is this skill using the cheapest model that can do the job correctly?"* If not, downgrade.
-
----
-
-## 5. The Skill Addition Filter
-
-*Use this checklist every time a new skill is proposed — by the team, by users, or by an AI session that thinks "we should add X."*
-
-A proposed skill must pass **all 5 gates** to be added to the core mesh (L1-L3). L4 extension packs have a lighter filter (gates 1 and 5 only).
-
-### Gate 1 — Lifecycle Fit
-> Does this skill serve the software development lifecycle?
-
-The skill must fit one of these phases: planning, coding, testing, reviewing, deploying, monitoring, rescuing. If it primarily serves a non-development task (communication, content, business ops), it belongs outside Rune's core — possibly as a user's private skill.
-
-❌ **Fail example:** `slack-notifier` — communication, not development
-✅ **Pass example:** `audit` — project health assessment, fits the quality phase
-
-### Gate 2 — Connection Requirement
-> Does this skill have ≥2 meaningful mesh connections (inbound + outbound combined)?
-
-A skill must either call at least one existing skill OR be called by at least two existing skills — and ideally both. Connections must be meaningful (actual data flow), not ceremonial.
-
-❌ **Fail example:** `code-formatter` — no inbound, no outbound, pure L3 with 0 connections
-✅ **Pass example:** `audit` — calls `sentinel`, `dependency-doctor`, `autopsy`, `scout`, `journal`; called by `cook`, `launch`
-
-### Gate 3 — Non-Redundancy
-> Can this skill's function be achieved by composing 2 existing skills?
-
-If yes, add a new workflow to an existing skill instead of creating a new one. Rune's philosophy is deepening connections in existing skills before adding new nodes.
-
-❌ **Fail example:** `quick-security-check` — just `sentinel` with fewer checks; redundant
-✅ **Pass example:** `audit` — orchestrates multiple skills into a unified 7-phase report; not achievable by a single existing skill
-
-### Gate 4 — Layer Assignment
-> Is the correct layer assignment clear and unambiguous?
-
-If it's unclear whether the skill should be L1, L2, or L3 — that's a signal the skill's scope is not well-defined yet. Clarify the scope first.
-
-L3 if: stateless, single-purpose, no orchestration
-L2 if: workflow with multiple steps, may call other skills
-L1 if: full lifecycle orchestration, user-facing entry point
-
-### Gate 5 — The Removal Test
-> If this skill is removed in 6 months, does the mesh lose something irreplaceable?
-
-This test separates essential skills from convenience features. If the skill's absence could be worked around trivially, it's not core.
-
-❌ **Fail example:** `git-log-formatter` — convenience wrapper; absence has no workflow impact
-✅ **Pass example:** `sentinel` — no other skill provides security scanning; its absence leaves a critical gap
-
----
-
-## 6. Roadmap Horizons
-
-Rune operates on three time horizons. The roadmap is intentionally non-prescriptive about dates — Rune is a solo/small-team project and date-driven roadmaps create pressure to ship The Bloat.
-
-### H1 — Consolidation ✅ COMPLETE
-
-**Goal:** Make the existing skills excellent before adding more.
-
-- Deepen mesh connections: audit every skill's `## Calls` and `## Called By` for accuracy
-- Harden behavioral constraints: identify constraints that can be rationalized away and rewrite them
-- Validate L4 extension packs: ensure all 12 packs have complete, executable `PACK.md` files
-- Publish to Claude Code plugin marketplace
-
-**Constraint:** No new L1-L3 core skills until Consolidation is complete. L4 packs are allowed.
-
-### H2 — Ecosystem ✅ COMPLETE
-
-**Goal:** Make Rune extensible by others without compromising the core mesh.
-
-- Community L4 extension packs: documented contribution process, review criteria
-- Plugin versioning: semver for skill APIs so callers don't break on updates
-- Skill testing framework: automated validation of mesh connections and output format contracts
-- `rune:onboard` generates project-specific L4 suggestions based on detected stack
-
-**Constraint:** Core mesh (L1-L3) is frozen at ≤49 skills. Growth happens in L4.
-
-### H3 — Intelligence ✅ COMPLETE
-
-**Goal:** Make the mesh self-aware and self-improving.
-
-- ✅ Mesh analytics: `metrics-collector` hook captures skill invocations, `post-session-reflect` flushes to `.rune/metrics/`, `audit` Phase 8 surfaces insights via `/rune metrics`
-- ✅ Adaptive routing: `skill-router` Step 0 reads `.rune/metrics/routing-overrides.json`, `cook` Phase 8 auto-generates overrides from failure patterns
-- ✅ Skill performance metrics: `skills.json` tracks invocations, phase outcomes, quality gate results, debug loops per skill
-- ✅ Community skill sharing: `/rune pack install/list/remove/create` commands, `validate-pack.js` script, `COMMUNITY-PACKS.md` guide, `onboard` discovers installed packs
-
-**Implementation**: Zero new L1-L3 skills added. 1 new hook (`metrics-collector`), 3 modified hooks, 4 extended skills (`audit`, `cook`, `skill-router`, `onboard`), 2 new commands (`/rune metrics`, `/rune pack`).
-
-**Constraint:** Core mesh expanded to 59 skills (v2.1.0+). Further growth happens in L4 and community packs.
-
----
-
-## 7. Success Metrics
-
-*Rune is successful when these are true. Not when the feature list is long.*
-
-### Mesh Health
-- **Connection density** ≥ 3.0 connections/skill (currently: 3.4 at 200+ connections / 59 skills) — do not let this drop below 2.5
-- **Dead nodes** = 0 — every skill has ≥1 inbound and ≥1 outbound connection
-- **Max chain depth used** < 6 in practice (ceiling is 8) — if chains regularly hit 8, the mesh needs restructuring
-- **Bloat Index** = 0.00 — dead nodes / total skills
-
-### Behavioral Quality
-- **Constraint coverage** = 100% — every skill has a `## Constraints` section
-- **HARD-GATE consistency** — all hard gates use `<HARD-GATE>` XML format, none can be silently bypassed
-- **Output format coverage** = 100% — every skill has a structured `## Output Format`
-
-### Developer Experience
-- A developer can go from `/rune onboard` to first working feature with `/rune cook` in one session
-- A developer can pick up work across sessions with zero manual context re-loading (`.rune/` handles it)
-- The most common workflows (`cook`, `debug`, `rescue`) work without reading any documentation
-
-### The Bloat Index
-*This is the most important metric.*
-
-> **Bloat Index = dead nodes / total skills**
-
-Target: **0.00**. If any skill has 0 inbound AND 0 outbound connections, it is dead weight. Review quarterly and remove or reconnect.
-
----
-
-## Appendix: The Bloat's Greatest Hits
-
-*A record of feature requests and ideas that The Bloat has whispered — and why they were rejected.*
-
-| Proposal | The Bloat's argument | Why rejected |
-|----------|---------------------|--------------|
-| `code-formatter` | "Devs always need formatting" | 0 mesh connections. Use the project's existing linter instead. |
-| `email-writer` | "Devs write emails about their code all the time" | Not a development lifecycle task. Wrong product category. |
-| `quick-fix` | "Sometimes `fix` is overkill" | Redundant. Use `fix` with a narrow scope. Don't duplicate skills. |
-| `explain-code` | "Junior devs need code explained" | Claude's base capability handles this. No mesh value added by wrapping it in a skill. |
-| `changelog-generator` | "Every project needs changelogs" | `journal` + `session-bridge` + a git log command covers this. Non-core. |
-
-*When The Bloat returns with a new proposal — and it will — add it here with the rejection reason. This log is part of the VISION.*
-
----
-
-*This document is a living compass, not a frozen spec. Update it when Rune's direction genuinely shifts — not to justify a decision already made.*

package/docs/assets/demo-subtitles.srt

@@ -1,215 +0,0 @@
-1
-00:00:00,000 --> 00:00:04,000
-You're debugging for the 4th time.
-Claude keeps suggesting the same fix.
-
-2
-00:00:04,000 --> 00:00:06,500
-Same loop. Same frustration.
-
-3
-00:00:06,500 --> 00:00:08,000
-What if your AI assistant had a
-structured workflow that actually worked?
-
-4
-00:00:08,000 --> 00:00:12,000
-This is Rune — a 57-skill mesh
-that turns your AI coding assistant
-
-5
-00:00:12,000 --> 00:00:15,000
-from a chatbot into
-an engineering team.
-
-6
-00:00:15,000 --> 00:00:18,000
-It works on Claude Code, Cursor,
-Windsurf, and Antigravity.
-
-7
-00:00:18,000 --> 00:00:20,000
-Let me show you.
-
-8
-00:00:20,000 --> 00:00:22,000
-Install takes 10 seconds.
-
-9
-00:00:22,000 --> 00:00:27,000
-claude plugin install rune-kit/rune
-
-10
-00:00:27,000 --> 00:00:30,000
-57 skills loaded.
-
-11
-00:00:30,000 --> 00:00:34,000
-For Cursor or Windsurf, one command
-compiles all skills into your IDE's format.
-
-12
-00:00:34,000 --> 00:00:40,000
-npx --yes @rune-kit/rune init
---platform cursor
-
-13
-00:00:40,000 --> 00:00:44,000
-First thing — let Rune
-understand your project.
-
-14
-00:00:44,000 --> 00:00:47,000
-/rune onboard
-
-15
-00:00:47,000 --> 00:00:52,000
-Rune scans your codebase, detects
-your stack, and creates context files
-
-16
-00:00:52,000 --> 00:00:57,000
-that persist across sessions.
-No more re-explaining your project.
-
-17
-00:00:57,000 --> 00:01:00,000
-Now let's debug.
-
-18
-00:01:00,000 --> 00:01:04,000
-Users report login returns 401
-for valid credentials.
-
-19
-00:01:04,000 --> 00:01:08,000
-/rune debug "login returns 401
-for valid credentials"
-
-20
-00:01:08,000 --> 00:01:14,000
-Rune's debug skill traces the code path,
-finds the root cause —
-
-21
-00:01:14,000 --> 00:01:18,000
-an expired JWT secret rotation —
-and hands it to fix.
-
-22
-00:01:18,000 --> 00:01:22,000
-Fix writes the code change.
-Verification runs automatically.
-
-23
-00:01:22,000 --> 00:01:26,000
-Lint pass. Typecheck pass.
-Tests pass.
-
-24
-00:01:26,000 --> 00:01:30,000
-Fixed. Verified. One command.
-
-25
-00:01:30,000 --> 00:01:34,000
-Now let's build something.
-Add Stripe billing to our SaaS app.
-
-26
-00:01:34,000 --> 00:01:40,000
-/rune cook "add Stripe subscription
-billing with plan management"
-
-27
-00:01:40,000 --> 00:01:46,000
-Cook activates: scout scans the codebase,
-detects the @rune/saas extension pack.
-
-28
-00:01:46,000 --> 00:01:50,000
-Plan creates implementation steps.
-
-29
-00:01:50,000 --> 00:01:56,000
-See that? Before writing a single line
-of code, Rune's adversary skill
-
-30
-00:01:56,000 --> 00:02:00,000
-red-teams the plan. Found a missing
-webhook security check.
-
-31
-00:02:00,000 --> 00:02:04,000
-Plan updated. User approves.
-
-32
-00:02:04,000 --> 00:02:08,000
-Test writes failing tests first.
-TDD from the start.
-
-33
-00:02:08,000 --> 00:02:12,000
-Fix implements the code.
-Preflight, sentinel, and review
-
-34
-00:02:12,000 --> 00:02:15,000
-run quality checks in parallel.
-
-35
-00:02:15,000 --> 00:02:19,000
-8 phases. TDD. Security scan.
-Code review.
-
-36
-00:02:19,000 --> 00:02:22,000
-All orchestrated automatically.
-
-37
-00:02:22,000 --> 00:02:26,000
-This isn't a list of
-independent tools. It's a mesh.
-
-38
-00:02:26,000 --> 00:02:30,000
-When debug can't find the cause,
-it escalates to problem-solver.
-
-39
-00:02:30,000 --> 00:02:34,000
-When cook hits a wall 3 times,
-it pivots to brainstorm.
-
-40
-00:02:34,000 --> 00:02:38,000
-When sentinel finds a vulnerability,
-it blocks the commit.
-
-41
-00:02:38,000 --> 00:02:42,000
-57 skills. 200+ connections.
-They talk to each other
-
-42
-00:02:42,000 --> 00:02:45,000
-so you don't have to.
-
-43
-00:02:45,000 --> 00:02:48,000
-Rune is free and open source.
-MIT license.
-
-44
-00:02:48,000 --> 00:02:52,000
-claude plugin install rune-kit/rune
-
-45
-00:02:52,000 --> 00:02:55,000
-Or for any IDE:
-npx --yes @rune-kit/rune init
-
-46
-00:02:55,000 --> 00:03:00,000
-Less skills. Deeper connections.
-Link in description.