rune

Use when starting any creative work — creating features, components, or functionality, modifying behavior, or solving ambiguous problems — before design or implementation. Covers product discovery, competitive research, feature analysis, technical design, and capability spec writing. Applies to every project; routes to writing-plans (non-UI) or design-workflow (UI).

Use when finishing an edit to source files — runs format, typecheck, and console.log detection before moving to the next task.

Use when implementation of a bug fix or feature task is complete — dispatches the appropriate language and global reviewers and returns a binary APPROVE/BLOCK verdict.

Use when about to git commit — validates commit message format, lints staged files, and scans staged content for secrets and debug artifacts.

Use when reaching the design-workflow V2-4 hard gate — adversarially reviews design artifacts (token coverage, contract completeness, artifact consistency, accessibility docs, responsive coverage, DESIGN.md compliance) against docs/designs/<feature>/ before development handoff.

Use when a task involves UI — new pages, components, visual interactions, or design tokens — including work in docs/designs/, *.pen files, or with Pencil MCP tools. Skip for backend-only, config-only, or refactoring without visual impact. Routes to writing-plans on completion.

Use when building Django features involving authentication, authorization, user input, sessions, or deployment — covers CSRF, SQL injection, and XSS prevention plus secure production configuration.

Use when finishing an implementation — syncs documentation to the change by updating specs, catalogs, and design artifact status (finishing-a-development-branch Step 2b).

Use when debugging a bug — root cause must be confirmed before any code change, then TDD (RED→GREEN→IMPROVE) and code review complete the fix.

Use when designing UIs in Pencil (.pen files) or generating production code from Pencil designs — covers Pencil MCP tools, .pen files, and design-to-code workflows, integrating with design-workflow v2 stages.

Use when writing Python — Pythonic idioms, PEP 8, type hints, exception handling, and packaging for robust, maintainable applications.

Use when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment or sensitive features — provides a security checklist and patterns.

Use when writing TypeScript or React — patterns for shadcn/ui conventions, Tailwind v4, hooks, and robust frontend applications.

Use when about to declare an implementation, fix, or quality-gate run complete — run a fresh build/test/lint verification command in the same turn and read its output before stating success.

Use when a workflow needs to write a templated documentation artifact (capability spec, change proposal/specs delta, ADR, design intent/component-contract/token-source-map/layout-report/review-verdict, l1 design note) from prepared structured data, or when reconciling doc indexes (FEATURE-CATALOG, CODEMAP) after a workflow step.

Use when adopting Rune for an existing project — scaffolds docs/ topology, generates codemap (incl. module index), creates feature catalog (incl. component/decision sections) with Pre-Rune entries, writes adoption ADR. One-time setup for brownfield projects.

Use when executing implementation plans with independent tasks. Dispatches a fresh subagent per task with TDD + quality gate + code review. Required after writing-plans skill. Terminal state: invokes finishing-a-development-branch skill.

Use when implementation is complete and all tasks have passed review — verifies tests, applies spec delta + archives docs/changes, presents structured integration options (PR/merge/keep/discard), and cleans up workspace. Required after subagent-driven-development skill. Not for use when tests fail or review has open issues.

Use when you have a spec or requirements for a multi-step task, before touching code. Creates design.md + tasks.md in docs/changes/<feature>/ (technical design + task breakdown). User approval required before implementation.

Use when you have one or more existing GitHub issues to resolve — whether collected via the feedback skill from external users or filed by a maintainer. Verifies each issue against the codebase's actual state, decides whether it is worth fixing, routes implementation to existing workflows, and closes the loop via PR with Closes #N. A thin orchestrator: it delegates design/implementation to existing skills and only owns issue verification, the worth-fixing decision, and PR/merge wiring.

Use when you hit a rune problem worth reporting — a hook false-positive, a skill behaving against its docs, a confusing or bloated workflow step, a misleading doc. Walks through structuring the report, shows each draft for review, and submits via gh issue create only after you explicitly approve that draft. Never auto-submits, never reads session transcript.

Use when starting any conversation or after compact - establishes Rune iron laws, skill invocation rules, and red flags

Use when implementing any feature, bugfix, or refactoring, before writing implementation code

Use when starting subagent-driven-development (Phase 0a) or before executing implementation plans — ensures an isolated workspace exists. Detects existing isolation first, prefers native worktree tools, falls back to `git worktree add` under .claude/worktrees/.

Use when creating new skills or editing existing skills for the Rune skill library — guides skill authoring with CSO optimization, TDD testing methodology, and anti-rationalization patterns

Use when code-review returns BLOCK — processes feedback, deduplicates, classifies, orders, and evaluates pushback before routing to implementer for fixes