Skip to content

calmtechltd/calm-craft

v0.4.3MIT

Specs as the source of truth, a chunked delivery loop, and decided-and-enforced code conventions — as portable agent skills.

ask-questions

Surface consequential open decisions in the current task and ask through the host's available question tools. Use when asked for questions or when necessary facts remain unresolved; reuse settled decisions and authorized defaults.

author-implementation-plan

Generate a chunked implementation plan from a design document (and optional related specs). Produces phased, agent-session-sized chunks with dependencies, acceptance criteria, and spec links. Use when planning a new feature from a design doc, turning standards-feature.md-style designs into execution plans, or when the user asks for an implementation plan, chunk breakdown, or phased rollout from specs.

branch-cleanup

Survey local branches, worktrees, and Graphite stacks for cleanup, including squash-merged PRs. Use for branch or worktree cleanup and merge-status questions. Report merge evidence and ownership blockers before authorized local deletion; remote branches are report-only.

branch-self-review

Review a branch or the current task's changes for functional bugs, permission and tenancy holes, and maintainability problems. Use when the user asks to review changes or an implementation workflow calls for final review. Reports findings without editing product code or running whole-repository gates.

bug-regression-red-green

Fix a bug by reproducing it with a failing test, then fixing the code until green and preserving regression protection. Use when the user says "write a regression test", "red test first", "fix this bug properly", "make sure this never breaks again", or when fixing incorrect behaviour with no test covering the broken path.

clean-code-slop

Find and simplify low-value tests, redundant wrappers, duplicated business rules, speculative abstractions, and inconsistent code. Use only when the user explicitly requests a code-slop audit or cleanup, or invokes clean-code-slop. Honour review-only requests; otherwise make verified, behaviour-preserving simplifications within the requested scope.

coderabbit-review-implement

Implement verified PR review fixes from CodeRabbit, Codex, and human reviewers using completed triage. Keep changes local; publication, replies, and resolution use coderabbit-review-publish-resolve when requested.

coderabbit-review-publish-resolve

Triage, implement, verify, commit and publish PR review fixes, then reply and resolve addressed CodeRabbit, Codex, and human feedback in one pass. Use when explicitly asked for the complete publish-and-resolve workflow; ordinary local fixes use coderabbit-review-implement.

coderabbit-review-triage

Download and triage PR feedback from CodeRabbit, Codex, and human reviewers. Save raw comments, verify findings against the codebase, and classify fixes, skips, and items needing input before implementation.

conventions-audit

Review a diff or file scope against recorded conventions, reporting verified violations and enforcement gaps. Reports only; avoids duplicating existing compiler, formatter, lint, or CI checks.

conventions-decide

Record coding convention decisions and implement their agreed enforcement using existing repository tools. Use for choosing or revising standards; preserve settled decisions and distinguish chosen answers from defaults.

conventions-migrate

Apply an agreed convention change to existing code in reviewable batches and tighten its enforcement. Use for convention migrations; select checks for the transformation instead of running tests after every batch.

conventions-revisit

Review recorded convention defaults, enforcement, exceptions, and drift. Use when revisiting standards; proposes evidence-backed changes without editing code or configuration.

engineering-setup

Discover and record the repository toolchain, CI gates, paths, and selected agent instructions. Use when setting up or repairing Calm Craft configuration; inspect commands before running only necessary authorized checks.

linear-pr-link

Check Linear for matching outstanding issues before creating or submitting a PR in repositories configured with tickets.provider: linear in .engineering/config.yaml. Link a suitable issue or offer to create one; skip repositories without Linear configured.

ready-for-pr

Run requested local CI gates, fix in-scope failures, and report readiness. Mark an existing draft ready only when that action is authorized and its published head contains the validated state. Ordinary implementation or PR metadata work does not trigger this skill.

run-implementation-plan

Execute one chunk or, when explicitly requested, finish the selected implementation plan. Read linked specs, implement within scope, and verify each chunk before marking it complete. Use when asked to run, continue, or finish a plan, implement a named or next chunk, or execute a plan in a host goal.

run-implementation-plan-all

Create or continue a host goal to finish the selected implementation plan, verifying and recording one chunk at a time across turns. Use when the user explicitly invokes run-implementation-plan-all or requests a goal to finish all remaining chunks. Ordinary one-chunk or session-only runs use run-implementation-plan.

spec-assess-coverage

Audit a feature spec against the test suite to find which behaviours, invariants, decision-table rows, and flow transitions have tests and which do not. Use when the user says "what's untested here", "which parts of this spec have tests", "where should I focus testing", or before trusting a spec's implemented badges. Pairs with spec-audit-drift, which asks whether the spec matches the code.

spec-audit-drift

Audit a feature spec against the actual implementation to find where behaviours or user-flow contracts no longer match the code. Use when the user says "is this spec still accurate", "check the spec against the code", "I think this wizard bypasses the documented flow", or before relying on a spec that hasn't been touched in a while. Reports only. Pairs with spec-assess-coverage, which asks whether tests exist.

spec-author-from-impl

Document a scoped existing feature from its implementation and current verification evidence. Use to backfill specs without changing product code, adding tests, or inventing intended behavior.

spec-author-greenfield

Write a design-first feature spec from supplied requirements and decisions, including flow contracts where warranted. Use for unbuilt features; ask only consequential unresolved questions and do not implement.

spec-author-tests

Write worthwhile tests from a feature spec and its flow contract, reusing existing coverage and reporting disagreements between code and intent. Use when the user says "write tests from this spec", "fill the coverage gaps", "prove this wizard works", or after spec-assess-coverage identifies required automated gaps.

spec-gap-sweep

Sweep every spec in the estate for maintenance debt — partial behaviours without a note, ageing future behaviours, roll-up statuses that disagree with their behaviours, long-standing open questions, and modules with no specs at all. Use when the user asks "what state are our specs in", "review the spec estate", "which open questions are blocking work", or on a periodic cadence. Reports only.

spec-harvest-discussion

Read a requested issue or PR discussion and propose evidence-backed updates to its governing spec. Use when the user asks to extract or review decisions, or to catch a spec up from a discussion. Distinguishes decisions from suggestions. This skill proposes changes; the maintenance workflow applies user-authorized spec edits.

spec-maintain-on-ship

Update a feature spec when work changes its state — a partial behaviour ships, a future behaviour is prioritised, an open question is answered, or a journey changes. Use when the user says "this shipped, update the spec", "we decided X, record it", "mark B4 done", or as part of a pull request that changes documented behaviour. Pairs with spec-audit-drift to verify the update is honest.

spec-plan-gap

Search the existing spec estate for overlap, conflict, or existing coverage, then propose where a requested spec should live and what it should cover. Use for a requested gap analysis, coverage question, or spec-authoring workflow. Documentation needs found during ordinary implementation do not trigger this skill. Pairs with spec-author-greenfield and spec-author-from-impl for writing.

spec-storyboard-journey

Storyboard and improve a spec-governed product journey using an Apple-inspired UX review lens and authoritative flow contracts. Use when the user requests a flow review, storyboard, or design proposal, or as the design stage of an authorized journey implementation. A concrete implementation suggestion about a multi-step feature does not trigger this skill by itself.

spec-triage-bug-report

Assess a bug report against authoritative intent and observed behavior, including an insufficient-evidence outcome. Use when the user asks to classify, diagnose, or report on a suspected defect, or as the diagnostic stage of an authorized fix. A mention of broken behavior inside an implementation request does not trigger this skill. This skill reports; the regression workflow handles an authorized confirmed fix.

spec-visualize

Open the local CalmCraft visualizer for a spec estate or branch review. Use when the user asks to browse, visualize, search, or review the specs in a checkout or worktree.

update-pr

Draft or update a GitHub PR title and description from its actual branch changes, preserving ticket relationships and user-authored notes. Use for requested metadata refreshes or title-only fixes; does not run gates, push code, or create/merge PRs.

write-tests

Decide whether a test is worth writing, and at which layer, before adding one. Use when writing, generating, or filling tests; when the user says "don't test this", "skip tests", "that's too many tests", or "over the top"; and whenever an agent is about to add *.test.*, *.spec.*, or component tests. Prefer fewer tests that lock behaviour over coverage padding.