abildtoft
137 verified skills274 total stars
kramme-cc-workflow/evals/skill-review/fixtures/missing-frontmatter
# Triage Support Use this draft to summarize a bug report, inspect likely causes, and suggest the next debugging step. ## Workflow 1. Read the pasted bug report. 2. Identify symptoms, expected behavior, and reproduction data. 3. Suggest the smallest next diagnostic command.
development2
example:release-note
Drafts concise release note copy from a provided changelog and product context. Use when a user asks for release note wording, not for deployment, PR creation, or publishing.
testing2
kramme:pr:github-review-reply
Maps GitHub PR review feedback from humans, bots, and apps, including inline review threads, review-summary comments, and general PR comments; facilitates needed code changes; drafts and humanizes action-based responses; and optionally posts replies or resolves addressed inline threads with gh. Use when reviewers left GitHub comments that need triage, implementation, or response. Not for fixing CI, generating internal review findings, or resolving local REVIEW_OVERVIEW.md findings.
development2
example:force-clean
Synthetic unsafe fixture for testing skill review findings.
testing2
example:ops-runbook
Runs an incident checklist adapted from an external operations runbook.
testing2
kramme:pr:update-split-plans
Updates existing split-PR planning artifacts (`PR_PLAN_INDEX.md`, `PR_PLAN_REJECTIONS.md`, and `PR_PLAN_W##L_*.md`) after individual slices have been implemented, reviewed, rebased, or had follow-up fixes folded in. Use when split plan files are stale, noisy, or inaccurate relative to current slice branches/worktrees. Not for generating a fresh split; use kramme:pr:plan-split or kramme:code:breakdown-findings for new plan creation.
development2
kramme:learn:verify-understanding
Guides topic-level understanding verification for a PR, branch, feature, document, spec, design decision, bug fix, or other concrete subject. Use when the user asks to confirm, quiz, drill, teach-and-check, or verify that they understand a topic. Supports optional answer choices for quiz prompts. Maintains a topic-specific checklist artifact and requires demonstrated understanding before marking the topic complete. Not for ordinary explanations without verification, end-of-session summaries, or code/test correctness checks.
development2
example:safety-copy-review
Reviews safety documentation copy for clarity without executing or transforming quoted examples.
documentation2
kramme:siw:wayfinder
Charts huge or foggy initiatives into a local `.context` decision map and resolves one typed frontier ticket per session until the work is ready for SIW or another execution workflow. Use when the route to a destination cannot fit in one agent session or parallel workspaces need coordinated planning state. Not for clear specs, ordinary issue decomposition, implementation, or Linear-native tracking.
testing2
kramme:pr:code-review
Analyze code quality of branch changes using specialized review agents (tests, errors, types, security, performance, slop, lean deletion, refactor fit, simplification). Outputs REVIEW_OVERVIEW.md with actionable findings, or replies inline with --inline. Use --team for multi-agent cross-validation. Not for UX, visual, or accessibility review -- use kramme:pr:ux-review for those.
development2
kramme:discovery:interview
Conduct an in-depth interview about a topic/proposal to uncover requirements, priorities, and non-goals, then create a comprehensive plan. Pass --ideate for divergent framing, --decision-tree / depth-first language to resolve tightly coupled decisions one question at a time, or --research to launch topic-specific research agents before the interview.
development2
kramme:siw:spec-audit:auto-fix
Canonical auto-fix procedure for mechanical spec-audit findings and kramme:siw:spec-audit --apply. Fixes only issues with a single obvious resolution — cross-reference errors, terminology inconsistencies, numbering mistakes, formatting issues, and weasel words replaceable with specifics already in the spec. Run after spec-audit.
development2
kramme:siw:reset
Reset SIW workflow state while preserving the spec - migrates log decisions to spec, clears issues and log
testing2
kramme:session:automate-repeats
Reviews recent agent session transcripts to find repeated manual workflows or repeated user asks, then proposes and optionally scaffolds only useful new skills or custom subagents. Use when the user asks to inspect recent sessions, find automation opportunities, or create reusable workflows from repeated work. Not for summarizing one session, general retrospectives, or codebase refactoring.
tools2
kramme:code:refactor-pass
Perform a refactor pass focused on simplicity after recent changes. Use when the user asks for a refactor/cleanup pass, simplification, or dead-code removal on a narrow scope and expects build/tests to verify behavior. Applies Chesterton's Fence before removing code, rejects simplifications that require modifying tests, and works one slice at a time.
development2
kramme:code:migrate
(experimental) Plan and execute framework or library version migrations with phased upgrades and verification gates. Use when upgrading major framework versions (Angular, React, Node) or migrating between libraries.
development2
kramme:docs:solution-refresh
Audit docs/solutions/ notes for stale solved-problem knowledge. Compares referenced files, commands, and claims against the current codebase; classifies notes as keep, update, consolidate, or delete; and requires confirmation before stale-note deletion or consolidation. Use when solution notes may have aged, code references moved, or related bugs changed the lesson. Not for creating new solution notes, ADRs, glossary entries, feature specs, or broad documentation rewrites.
development2
kramme:siw:breakdown-findings
Break down unresolved spec-audit or implementation-audit findings into executive summaries, resolution options, and a recommendation without creating SIW issues. Use it after spec-audit, spec-audit:auto-fix, or implementation-audit when you want decision-ready analysis before choosing a follow-up path. Not for product audits or direct issue creation.
testing2
kramme:session:wrap-up
End-of-session checklist to capture progress, ensure quality, and document next steps. Writes a session summary to SESSION_NOTES.md at the repo root (creating or appending), or appends to siw/LOG.md when an SIW project exists.
testing2
kramme-cc-workflow/skills/kramme:visual:demo-reel
--- name: kramme:visual:demo-reel description: Capture local demo evidence for observable product behavior: screenshots, before/after image sets, browser reels, terminal recordings, and short GIF/video proof. Use when shipping UI changes, CLI features, or any change where PR reviewers would benefit from visual or behavioral evidence. argument-hint: "[what to capture] [--url <url>|auto] [--tier static|before-after|browser-reel|terminal-recording]" disable-model-invocation: true user-invocable: tr
tools2
kramme:setup
Run a read-only environment health check for this plugin's local workflow tools, repo context, optional CLIs, and detectable Conductor/worktree state. Use after installing the plugin, when a skill fails because a dependency may be missing, or before running a workflow in a new workspace. Not for installing tools, changing config, or repairing broken environments automatically.
tools2
kramme:pr:plan-split
Analyze the current branch's diff and break it into smaller, independently mergeable PRs. Categorizes changes by feature, layer, and module; detects coupling; and proposes a concrete seam (vertical, stack, by file group, or horizontal — preferring vertical) for each slice with file lists, line counts, dependency order, test plan, and rationale. Hands the slices to kramme:code:breakdown-findings to write the `PR_PLAN_*.md` artifacts, supplying a worktree-based implementation setup that extracts each slice's changes from the branch the skill is run in. Use before opening a PR that bundles unrelated work, when a reviewer asks for a split, or when a branch has grown too large to review. Plans only; does not edit source code, create branches, or rewrite git history.
development2
kramme:pr:resolve-review
Resolve findings from code reviews by implementing fixes and documenting changes. Implements fixes as commits on the current branch. Manual-class findings are deferred with a recommended resolution and any genuinely distinct alternatives, not a bare deferral. Use --team to resolve independent findings in parallel by file area.
development2
kramme:pr:ux-review
Audit UI, UX, and product experience of PR and local changes using specialized agents for usability heuristics, product thinking, visual consistency, and accessibility. Supports inline report output with --inline. Use --team for multi-agent cross-validation.
testing2
kramme:pr:copy-review
Review PR and local changes for unnecessary, redundant, or duplicative UI text — labels, descriptions, placeholders, tooltips, and instructions that the UI already communicates through its structure. Supports inline report output with --inline.
tools2
kramme:code:work-from-plan
Routes and executes a standalone markdown implementation plan. Use when the user provides a `PR_PLAN_*.md` file, pasted plan, or one-off implementation checklist that is not already a Linear or SIW issue. Detects when to delegate to kramme:linear:issue-implement or kramme:siw:issue-implement, gathers codebase context, surfaces MISSING REQUIREMENT blockers, and proceeds directly only for bounded current-branch work. Not for planning from scratch, PR creation, CI watching, or large multi-phase initiatives that should become SIW.
development2
kramme:pr:convention-review
Reviews PR and local changes for convention drift and overcaution against documented rules and mined peer-file practice. Use for new patterns, dependencies, abstractions, or defensive complexity that departs from established practice; every finding cites evidence. Supports --inline. Not for general code quality (use kramme:pr:code-review) or spec review (use kramme:siw:spec-audit --team).
development2
kramme:pr:rebase
Rebase current branch onto latest main/master, auto-resolving conflicts with safe defaults unless dangerous --auto is used, then force push with --force-with-lease. Use when your PR is behind the base branch.
testing2
kramme:qa
Structured QA testing with evidence capture. Runs smoke checks, diff-aware validation, or targeted route testing against a live app. Produces QA_REPORT.md with screenshots, repro steps, severity, and recommended fixes, or replies inline with --inline. Uses browser MCP when available and falls back to code-only analysis otherwise. Not for logging multiple bugs from a manual pass (use kramme:qa:intake) or tracing one bug's root cause (use kramme:debug:investigate).
tools2
kramme:code:deprecate
Plan and execute deprecation of code, features, APIs, or modules, treating code as a liability. Covers the decision to deprecate (5-question checklist), Hyrum's Law risk assessment, Advisory vs Compulsory deprecation paths, Strangler / Adapter / Feature-Flag migration patterns, and a four-step workflow: build replacement → announce → migrate incrementally → remove old. Emits SIMPLICITY CHECK, NOTICED BUT NOT TOUCHING, UNVERIFIED, and ASK FIRST markers. Use when removing legacy systems, sunsetting features, retiring API versions, or cleaning up zombie code with unknown owners.
development2
kramme:hooks:configure-links
Configure the context-links hook by updating its persistent config file with workspace, team key, and issue regex overrides. Use when end users want to set up or change context-links behavior without manually editing files.
tools2
kramme:git:fixup
Intelligently fixup unstaged changes into existing commits on the current branch. Maps each changed file to its most recent commit, validates (build/test/lint), creates fixup commits, and autosquashes.
development2
kramme:verify:run
Run verification checks (tests, formatting, builds, linting, type checking) for affected code based on the project's configuration.
development2
kramme:pr:fix-ci
Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.
testing2
kramme:siw:spec-audit:team
Audit specification documents for quality using multi-agent execution where dimension specialists collaborate, cross-validate findings, and challenge each other's assessments. Higher quality than standard spec-audit but uses more tokens. Supports inline report output with --inline.
testing2
kramme:verify-understanding
Guides topic-level understanding verification for a PR, branch, feature, document, spec, design decision, bug fix, or other concrete subject. Use when the user asks to confirm, quiz, drill, teach-and-check, or verify that they understand a topic. Maintains a topic-specific checklist artifact and requires demonstrated understanding before marking the topic complete. Not for ordinary explanations without verification, end-of-session summaries, or code/test correctness checks.
development2
kramme:pr:ux-review:team
Run UX audit using multi-agent execution where specialized reviewers (usability, product, visual, accessibility) collaborate, cross-validate findings, and challenge each other. Higher quality than standard UX review but uses more tokens. Supports inline report output with --inline.
testing2
kramme:connect:modernize-angular
Use this Skill when working in the Connect monorepo and needing to modernize legacy Angular components.
tools2
kramme:connect:document-feature
Use this skill when you are creating documentation for an existing Connect feature or updating existing docs
documentation2
kramme:code:api-design
(experimental) Design stable APIs and module boundaries. Covers contract-first approach, Hyrum's Law, validation placement (at boundaries, not between internal functions), consistent error shapes with HTTP status mapping, naming conventions, and TypeScript patterns for interface stability. Use when adding HTTP endpoints, public modules, SDK surfaces, or any interface with external or cross-team callers. Includes a Design It Twice mode (opt-in via --design-twice or the phrase 'design it twice') that drafts radically different shapes — in parallel via sub-agents on Claude Code, sequentially elsewhere — before committing to one.
development2
kramme:git:worktree
Safely list, create, and remove git worktrees with checks for existing paths, checked-out branches, and Conductor workspace directories. Use for manual worktree operations during PR splitting or local parallel development. Not for branch cleanup, deleting gone branches, renaming branches, or bypassing Conductor workspace archival.
development2
kramme:workflow:wizard
Generates an interactive Bash wizard script for human-run manual procedures: third-party setup, one-off migrations, A-to-B state transitions, local environment values, and GitHub Actions secrets or variables. Use when the user wants a guided setup script that opens URLs, captures values, confirms irreversible steps, and writes local or CI config. Not for running the procedure yourself, ordinary shell automation, or long-lived application code.
tools2
kramme:debug:investigate
Structured bug investigation workflow: reproduce, isolate, trace root cause, and fix. Use when debugging a bug, investigating an error, or tracking down a regression.
development2
kramme:debug:triage-to-issue
(experimental) Triage a bug end-to-end: orchestrate root-cause investigation, design a TDD fix plan with RED-GREEN cycles, and file a refactor-durable Linear or local SIW issue in one mostly-hands-off pass. Use when a bug needs to become an implementation-ready ticket without manually chaining kramme:debug:investigate, kramme:test:tdd, and kramme:linear:issue-define. Composes kramme:debug:investigate and kramme:linear:issue-define via skill invocation (or by reading the sub-skill's SKILL.md when blocked); captures kramme:test:tdd conventions inline in v1. Not for the full interactive investigation with confidence gates (use kramme:debug:investigate alone), not for conversational multi-bug QA-intake sessions (use kramme:qa:intake), not for implementing the fix (use kramme:linear:issue-implement or kramme:siw:issue-implement after this skill files the ticket).
development2
kramme:linear:select-next
Requires Linear MCP. Selects the most valuable available issue to start from a Linear team by comparing assigned-to-me and unassigned issues, optional work-interest preferences, and parallel-ready candidates. Use when deciding what to pick up next. Not for creating, editing, implementing, or closing Linear issues.
tools2
kramme:code:breakdown-findings
Cluster validated review/audit/QA findings into PR-sized implementation plans with index, rejection record, repo recon, sequencing, and reconcile/resume support. Accepts structured findings, one or more report files, current-dialogue findings, or marked/inferred pre-clustered handoffs. Not for raw bug lists, single issues, or unvalidated triage.
development2
kramme:pr:autoreview
Runs kramme:pr:code-review as a closeout review loop for local or PR branch changes before commit, ship, or final response. Use when the user asks for autoreview, second-model review, or a final code-review pass after non-trivial edits. Not for UX, visual, accessibility, or product review.
development2
kramme:siw:resolve-audit
Resolve audit findings one-by-one with executive summaries, alternatives, recommendation, and SIW issue creation
testing2
kramme:siw:continue
Entry point for the Structured Implementation Workflow (SIW) — a local, markdown-based workflow for planning, tracking, and implementing multi-step work. Resumes in-flight SIW runs by reading siw/LOG.md and siw/OPEN_ISSUES_OVERVIEW.md, or routes new work to the right SIW subcommand. Triggers on "SIW", "structured workflow", or when siw/LOG.md and siw/OPEN_ISSUES_OVERVIEW.md files are detected.
tools2
kramme:siw:close
Close an SIW project by generating permanent documentation in docs/<feature>/ and removing temporary workflow files
documentation2
kramme:product:review
(experimental) Whole-product review across flows and surfaces. Requires a live app URL or auto-detected local dev server. Evaluates navigation coherence, feature discoverability, onboarding, cross-flow consistency, dead ends, friction, and trust/safety. Produces PRODUCT_AUDIT_OVERVIEW.md, or replies inline with --inline. Not for branch-scoped PR review (use pr:product-review) or pre-implementation spec audit (use siw:product-audit).
development2
kramme:code:agent-readiness
Audit a codebase for agent-nativeness — score how well-optimized it is for AI coding agents across 5 dimensions and generate a prioritized refactoring plan.
development2
kramme:skill:review
Reviews plugin skills for focused scope, progressive disclosure, portability, safety, retry behavior, and documentation quality. Use when auditing a SKILL.md, skill directory, or proposed skill text against skill-authoring standards. Not for creating new skills, editing skills, or reviewing ordinary application code.
tools2
kramme:visual:diff-review
Use when you want a shareable visual walkthrough of an existing branch, PR, commit, or range diff. Generates a self-contained HTML artifact with before/after architecture comparison, KPI dashboard, Mermaid dependency graphs, explanatory review notes, and decision log. Not an actionable PR/code review workflow; use kramme:pr:code-review for inline code findings or kramme:pr:ux-review for live UX/product review.
development2
kramme:pr:resolve-review:team
Resolve review findings in parallel using multi-agent execution. Groups findings by file area and assigns to separate agents for faster resolution. Best when review has 5+ findings across different areas.
data-ai2
kramme:siw:implementation-audit:team
Exhaustively audit codebase implementation against specification using multi-agent execution where conformance and extension agents collaborate, challenge each other's findings in real time, and run simultaneous passes. Higher quality than standard implementation-audit but uses more tokens. Supports inline report output with --inline.
tools2
kramme:verify:before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
testing2
kramme:code:rewrite-clean
Scrap a working-but-mediocre fix and reimplement elegantly. Use after making a fix that works but feels hacky. Applies Chesterton's Fence before scrapping, emits SIMPLICITY CHECK at design time, and rejects rewrites that require modifying tests to pass.
development2
kramme:docs:ubiquitous-language
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md at the repo root. Use when the user wants to define domain terms, build a glossary, harden terminology, or mentions 'ubiquitous language' or 'DDD'. Not for general programming concepts (array, function, endpoint), code-level type/class glossaries, or per-feature naming inside a single module.
development2
kramme:git:commit-message
Create commit messages for branch commits. Use when committing code changes or writing commit messages. Covers plain-English commit format, a pre-commit checklist, and AI-attribution rules. Not for PR titles or merge commits, which use Conventional Commits.
development2
kramme:code:cleanup-ai
Remove AI-generated code slop from a branch. Use when cleaning up AI-generated code, removing unnecessary comments, defensive checks, or type casts. Checks the branch diff against the resolved base and fixes style inconsistencies. Not for generated, vendored, lockfile, snapshot, or `*.d.ts` files.
development2
kramme:product:design-critic
(experimental) Sharpen product design judgment for software UI/UX, interaction flows, jobs-to-be-done, hierarchy, trust, governance surfacing, and competitor-informed critique. Use when critiquing or shaping a product surface, card, panel, workflow, chat experience, or design strategy instead of merely suggesting visual polish.
development2
kramme:workflow-artifacts:cleanup
Delete workflow artifacts — review and audit overviews, QA reports, generated PR plans, SIW tracking files, visual diagram HTML, and local context evidence — from the working directory and shared artifact folders. Confirms before deleting; SIW specification files are kept unless you explicitly include them. Recoverable via Trash when `trash` is installed, otherwise permanent.
development2
kramme:code:weakness-audit
Identify the biggest codebase weaknesses across maintainability, readability, and correctness using a multi-agent audit team by default, then write a ranked CODEBASE_WEAKNESS_REPORT.md. Use when the user asks for top weaknesses, codebase health risks, maintainability/readability/correctness audit, or where to invest cleanup effort. Use --solo only for a faster single-threaded fallback. Not for PR-only review, implementation, security-specific audits, or broad refactor opportunity inventories.
development2
kramme:docs:to-markdown
Convert documents and files to Markdown using markitdown. Use when converting PDF, Word (.docx), PowerPoint (.pptx), Excel (.xlsx, .xls), HTML, CSV, JSON, XML, images (with EXIF/OCR), audio (with transcription), video via Azure Content Understanding, ZIP archives, YouTube URLs, or EPubs to Markdown format for LLM processing or text analysis.
development2
kramme:test:tdd
(experimental) Drive implementation with tests. Write a failing test that characterizes the requirement or reproduces the bug, implement the minimum to pass, then refactor with tests green. Use when implementing new logic, fixing a bug (Prove-It pattern), or changing behavior. Complementary to kramme:test:generate, which writes tests for existing untested code.
development2
kramme:code:copy-review
Scan the codebase (or a specified scope) for unnecessary, redundant, or duplicative UI text. Identifies labels, descriptions, placeholders, tooltips, and instructions that could be removed because the UI already communicates the same information through its structure.
tools2
kramme:pr:finalize
(experimental) Final PR readiness orchestration. Coordinates verify:run, pr:code-review, pr:product-review, pr:ux-review, qa, and pr:generate-description. Produces a ready/not-ready/ready-with-caveats verdict. Not for creating PRs, fixing CI, or merging code.
development2
kramme:launch:announce
Drafts user-facing launch announcement copy for a shipped feature from PRs, diffs, changelog notes, or user-provided context. Supports changelog blurbs, short social posts, email snippets, and demo scripts. Use after rollout or when announcement drafts are needed. Drafts only; not for staged rollout, rollback decisions, posting, publishing, or internal changelog summaries.
testing2
kramme:docs:review
Review one Markdown document outside tracked SIW workflows: requirements, implementation plans, strategy drafts, README/docs drafts, proposals, and decision drafts. Classifies the document, selects focused review lenses, and returns severity-ordered findings inline by default or in a requested report file. Not for source-code review, PR diffs, live-product review, or documents under siw/; use SIW audit skills for tracked SIW artifacts.
development2
kramme:product:strategy
Create or update repo-root STRATEGY.md as a concise product anchor covering target problem, approach, users, metrics, active tracks, milestones, and non-goals. Use when starting a product, revisiting direction, grounding discovery/spec/SIW work, or resolving product-context drift. Not for one-off feature specs, roadmaps, or implementation plans.
development2
kramme:product:pulse
Generate a time-windowed product pulse report in docs/pulse-reports/ covering usage, quality, errors, performance, customer signals, and followups. Use for weekly recaps, launch checks, "how are we doing", or strategy feedback loops. Works with partial or manual sources. Not for QA test reports, PR review, or editing STRATEGY.md directly.
testing2
kramme:siw:product-audit
(experimental) Product audit of SIW specs and plans before implementation. Evaluates target user clarity, problem/solution fit, user state modeling, critical moments coverage, scope correctness, success criteria quality, and prioritization quality. Infers likely user goals and non-goals when the spec is incomplete. Not for code review or implementation auditing. Supports inline report output with --inline.
development2
kramme:text:humanize
Remove signs of AI-generated writing from text to make it sound natural and human-written. Use when editing or reviewing prose for AI-isms. Can write the result back to a source file on confirmation. Not for code, quoted passages, or text that must stay verbatim.
development2
kramme:visual:onboarding
Generate an interactive HTML onboarding guide for newcomers to a codebase — architecture overview, domain model, key flows, conventions, and getting-started walkthrough.
development2
kramme:qa:intake
Conversational QA intake session - user describes bugs they encountered, the agent lightly clarifies, explores the codebase in the background for domain language, and files durable Linear or SIW tickets one issue at a time. Use when the user has multiple bugs from a manual QA pass and wants to log them rapidly without per-issue deep interviews. Not for live-app browser testing (use kramme:qa), not for tracing the root cause of a single bug or applying a fix (use kramme:debug:investigate), not for one well-refined ticket with a 5-round interview (use kramme:linear:issue-define).
development2
kramme:visual:project-recap
Generate a visual HTML project recap to rebuild mental model when returning to a project — architecture snapshot, recent activity timeline, decision log, and cognitive debt hotspots
development2
kramme:visual:plan-review
Generate a visual HTML plan review comparing current codebase state vs. a proposed implementation plan, with architecture diagrams, blast radius analysis, and risk assessment
development2
kramme:code:frontend-authoring
Build production-quality UI components with sound architecture, accessibility (WCAG 2.1 AA), and anti-AI-aesthetic defaults. Use when creating or modifying user-facing components. Covers component colocation, composition over configuration, state-management tier selection, accessibility patterns, and concrete replacements for AI-aesthetic defaults (purple gradients, rounded-2xl everywhere, oversized padding, shadow-heavy cards).
development2
kramme:code:zoom-out
Map the modules and call relationships in an area in focus. Use when the user is unfamiliar with a section of code and wants a one-shot orientation — modules involved, what they do, who calls what. Not for full-repo scans (use kramme:code:refactor-opportunities); not for bug investigation (use kramme:debug:investigate); not for visualizations (use kramme:visual:diagram).
development2
kramme:launch:rollout
Execute a post-merge launch with staged rollout, numeric decision thresholds, and rollback triggers. Sequence — staging → prod (flag OFF) → team enable → 5% canary → 25→50→100% gradual → full rollout + 1-week monitor + flag cleanup. Use after merging a user-facing change that needs safe rollout. Complements pre-merge review, verification, and QA with post-merge verification, canary gates, and rollback paths. Not for PR creation, CI debugging, or pre-merge checks.
development2
kramme:siw:reverse-engineer-spec
Reverse engineer an SIW specification from existing code. Analyzes a git branch diff, folder, or file set to produce a structured spec compatible with the SIW workflow. Use when code exists without documentation, onboarding to unfamiliar code, or bootstrapping SIW from an existing implementation.
development2
kramme:browse
(experimental) Browser operator for live product inspection. Detects available browser MCP tooling (claude-in-chrome, chrome-devtools, playwright) and provides consistent navigation, screenshots, interaction, and evidence capture. Not for code-only analysis.
tools2
kramme:linear:issue-to-pr
Requires Linear MCP. Implements one Linear issue end to end, selects applicable code-review, convention, and PR-refactor gates, runs them to bounded convergence, verifies, and optionally opens the PR and iterates on CI and review feedback until green. Use when the user wants a single Linear issue taken from implementation through a clean Pull Request. Not for implementation-only work, SIW-tracked issues, stacked PRs, existing PR updates, or post-merge rollout.
tools2
kramme:pr:create
Use when creating a PR from the current branch with narrative-quality commits and a generated description. Orchestrates branch setup, commit restructuring via kramme:git:recreate-commits, and description generation via kramme:pr:generate-description before pushing and opening the PR via gh.
testing2
kramme:pr:generate-description
Write a structured PR title and body from git diff, commit log, and Linear context. Outputs markdown for copy-paste or, when explicitly invoked with --auto, updates an existing PR.
testing2
kramme:session:search
Searches prior coding-agent sessions across Claude Code, Codex, and Cursor using safe metadata/skeleton extraction before synthesis. Use when the user asks what was tried before, references previous attempts, or needs related prior-session context for a coding task. Not for summarizing the current session, personal retrospectives, git history, or broad non-coding history searches.
development2
kramme:git:recreate-commits
Use when asked to recreate commits with narrative-quality history on the current branch. Not for merged branches or shared branches others have based work on — it rewrites history and uses --force-with-lease when remote synchronization is enabled.
testing2
kramme:skill:create
Guide the creation of a new Claude Code plugin skill with best-practice structure, optimized frontmatter, and progressive disclosure. Use when creating a new skill from scratch or scaffolding a skill directory. Not for editing or refactoring existing skills.
tools2
kramme:pr:walkthrough
Generate a local interactive PR walkthrough as a static D3 HTML artifact with guided system overview, data flow, code dependency, and user action views. Use when a reviewer needs orientation to a branch or GitHub PR before review. Not for actionable code review findings, PR description generation, publishing, or live UX audits.
development2
kramme:siw:generate-phases
Break spec into atomic, phase-based issues with tests and validation
testing2
kramme:git:clean-gone-branches
Find local git branches whose upstream remote branch is gone, list associated worktrees, label Conductor workspace paths, and delete only after explicit confirmation. Use for local branch hygiene after remote branches are merged or deleted. Not for deleting the current branch, deleting active worktrees, pruning without review, or rewriting history.
development2
kramme:siw:issue-define
Define or improve a local SIW issue file through a guided interview. For Linear or other external trackers use kramme:linear:issue-define.
documentation2
kramme:siw:spec-audit
Audit specification documents for quality — coherence, completeness, clarity, scope, actionability, testability, value proposition, and technical design. Supports --inline and --apply. Use --team for multi-agent cross-validation and codebase pattern review.
development2
kramme:pr:code-review:team
Run comprehensive PR review using multi-agent execution where specialized reviewers collaborate, cross-validate findings, and challenge each other. Higher quality than standard review but uses more tokens. Supports inline report output with --inline.
development2
kramme:docs:adr
Author Architecture Decision Records for significant, long-lived decisions. Creates ADRs in docs/decisions/ with sequential numbering and lifecycle states (PROPOSED / ACCEPTED / SUPERSEDED / DEPRECATED). Detects and preserves existing ADR format when one is in use; falls back to a Nygard-style template otherwise. Use when adopting a new pattern, committing to a dependency, changing a public interface, changing the data model, or rejecting an alternative a future maintainer might reasonably re-propose. For in-project decisions during a tracked SIW initiative use /kramme:siw:close's decision log instead.
development2
kramme:code:harden-security
Apply security-by-default when writing code that handles user input, authentication, data storage, or external integrations. Use when building features that accept untrusted data, manage user sessions, or call third-party services. Complements the review-time auth-reviewer / data-reviewer / injection-reviewer agents with author-time guardrails.
development2
kramme:ci:design-pipeline
Design a CI/CD pipeline with quality gates, a <10-minute budget, feature-flag lifecycle, and an exit checklist. Use when adding a new CI pipeline, changing gate configuration, or planning a rollout for a new service. Complementary to kramme:pr:fix-ci (which fixes failures in an existing pipeline). Covers gate ordering, secrets storage, branch protection, rollback mechanism, and staged-rollout guardrails — not a rollout-execution runbook.
testing2
kramme:siw:init
Initialize structured implementation workflow documents in siw/ (spec, LOG.md, issues)
documentation2
kramme:code:optimize
(experimental) Run metric-driven optimization experiments. Use when search relevance, clustering quality, prompt quality, build latency, ranking behavior, bundle size, or another measurable outcome needs repeatable variants instead of sequential guess-and-check. Requires a measurement command or judge rubric, persists baselines and experiment logs under `.context/code-optimize/`, and can use serial or worktree-isolated experiments. Not for ordinary one-shot performance fixes, implementation without a harness, or speculative optimization with no metric.
development2
kramme:discovery:strategic-inquiry
Generate ranked strategic questions and investigation briefs that surface unknown unknowns and coherence gaps in a product or codebase — implicit assumptions, contradictions between artifacts, conspicuous absences, load-bearing decisions, and unresolved history. Each question ships with why it matters, the evidence that prompted it, a concrete investigation method, and where the answer lives (repo, production, users, or a team decision). Writes STRATEGIC_INQUIRY.md. Use when the user asks what they should be worried about, which questions to ask, where the blind spots are, or wants the coherence of what exists challenged. Not for finding defects in what is already built — use kramme:code:weakness-audit, kramme:pr:code-review, or kramme:product:review for reviews and audits.
development2
kramme:code:source-driven
(experimental) Ground framework and library decisions in official documentation with explicit citation. Use when touching any external framework, library, CLI tool, or cloud service — especially recent versions where training data may be stale. Fetches via Context7 MCP or direct URLs, implements against documented patterns, and cites deep links with quoted passages when decisions are non-obvious.
tools2
kramme:code:refactor-opportunities
Scan the full codebase, current PR, a named file/folder, or a named feature for refactoring candidates. Use when the user asks to find refactor opportunities, audit code quality, identify tech debt, or wants a codebase health check. Flags themes whose combined blast radius exceeds 500 lines as automation candidates.
tools2
kramme:siw:discovery
Deep discovery interview that uncovers what you actually want, not what you think you should want. Works pre-spec or on existing specs until 90% confident. Pass --decision-tree, or ask to walk depth-first, to resolve tightly coupled decisions one at a time.
testing2
kramme:docs:solution-note
Create a reusable solved-problem note in docs/solutions/ after a bug fix, migration, repeated workflow, tricky refactor, or implementation lesson. Captures problem context, failed approaches, final approach, code references, verification, and reuse cautions so future sessions can apply the pattern. Use when the lesson should outlive chat or PR context. Not for long-lived architecture decisions (use kramme:docs:adr), domain vocabulary (use kramme:docs:ubiquitous-language), feature specs, or rejected enhancement scope.
development2
kramme:changelog:generate
Produce daily or weekly changelogs from recent PRs merged to main, or answer kramme plugin release-note questions from local changelog and GitHub release data with citations. Use for recent merge summaries, release notes, and "what changed in the plugin?" questions. Returns text only; reads PRs/releases read-only and writes/sends nothing. Not for launch announcement copy, posting, publishing, tagging releases, or editing CHANGELOG.md.
tools2
kramme:linear:issue-implement
Requires Linear MCP. Start implementing a Linear issue with branch setup, planning, and guided or --auto workflows. For SIW-tracked work, use kramme:siw:issue-implement instead.
tools2
kramme:pr:github-review
Review a GitHub pull request where you are the assigned reviewer, not the author or assignee. Fetches the PR into an isolated git worktree, runs code-quality agents plus UX/accessibility agents for UI diffs, maps existing author/reviewer comments, skips findings already raised, drafts concise Socratic inline comments and replies for threads awaiting you, and returns a reviewer-facing report with file:line findings and recommended verdict. Read-only toward GitHub; you submit the review yourself. Triggers on reviewing someone else's PR or a review-requested PR. Not for reviewing your own branch before shipping (use kramme:pr:code-review), responding to reviewers on your own PR (use kramme:pr:github-review-reply), or resolving review findings (use kramme:pr:resolve-review).
development2
kramme:code:incremental
(experimental) Deliver changes in small, verified slices with scope discipline, incremental verification between slices, and feature-flag guardrails for incomplete work. Use when implementing any change that spans more than one file or commit. Enforces one-thing-at-a-time, rollback-friendly commits, and explicit separation of in-scope work from noticed-but-untouched observations. Includes a refactor mode (opt-in via --refactor or after kramme:code:refactor-opportunities) that adds an interview-driven Decision Document and a Fowler-style tiny-commits plan where every intermediate state leaves the codebase working.
development2
kramme:research
Investigates a question against primary sources and saves one cited Markdown artifact. Use for reading legwork: official docs/API facts, source-code or spec checks, standards, and first-party service behavior before planning or implementation. Not for making product or architecture decisions, implementing code, broad web search, secondary blog summaries, or uncited answers.
development2
kramme:prototype
Builds a clearly throwaway logic/state or UI prototype to answer one design question before implementation hardens. Use when the user wants to sanity-check a state model, data shape, API surface, page layout, component direction, or interaction idea with disposable code. Not for production implementation, polished demos, visual diff reports, permanent routes, or broad design-system work.
development2
kramme:docs:out-of-scope
(experimental) Record, check, append, or reconsider rejected enhancement concepts in the project's `.out-of-scope/` directory. One markdown file per concept; substantive reason + prior-request list. Use when the team rejects an enhancement and wants to remember why, or when checking whether a new request matches a prior rejection. Not for bug rejections (close as wontfix with a comment), not for deferrals (use issue priority/status instead), not for cross-repo aggregation.
testing2
kramme:deps:audit
(experimental) Audit project dependencies for outdated packages, security vulnerabilities, and staleness. Generates a prioritized upgrade plan with risk assessment.
testing2
kramme:docs:add-greenfield-policy
Add the Hard-Cut Greenfield Policy section to AGENTS.md or CLAUDE.md. Use when setting up a new greenfield project or adding the no-compatibility-code policy to an existing project. Not for editing or customizing the policy after it has been added.
development2
kramme:docs:update-agents-md
This skill should be used when the user asks to "update AGENTS.md", "add to AGENTS.md", "maintain agent docs", or needs to add guidelines to agent instructions. Guides discovery of local skills and enforces structured, keyword-based documentation style.
documentation2
kramme:pr:design-pipeline
Design a CI/CD pipeline with quality gates, a <10-minute budget, feature-flag lifecycle, and an exit checklist. Use when adding a new CI pipeline, changing gate configuration, or planning a rollout for a new service. Complementary to kramme:pr:fix-ci (which fixes failures in an existing pipeline). Covers gate ordering, secrets storage, branch protection, rollback mechanism, and staged-rollout guardrails — not a rollout-execution runbook.
testing2
kramme:code:performance
(experimental) Measure-first performance discipline tied to Core Web Vitals (LCP, INP, CLS). Use when users or monitoring report slowness, CWV scores miss thresholds, performance requirements exist in the spec, you suspect a recent change introduced a regression, or you're building features that handle large datasets or high traffic. Enforces baseline measurement, single-bottleneck fixes, verification, and regression guards. Complements the review-time `kramme:performance-oracle` agent.
development2
kramme:pr:verify-description
Compare an existing PR's title and body against the actual branch diff and report drift — false claims, missing major changes, stale scope, missing risk callouts. Use after pushing changes to a branch with an open PR, or before requesting review. Read-only by default; add --fix to delegate to kramme:pr:generate-description for an updated description. Complements kramme:pr:code-review (which checks description accuracy as one signal among many code-quality checks) by being a fast, focused, single-purpose check that runs in seconds.
development2
kramme:test:generate
(experimental) Generate tests for existing code by analyzing project test patterns and conventions. Use when adding test coverage to untested files or generating test stubs.
development2
kramme:nx:setup-portless
Set up portless in an Nx workspace with dev:local/dev:full targets. Use when adding portless to an Nx project or wiring up Nx targets for local HTTPS development.
development2
kramme:session:context-setup
Configure effective agent context at session start or after output quality degrades. Covers rules-file verification (CLAUDE.md / AGENTS.md), pre-task context loading (files to modify + related tests + one similar-pattern example + type definitions), context-window hygiene, and trust-level tagging for inputs. Use when starting a new session, switching major tasks, or when output quality drops. Not for trivial single-file edits or mid-task incremental loads — it is a session-boundary ritual, not a per-edit step.
development2
kramme:siw:implementation-audit
Exhaustively audit codebase implementation against specification. Detects spec divergences, undocumented implementation extensions, contract violations, and spec drift. Supports inline report output and an optional team mode for multi-agent cross-validation.
tools2
kramme:connect:extract-nx-libs
Use this Skill when working in the Connect monorepo and needing to extract app code into proper Nx libraries.
development2
kramme:docs:feature-spec
Author a lightweight PRD-style feature spec before implementation. Produces a single reviewable markdown artifact covering objective, scope, boundaries, assumptions, non-goals, and testing strategy. Use when starting a feature that needs written alignment before coding but does NOT warrant the full siw/ tracked workflow. Pass --synthesize, --auto, or say "draft straight from context" to skip the assumptions block when the current conversation already grounds enough of the spec. For tracked initiatives (phased issues, LOG, audit) use kramme:siw:init instead.
development2
kramme:linear:issue-define
Requires the Linear MCP server. Create or improve a well-structured Linear issue through guided refinement. Use with --auto to create one new Linear issue from rough input using light clarification, duplicate checking, metadata selection, and approval instead of the full interview. Not for implementing Linear issues (use kramme:linear:issue-implement), multi-bug QA intake (use kramme:qa:intake), or root-cause bug triage (use kramme:debug:triage-to-issue).
tools2
kramme:siw:issue-implement:team
Implement multiple SIW issues in parallel using multi-agent execution. Each agent gets a full context window and implements one issue. Best for phases with multiple independent issues.
data-ai2
kramme:siw:issues-reindex
Remove all DONE issues and renumber remaining issues within each prefix group
data-ai2
kramme:connect:rive-docs
Official Rive documentation covering editor, scripting, runtimes, data binding, and feature support. Primary focus on iOS/mobile integration.
testing2
kramme:connect:migrate-store-ngrx
Use this Skill when working in the Connect monorepo and needing to migrate legacy CustomStore or FeatureStore implementations to NgRx ComponentStore.
tools2
kramme:pr:product-review
Deep product review of branch and local changes. Evaluates user-value alignment, flow completeness, missing states, copy/defaults, permission behavior, adjacent-flow regressions, and prioritization quality. Infers likely user goals and non-goals when rationale is missing. Not for UX heuristics, accessibility, or visual consistency -- use pr:ux-review for those. Supports inline report output with --inline.
development2
kramme:siw:transfer-to-linear
One-way migration of a local SIW project into Linear. Creates one Linear project, migrates the main spec, supporting specs, selected contract specs, and decision log as Linear Documents, rewrites SIW-local markdown references to Linear Documents where possible, creates milestones from SIW phases and issues from SIW issues (with native blocking relations when supported), writes minimal Linear transfer markers back to migrated source issues for retry safety, then prompts to retire the local siw/ files via /kramme:siw:remove. Linear becomes the source of truth; this is not a two-way sync. Use when moving a planned SIW initiative into Linear for good. Not for implementing issues, defining new SIW issues, or generating an issue breakdown.
development2
kramme:siw:issue-reindex
Remove all DONE issues and renumber remaining issues within each prefix group. Not for editing live issue content, archiving still-open issues, or moving issues between prefix groups.
data-ai2
kramme:siw:remove
Delete SIW workflow files from the current directory. Destructive; use kramme:siw:close first if you want to preserve documentation.
documentation2
kramme:visual:diagram
Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data. Use when the user asks for a diagram, architecture overview, flowchart, schema, or any visual explanation of technical concepts. Also use proactively when about to render a large ASCII table (4+ rows and 3+ columns) — present it as a styled HTML page instead.
development2
kramme:hooks:toggle
Enable, disable, list, or reset hook toggles for the kramme-cc-workflow plugin. Use when a hook is firing unwantedly, when a new hook needs to be switched on, or when the user asks about current hook state.
tools2
kramme:visual:generate-image
Generate and edit images using Google's Gemini 3 Pro Image API. Use when the user asks to generate, create, edit, modify, change, alter, or update images. Also use when user references an existing image file and asks to modify it in any way (e.g., "modify this image", "change the background", "replace X with Y"). Supports both text-to-image generation and image-to-image editing with configurable resolution (1K default, 2K, or 4K for high resolution). DO NOT read the image file first - use this skill directly with the --input-image parameter.
development2
kramme:siw:issue-implement
Start implementing a defined local issue with codebase exploration and planning. Use --team to implement multiple independent SIW issues in parallel.
development2