@ketecode/loom 0.0.0-stage → 0.2.0

package/commands/aside.md

@@ -0,0 +1,19 @@
+---
+name: aside
+description: Answer a quick side question without changing files or losing the thread of the current task, then pick the task up where it was.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: read-only
+  kete-loom/argument-hint: "<your side question>"
+  kete-loom/owner: "Kete-org"
+---
+
+The user has a side question. Answer it without disturbing the task in progress.
+
+- Answer briefly and directly. You may read files and search the codebase to answer; do not edit files, run commands that change anything, or start new work.
+- If answering properly needs a change or a longer investigation, say so in one line and offer to do it after the current task.
+- Then add one line restating where the main task stands and the next step, and continue it unless the user says otherwise.
+
+Side question: $ARGUMENTS

package/commands/brainstorm.md

@@ -0,0 +1,25 @@
+---
+name: brainstorm
+description: Turn a rough idea into an approved design before any code is written, asking one question at a time and comparing approaches.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<idea or feature>"
+  kete-loom/owner: "Kete-org"
+---
+
+Shape the idea below into a design the user approves. Do not write or change any code during this command.
+
+If the user gave no idea, ask what they want to build and stop.
+
+If the `design-brainstorming` skill is available, follow it. Otherwise:
+
+1. Read the relevant code, docs and recent commits so questions are grounded in the project.
+2. Ask clarifying questions one at a time (purpose, users, constraints, what success looks like), preferring multiple-choice questions.
+3. Propose two or three approaches with their trade-offs, and recommend one with the reason.
+4. Present the design in short sections (scope, components, data flow, error handling, testing), asking after each whether it looks right.
+5. When the user approves, offer to save it as a design document and to turn it into an implementation plan (`implementation-plans` skill or `/plan-feature`).
+
+Idea from the user: $ARGUMENTS

package/commands/build-fix.md

@@ -0,0 +1,26 @@
+---
+name: build-fix
+description: Fix the current build, compile or type-check failure with the smallest change, routed to the build resolver for that language.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[failing command or error output]"
+  kete-loom/owner: "Kete-org"
+---
+
+Get the build passing again with minimal, targeted edits.
+
+1. Find the failing command. Use the one the user gave below; otherwise take the build or type-check command from the project's CI workflow, package scripts, Makefile or task runner, run it, and capture the first error.
+2. Identify the language from the failing tool (for example `tsc`, `go build`, `cargo`, `mvn`/`gradle`, `dotnet`, `cmake`/`make`, `swift build`, `dart analyze`/`flutter build`, `composer`, `bundle`, `pip`/`mypy`).
+3. Delegate to the matching Kete Loom agent if it is available: `typescript-build-resolver`, `python-build-resolver`, `go-build-resolver`, `rust-build-resolver`, `java-build-resolver`, `kotlin-build-resolver`, `csharp-build-resolver`, `fsharp-build-resolver`, `cpp-build-resolver`, `swift-build-resolver`, `dart-build-resolver`, `php-build-resolver`, `ruby-build-resolver`, `perl-build-resolver`. Pass it the exact command and error output.
+4. If no resolver is available, fix it yourself:
+   - Fix the root cause of the first error, then re-run; later errors are often follow-ons.
+   - Change only what the error requires. No refactors, no dependency upgrades, no new dependencies.
+   - Never silence the error instead of fixing it: no `any` casts, `@ts-ignore`, `# type: ignore`, `#[allow]`, `@SuppressWarnings` or deleted tests unless the user agrees.
+   - Stop and ask the user if the fix needs a dependency change, a config change shared by the team, or a choice between two plausible behaviours.
+5. Re-run the failing command until it passes, then run the tests once to check nothing else broke.
+6. Report: the command, the root cause in one line, the files changed, and the final pass/fail output.
+
+Failing command or error from the user, if any: $ARGUMENTS

package/commands/campaign.md

@@ -0,0 +1,19 @@
+---
+name: campaign
+description: Plan a marketing campaign: audience, positioning, channels, messages, calendar, budget split and success metrics.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: read-only
+  kete-loom/argument-hint: "<product and goal>"
+  kete-loom/owner: "Kete-org"
+---
+
+Use the `marketing-campaign` skill if it is available. Otherwise:
+
+1. Ask for what is missing: the product, the goal (with a number and a date), the audience, the budget, and the channels already working.
+2. Write the plan: audience and the problem it has, positioning in one sentence, two or three key messages, channels with why each fits, a week-by-week calendar, the budget split, and how success is measured.
+3. Point out the riskiest assumption and a cheap way to test it first.
+
+Brief: $ARGUMENTS

package/commands/changelog.md

@@ -0,0 +1,36 @@
+---
+name: changelog
+description: Write changelog entries for the changes since the last release tag, grouped by type, with breaking changes called out first.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[from-ref..to-ref or version]"
+  kete-loom/owner: "Kete-org"
+---
+
+Write changelog entries for the changes since the last release.
+
+If a release tool owns the changelog (release-please, semantic-release, Changesets, git-cliff config in the repo), do not hand-edit `CHANGELOG.md`: show the entries, tell the user which tool generates the file, and stop.
+
+If the `release-management` skill is available, follow only its changelog step (not versioning, tagging or publishing); use the `conventional-commits` skill to read commit types if it is available. Otherwise:
+
+1. Find the range. If the user gave a range or version below, use it. Otherwise use the latest tag: `git describe --tags --abbrev=0`, then `git log <tag>..HEAD --no-merges --format='%h %s%n%b'`. If there are no tags, ask the user where to start and stop.
+2. Classify each commit. With Conventional Commits, map `feat` to Added, `fix` to Fixed, `perf` and `refactor` with user-visible effect to Changed, and anything with `!` before the colon or a `BREAKING CHANGE:` / `BREAKING-CHANGE:` footer to Breaking. Drop `chore`, `ci`, `test`, `style` and `docs`-only commits unless they matter to users. For commits without a type, read the diff to classify.
+3. Rewrite each entry for users: what changed and why it matters, not the commit subject verbatim. Merge commits that are one change.
+4. Match the existing `CHANGELOG.md` format if there is one (for example Keep a Changelog: Added, Changed, Deprecated, Removed, Fixed, Security, with breaking changes marked in the entry); otherwise use:
+
+```
+## [<version or Unreleased>] - <YYYY-MM-DD>
+### Breaking
+- ... Migration: ...
+### Added
+### Changed
+### Fixed
+```
+
+5. Show the entries to the user. Insert them at the top of `CHANGELOG.md` only after they confirm. Do not bump versions, tag or push.
+
+Range or version, if any: $ARGUMENTS

package/commands/checkpoint.md

@@ -0,0 +1,26 @@
+---
+name: checkpoint
+description: Save a restorable snapshot of the working tree after running the project's checks, without committing or changing anything, or list and restore earlier ones.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[name | list | restore <name>]"
+  kete-loom/owner: "Kete-org"
+---
+
+Checkpoints are snapshots stored under `refs/checkpoints/` with `git stash create`, which records the tracked changes without touching the branch, the index or any file.
+
+**Save** (no argument, or a name):
+1. Run the project's checks the way the `verification-loop` skill does (or `/verify`), and report pass or fail. Save the checkpoint either way, but say in its name when checks failed.
+2. Run `git stash create "checkpoint: <name>"`. If it prints nothing, there are no tracked changes; record `HEAD` instead.
+3. Store it: `git update-ref refs/checkpoints/<name> <sha>` (default name: the date and time, like `2026-10-18-1430`).
+4. List untracked files (`git status --porcelain`): a stash snapshot does not include them. Tell the user which files are not covered.
+
+**List** (`list`): `git for-each-ref --sort=-creatordate --format='%(refname:short) %(creatordate:relative) %(subject)' refs/checkpoints/`.
+
+**Restore** (`restore <name>`): first show `git diff --stat` for what is uncommitted now and ask before going further, because restoring on top of uncommitted work can conflict. Then `git stash apply refs/checkpoints/<name>`. Never use `git reset --hard` or `git checkout .` to restore.
+
+Request: $ARGUMENTS

package/commands/codemap.md

@@ -0,0 +1,25 @@
+---
+name: codemap
+description: Write or refresh a short architecture map of the codebase (entry points, modules, data flow, commands) at docs/CODEMAP.md, so agents can orient without reading everything.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "[area to focus on]"
+  kete-loom/owner: "Kete-org"
+---
+
+Create or update `docs/CODEMAP.md` (or the project's existing map if it has one). If the `codebase-onboarding` skill is available, use its exploration steps.
+
+1. Find the entry points (main files, servers, CLIs, workers), the build, test and run commands, and the top-level modules. Read enough of each module to describe it accurately; don't guess from names.
+2. Write the map, under 150 lines:
+   - **Run it**: the commands, one line each.
+   - **Entry points**: `path` and what starts there.
+   - **Modules**: one line per module, `path/` and what it owns; group by layer if the project has layers.
+   - **Data flow**: how a typical request or job moves through the modules, as a short list.
+   - **Where to change things**: common tasks mapped to the files to touch.
+3. If a map already exists, update the parts that are out of date and keep what is still right. Keep paths exact so they stay greppable.
+4. Suggest linking it from AGENTS.md if it isn't already. Don't commit.
+
+Focus, if any: $ARGUMENTS

package/commands/commit.md

@@ -0,0 +1,26 @@
+---
+name: commit
+description: Write a Conventional Commits message for the staged changes, show it, and commit only after the user confirms.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[type, scope or extra context]"
+  kete-loom/owner: "Kete-org"
+---
+
+Commit the staged changes with a Conventional Commits message.
+
+If the `conventional-commits` skill is available, follow it for the message format. Otherwise use `type(scope): summary`, where type is one of feat, fix, docs, style, refactor, perf, test, build, ci, chore or revert, the summary is imperative and under about 72 characters, and a breaking change is marked with `!` before the colon, a `BREAKING CHANGE:` footer, or both.
+
+1. Run `git diff --cached`. If nothing is staged, show `git status` and ask the user what to stage. Do not stage files yourself unless the user asks.
+2. If the staged diff contains secrets, credentials, `.env` files or large build artifacts, stop and warn the user.
+3. If the staged changes do two unrelated things, suggest splitting them and ask before continuing.
+4. Match the repository's existing style from `git log --oneline -20` (scopes in use, casing). Add a body that explains why when the change is not obvious, and any attribution trailers the project or host requires.
+5. Show the full message and wait for the user to confirm or edit it. Never commit before that.
+6. Commit with `git commit -F <file>` or an equivalent that keeps the body intact. Never use `--no-verify`, never amend, and never push. If a hook fails, the commit did not happen: show the output, fix the cause (ask first if the fix goes beyond formatting), re-stage, and commit again.
+7. Print the resulting `git log -1 --stat`.
+
+Extra context from the user, if any: $ARGUMENTS

package/commands/debug.md

@@ -0,0 +1,27 @@
+---
+name: debug
+description: Find the root cause of a bug, failing test or unexpected behaviour by evidence before proposing or making any fix.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "<symptom, error message or failing test>"
+  kete-loom/owner: "Kete-org"
+---
+
+Find the root cause of the problem below before fixing anything.
+
+If the user gave no symptom, ask for the error, the failing test or the steps that reproduce it, and stop.
+
+If the `systematic-debugging` skill is available, follow it. Otherwise:
+
+1. Read the full error and stack trace. Reproduce the failure reliably and write down the exact command or steps.
+2. Check what changed: `git log`, `git diff`, recent dependency or config changes. For a regression, consider `git bisect run <script>`.
+3. Trace the bad value back to where it first goes wrong, adding temporary logging at component boundaries if needed. Compare with similar code that works.
+4. State one hypothesis and test it with the smallest possible change or experiment. If it is wrong, form a new one; do not stack fixes.
+5. State the root cause in one sentence with file:line. To fix it, write a failing test first (`/fix-bug` or the `tdd-workflow` skill). If three fixes in a row fail, stop and question the design with the user.
+
+Report: reproduction, root cause, evidence, proposed fix, and what is still unknown.
+
+Problem from the user: $ARGUMENTS

package/commands/deps-audit.md

@@ -0,0 +1,32 @@
+---
+name: deps-audit
+description: Audit the project's dependencies for known vulnerabilities, abandoned or risky packages and licence problems, and report fixes by severity.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[manifest path or package name]"
+  kete-loom/owner: "Kete-org"
+---
+
+Audit this project's dependencies. Report only; do not upgrade, install or remove anything unless the user asks after seeing the report.
+
+If the `dependency-audit` skill is available, follow its inventory, scan and vetting steps, but stop at the report: skip its fix steps unless the user asks. Otherwise:
+
+1. Find the manifests and lockfiles (`package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `requirements*.txt`, `poetry.lock`, `uv.lock`, `go.mod`, `Cargo.lock`, `Gemfile.lock`, `composer.lock`, `pom.xml`, `build.gradle*`). If there is no lockfile, say that versions are not pinned.
+2. Run the ecosystem's audit tool if installed: `npm audit --json`, `pnpm audit`, `yarn audit` (Yarn 1) or `yarn npm audit` (Yarn 2+), `pip-audit -r requirements.txt` (plain `pip-audit` scans the active environment, not the project), `govulncheck ./...`, `cargo audit`, `bundle-audit check --update`, `composer audit`. For Maven, Gradle or anything else, use `osv-scanner scan source -r .` if installed. These tools query online advisory databases. If a tool is missing, say so and do not install it without asking.
+3. For each finding, check whether the vulnerable code path is reachable from this project (direct vs transitive, dev-only vs runtime). `govulncheck` already reports reachability; for the others, search the codebase for imports of the affected module before marking it reachable.
+4. Flag risky packages too: unmaintained (no release in years, archived repo), typosquat-like names, install scripts, and licences that conflict with the project's.
+5. Report:
+
+```
+## Dependency audit: <scope>
+- [critical|high|medium|low] <package>@<version> (direct|transitive, runtime|dev): <advisory id>. Reachable: yes|no|unknown. Fix: upgrade to <version> | replace | accept with reason.
+Risky packages: ...
+Tools run: <command: result> | not run: <reason>
+```
+
+Do not report advisories you did not get from a tool or an advisory database; never invent CVE ids.
+
+Scope, if any: $ARGUMENTS

package/commands/dual-review.md

@@ -0,0 +1,34 @@
+---
+name: dual-review
+description: Two independent reviewers, optionally on different models or providers, review the same change against one rubric; fix and repeat until both approve or the round limit is hit, then report disagreements.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[scope] [--rounds N] [--models a,b]"
+  kete-loom/owner: "Kete-org"
+---
+
+Run a dual review of the change below. Default: 3 rounds at most.
+
+1. **Scope.** Use the files, commit range or PR in the arguments; otherwise `git diff HEAD` plus untracked files from `git status --short`; if empty, the branch diff against its merge base with the default branch. If there is nothing to review, say so and stop.
+2. **Rubric.** Write one rubric and give it to both reviewers unchanged: correctness, security, error handling, tests for changed behaviour, breaking changes for callers. Each finding needs `path:line`, severity (blocking | should fix | nit) and a concrete fix. Verdict: approve | request changes.
+3. **Reviewers.** Start two reviewers in separate contexts, at the same time, with the same scope and rubric, and never show either the other's output. Use the matching Kete Loom reviewer agent for the language (as `/review` routes: `typescript-reviewer`, `python-reviewer`, `payments-reviewer` and so on), else `code-reviewer`. If `--models` names two models or the host has a second provider configured, run one reviewer on each; otherwise use two separate subagents and say the independence is weaker. If subagents aren't available, tell the user and stop rather than reviewing twice in one context.
+4. **Reconcile.** Merge findings. Mark each as *both*, *A only* or *B only*. Check every single-reviewer finding against the code yourself before acting on it; drop ones you can disprove and note why.
+5. **Fix.** Show the user the blocking and should-fix list and ask before editing. Apply the smallest fix per finding, run the project's tests, and don't touch code outside the scope.
+6. **Repeat.** Re-run both reviewers on the updated diff with fresh contexts. Stop when both approve, at the round limit, or when a round fixes nothing new (the same blocking findings keep coming back); in the last two cases list every unresolved blocking finding under Open. Never weaken the rubric to get an approval.
+
+Report:
+
+```
+## Dual review: <scope>   Rounds: <n>/<max>   Reviewers: <A agent/model>, <B agent/model>
+Verdict: both approve | A approves, B requests changes | both request changes
+Fixed: path:line — issue (found by A|B|both)
+Open: path:line — issue — why not fixed
+Disagreements: <finding> — A says ..., B says ..., your assessment
+Tests: <command> → <result>
+```
+
+Scope and options: $ARGUMENTS

package/commands/epic-decompose.md

@@ -0,0 +1,21 @@
+---
+name: epic-decompose
+description: Break a feature or epic into small, independently shippable issues with acceptance criteria, and create them in GitHub, Jira or Linear after approval.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: network
+  kete-loom/argument-hint: "<epic or feature>"
+  kete-loom/owner: "Kete-org"
+---
+
+Break the epic below into issues that can each be built, reviewed and shipped on their own.
+
+1. Understand the goal. If there is a PRD or spec, read it; if not, ask for the outcome and the constraints, or use the `prd-writing` skill to draft one first.
+2. Use the `estimation-and-scoping` skill to cut it into vertical slices (each one delivers something usable), smallest valuable slice first. Note dependencies and spikes for unknowns.
+3. For each issue write a title, the why, acceptance criteria as a checklist, dependencies, and a size (S, M, L). Show the full list and ask for changes.
+4. **After the user approves**, create them in the tracker the project uses, with the matching skill: `github-api-automation` (or the `gh` CLI), `jira-integration` or `linear-integration`. Link each to the epic and add dependencies. Never create issues before approval.
+5. Report the created issue links.
+
+Epic: $ARGUMENTS

package/commands/explain.md

@@ -0,0 +1,37 @@
+---
+name: explain
+description: Explain how a piece of code or a flow works, tracing it through the codebase with file:line references, without changing anything.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: read-only
+  kete-loom/argument-hint: "<file, symbol or flow>"
+  kete-loom/owner: "Kete-org"
+---
+
+Explain how the code or flow below works. Read only; do not edit files.
+
+If the user named nothing, ask which file, function or flow to explain and stop.
+
+If the `code-tour` skill is available, follow its tracing steps but answer in the reply only; do not write a tour file unless the user asks. Otherwise:
+
+1. Find the starting point: search for the symbol, route, command or file name the user gave.
+2. Trace the path in execution order: entry point, the calls it makes, data it reads and writes, and where it returns or hands off. Read each file you cite.
+3. Note what is surprising: side effects, error paths, config or feature flags that change behaviour.
+4. Answer:
+
+```
+## How <thing> works
+Summary: 2-3 sentences.
+Steps
+1. path:line: what happens here and why.
+2. ...
+Data: what goes in, what comes out, what is stored.
+Gotchas: ...
+Not traced: parts you did not follow, and why.
+```
+
+Cite only lines you read. If behaviour depends on runtime config you cannot see, say so instead of guessing.
+
+Target: $ARGUMENTS

package/commands/feature-dev.md

@@ -0,0 +1,23 @@
+---
+name: feature-dev
+description: Build a feature end to end: plan it, implement it test-first, review it and verify it, stopping for approval between stages.
+license: MIT
+metadata:
+  kete-loom/version: "0.2.0"
+  kete-loom/category: coding
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<the feature>"
+  kete-loom/owner: "Kete-org"
+---
+
+Build the feature below in stages. Stop after each stage, show the result, and wait for the user before starting the next.
+
+1. **Design.** If the feature is more than a small, well-defined change, agree the design first with the `design-brainstorming` skill (one question at a time, two or three approaches, approval per section). Skip this for small changes.
+2. **Plan.** Write the plan with the `implementation-plans` skill, or use the `planner` agent (otherwise plan it yourself): files to touch, tests to add, risks, and anything to ask. Ask the open questions now. For larger work, offer an isolated workspace with the `git-worktrees` skill.
+3. **Build test-first.** Follow the `tdd-workflow` skill: a failing test for each behaviour, the smallest change that passes it, then refactor with the suite green. For a plan with several tasks on a host with subagents, run it with the `subagent-driven-development` skill. Keep to the plan; if the plan turns out wrong, stop and say so.
+4. **Review.** Run `/review` (or the language reviewer agent, or `code-reviewer`) on the change. Fix what it finds that is in scope, and list the rest.
+5. **Verify.** Run the project's checks with the `verification-loop` skill (or `/verify`) and report pass or fail per check.
+
+Finish with a short summary: what changed, the tests added, the checks run, and anything left. Don't commit or push unless the user asks; when they want to wrap up, use the `finishing-a-branch` skill (or `/finish-branch`).
+
+Feature: $ARGUMENTS

package/commands/finish-branch.md

@@ -0,0 +1,26 @@
+---
+name: finish-branch
+description: Finish the current branch - run the checks, confirm the base, then merge locally, open a pull request, keep it or discard it, with cleanup and no force-push or deletion without consent.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[base branch]"
+  kete-loom/owner: "Kete-org"
+---
+
+Finish the work on the current branch.
+
+If the `finishing-a-branch` skill is available, follow it. Otherwise:
+
+1. If the working tree has uncommitted changes, ask what to do with them. Run the project's checks (`/verify`); if any fail, report them and stop.
+2. Confirm the base branch (the one given below, else the repository's default branch), and ask if unsure. Show `git log --oneline <base>..HEAD`.
+3. Offer exactly four choices and wait: merge into the base locally, push and open a pull request, keep the branch as it is, or discard it.
+4. Merge: switch to the base, `git merge <branch>`, re-run the checks, then delete the branch with `git branch -d`. Pull request: `git push -u origin <branch>` and create it as `/pr` does. Keep: change nothing. Discard: list the commits and files that will be lost and require the user to type `discard <branch>` before `git branch -D`.
+5. Remove the branch's worktree (`git worktree remove`, then `git worktree prune`) only after a merge or a confirmed discard; keep it for a pull request.
+
+Never force-push, delete a remote branch or use `--force` without the user's explicit consent.
+
+Base branch from the user, if any: $ARGUMENTS

package/commands/fix-bug.md

@@ -0,0 +1,38 @@
+---
+name: fix-bug
+description: Fix a reported bug by reproducing it as a failing regression test, finding the root cause, making the smallest fix, verifying, reviewing the diff and offering a commit.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "<bug report, issue link or failing behaviour>"
+  kete-loom/owner: "Kete-org"
+---
+
+Fix the bug described below. If no bug was given, ask for the report (what happened, what was expected, how to trigger it) and stop.
+
+1. **Understand.** Restate the bug as: input or steps, expected result, actual result. If you can't, ask the user for the missing detail. Run the existing test suite once; if it already fails, report which tests fail and ask before going on.
+2. **Reproduce as a failing test.** Write a regression test that reproduces the bug exactly as reported, next to the existing tests for that code and in their style. Run it and confirm it fails for the reported reason, not a typo or import error. If the `tdd-workflow` skill is available, follow its red step. If the bug can't be captured in an automated test (timing, environment, external service), write down the manual reproduction, show it failing, and tell the user why there is no test.
+3. **Find the root cause.** Trace from the failing test to where the wrong value first appears; read the code, add temporary logging, or use `git log -L` or `git bisect run <script>` when the bug is a regression (keep the new test in a script or file outside the tracked tree, since older commits don't contain it). Search the codebase for every caller of the function you will change and for the same mistake elsewhere. State the root cause in one sentence before editing. Fix the cause, not the symptom (no special-casing the reported input).
+4. **Smallest fix.** Change only what the root cause requires. No refactors, renames or dependency upgrades in the same change. Never weaken, skip or delete an existing test to get green; if one conflicts with the fix, stop and ask.
+5. **Verify.** Run the new test (now passing), the tests for the changed module and its callers, then the full check set. If the `verification-loop` skill is available, follow it; otherwise run the project's build, lint, type-check and test commands. If the fix touches a shared module, consider the `change-impact-analysis` skill for its consumers.
+6. **Review the diff.** Delegate to the `code-reviewer` agent if it is available (or the reviewer for that language); otherwise read `git diff` yourself for correctness, error paths, and leftover debug code. Remove temporary logging.
+7. **Offer a commit.** Propose a message such as `fix(<area>): <what was wrong>` with the root cause in the body and the issue reference if given. Commit only if the user agrees; never push.
+
+Stop and ask the user if the fix changes documented or public behaviour, needs a data migration or a dependency change, or if three focused attempts haven't found the root cause.
+
+Report:
+
+```
+## Bug fix: <summary>
+Reproduction: <test path::name, or manual steps>
+Root cause: <one sentence, file:line>
+Fix: <files changed: what>
+Verification: <commands> -> <pass/fail counts>
+Review: <findings addressed, or none>
+Commit: <proposed message> (committed: yes/no)
+```
+
+Bug report from the user: $ARGUMENTS

package/commands/hookify.md

@@ -0,0 +1,23 @@
+---
+name: hookify
+description: Turn a rule the agent must never break into an enforced hook: write it in the portable Kete Loom hook format, test it with cases, and show how to register it.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<the rule to enforce>"
+  kete-loom/owner: "Kete-org"
+---
+
+Turn the rule below into a hook that blocks the action, instead of a note that can be forgotten.
+
+1. **Pin down the rule.** Which event it guards (before a shell command, or before a file edit) and exactly what must be blocked. Write 3 or more examples that must be blocked and 3 or more near misses that must be allowed. Confirm them with the user.
+2. **Write the hook** in the Kete Loom format, in `.kete-loom/hooks/<name>/` unless the user picks another folder:
+   - `HOOK.md`: frontmatter with `name`, `description`, `license`, and `metadata` (`kete-loom/version`, `kete-loom/category`, `kete-loom/risk: read-only`, `kete-loom/event`: `pre-shell` or `pre-edit`), plus a short explanation.
+   - `hook.js`: `module.exports = { check }`, where `check({ command, cwd })` or `check({ files: [{ path, content }], cwd })` returns `{ block: true, reason }` or `{ block: false }`. Pure: no network, no writes, no child processes.
+   - `cases.json`: `should_block` and `should_allow` lists from step 1.
+3. **Test it:** run `npx @ketecode/loom check .kete-loom/hooks/<name>` and fix until every case passes.
+4. **Register it** with the current host: show the exact config change for its hook settings (for example a PreToolUse entry in `.claude/settings.json` or `kete.hooks` in `kete.json`) and **apply it only after the user agrees**. Mention that a hook that should help others can be contributed to Kete Loom.
+
+Rule: $ARGUMENTS

package/commands/i18n-check.md

@@ -0,0 +1,39 @@
+---
+name: i18n-check
+description: Check the current UI changes for internationalisation problems such as hard-coded strings, concatenation, plurals, and date or currency formatting.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[files, commit range or locale]"
+  kete-loom/owner: "Kete-org"
+---
+
+Check the current UI changes for internationalisation problems. Report only; do not edit files.
+
+If the `i18n-reviewer` agent is available, delegate to it with the scope below. Otherwise, if the `i18n-localization` skill is available, use it as the checklist. If neither is available:
+
+1. Take the change set from the scope below, or `git diff HEAD` plus untracked files from `git status --short`, or the branch diff against the default branch. Keep only UI code, templates and message catalogs.
+2. Find the project's i18n library and message files, and check the diff for:
+   - user-visible strings not passed through the translation function;
+   - sentences built by concatenating translated pieces instead of one message with placeholders;
+   - plurals done with `count === 1` instead of the library's plural or ICU `plural` support;
+   - dates, numbers and currency formatted by hand instead of `Intl` or the library's formatters;
+   - keys used in code but missing from the source catalog, or keys added to one locale only;
+   - layout that breaks for right-to-left scripts (physical `left`/`right` instead of logical properties) or longer text;
+   - text in images, and `alt` or `aria-label` strings left untranslated.
+3. Confirm each finding by reading the line. Drop anything you cannot point to.
+4. Report:
+
+```
+## i18n check: <scope>
+- [blocking|should fix|nit] path:line: problem. Fix.
+Catalog: missing keys ... | none
+Verdict: ready | needs changes
+```
+
+If there are no UI changes, say so and stop.
+
+Scope, if any: $ARGUMENTS

package/commands/issue-sync.md

@@ -0,0 +1,22 @@
+---
+name: issue-sync
+description: Bring tracked issues in line with the work: find the issues this branch or PR addresses and propose status updates, comments and links, applying them after approval.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: network
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[issue keys or numbers]"
+  kete-loom/owner: "Kete-org"
+---
+
+Bring the issue tracker in line with the current work.
+
+1. Find the issues: the ones named below, plus any referenced in the branch name, commit messages or PR description (for example `#123`, `ABC-45`).
+2. Read each issue and compare it with what the branch actually does: which acceptance criteria are met, which aren't, and what changed in scope.
+3. Propose, per issue: a status change, a short progress comment (what is done, what is left, link to the PR), and any follow-up issue for work that was split off.
+4. **After the user approves**, apply it with the matching skill: `github-api-automation` (or `gh`), `jira-integration` or `linear-integration`. Never close an issue whose acceptance criteria are not all met.
+5. Report what was updated.
+
+Issues: $ARGUMENTS

package/commands/jira.md

@@ -0,0 +1,19 @@
+---
+name: jira
+description: Work with Jira from the agent: find, read, create or update issues with JQL and transitions, asking before any change.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: integrations
+  kete-loom/risk: network
+  kete-loom/argument-hint: "<what to do in Jira>"
+  kete-loom/owner: "Kete-org"
+---
+
+Use the `jira-integration` skill if it is available; it covers authentication, JQL, transitions and custom fields. Otherwise use the Jira Cloud REST API or a configured Jira MCP server.
+
+- Reading and searching need no approval: run the JQL, and show results as key, summary, status and assignee.
+- Creating issues, commenting, transitioning or editing fields: show exactly what will change and **apply it only after the user agrees**.
+- Never put credentials in commands or files; read them from the environment or the MCP server's sign-in.
+
+Request: $ARGUMENTS

package/commands/learn.md

@@ -0,0 +1,23 @@
+---
+name: learn
+description: Turn a lesson from this session into a lasting project rule, in AGENTS.md or a Kete Loom rule, so future sessions don't repeat the mistake.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "[the lesson]"
+  kete-loom/owner: "Kete-org"
+---
+
+Capture a lesson so it sticks.
+
+1. **Find the lesson.** Use the one given below, or the most important correction, surprise or repeated mistake in this session. State it as one concrete rule: "When X, do Y (because Z)". Vague lessons ("be careful") are not worth saving.
+2. **Choose where it lives:**
+   - A project fact or convention → `AGENTS.md` (or `CLAUDE.md` if that is what the project uses), under the most fitting heading.
+   - Guidance for one language or file type → a short rule file the hosts load for those paths (see the Kete Loom rules format: `kete-loom/paths` globs).
+   - Something that must be enforced, not just remembered → suggest `/hookify` instead.
+3. Check it doesn't duplicate or contradict an existing line; update the existing line if it does.
+4. Show the exact text and location, and **write it only after the user agrees**. Don't commit.
+
+Lesson: $ARGUMENTS

package/commands/loom.md

@@ -0,0 +1,21 @@
+---
+name: loom
+description: Find the Kete Loom skills, agents, commands, rules, hooks or MCP servers that fit what you are doing, and show how to install them.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[what you are trying to do]"
+  kete-loom/owner: "Kete-org"
+---
+
+Help the user find the right Kete Loom items for their task. Do not install anything without asking.
+
+1. Read what they want to do (below). If it is empty, use the current repository and conversation as the context.
+2. See what exists: run `npx @ketecode/loom list --json` (or read `catalog.json` if this is the Kete Loom repository). See what is already installed: run `npx @ketecode/loom doctor`.
+3. Pick at most five items that clearly fit, preferring one skill or agent per job. For each, say in one line why it fits. Say plainly if nothing fits.
+4. If the task is "set up this project", run `npx @ketecode/loom audit` and `npx @ketecode/loom profiles` instead, and recommend a profile.
+5. Show the exact install command, for example `npx @ketecode/loom install --skill a,b --agent c`, and ask before running it. Hooks and MCP servers change host configuration, so say so when you suggest them.
+
+What the user is trying to do: $ARGUMENTS