@ketecode/loom 0.0.0-stage → 0.1.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/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/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/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,22 @@
+---
+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.1.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 four stages. Stop after each stage, show the result, and wait for the user before starting the next.
+
+1. **Plan.** Use the `planner` agent if available (otherwise plan it yourself): files to touch, tests to add, risks, and anything to ask. Ask the open questions now.
+2. **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. Keep to the plan; if the plan turns out wrong, stop and say so.
+3. **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.
+4. **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.
+
+Feature: $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

package/commands/loop.md

@@ -0,0 +1,20 @@
+---
+name: loop
+description: Run a bounded autonomous loop toward a goal, with a stop condition, a budget and a check after every iteration.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<goal> [max iterations]"
+  kete-loom/owner: "Kete-org"
+---
+
+Use the `autonomous-loops` skill if it is available. Otherwise:
+
+1. **Set the frame before starting**, and confirm it with the user: the goal, how success is checked (a command that passes, a number reached), the maximum iterations (default 5), and what the loop may not touch.
+2. **Each iteration:** make one focused change toward the goal, run the check, and record one line: what changed, the check result, and the next step.
+3. **Stop** when the check passes, the iteration limit is reached, two iterations in a row make no progress, or something needs a decision the user hasn't made (stop and ask). Never widen the scope to keep going.
+4. **Report** the iterations, the final check result, and anything left unresolved.
+
+Goal: $ARGUMENTS

package/commands/model-route.md

@@ -0,0 +1,27 @@
+---
+name: model-route
+description: Recommend which model tier to use for a task (fast, balanced or most capable), weighing complexity, risk and cost, and say how to switch in this host.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: ai
+  kete-loom/risk: read-only
+  kete-loom/argument-hint: "<the task>"
+  kete-loom/owner: "Kete-org"
+---
+
+Recommend a model tier for the task below. Don't switch models yourself.
+
+Judge the task on three things, briefly:
+- **Complexity**: how much reasoning, how many files, how much ambiguity.
+- **Risk**: what a mistake costs (security, money, data, production, or a throwaway script).
+- **Volume**: one careful pass, or many repetitive calls.
+
+Then recommend one tier:
+- **Fast and cheap** for mechanical, well-specified or high-volume work: renames, formatting, boilerplate, simple lookups, bulk classification.
+- **Balanced** for everyday feature work and debugging with clear tests.
+- **Most capable** for design decisions, subtle bugs, security or payment code, large refactors and anything hard to undo.
+
+Give the recommendation in two or three lines with the reason, name the host's current models in that tier if you know them, and say how to switch here (for example the host's model command or setting). If the task mixes both kinds of work, suggest splitting it.
+
+Task: $ARGUMENTS

package/commands/onboard.md

@@ -0,0 +1,35 @@
+---
+name: onboard
+description: Get oriented in an unfamiliar codebase: what it does, how it is laid out, how to build, test and run it, and where to start.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[area or question to focus on]"
+  kete-loom/owner: "Kete-org"
+---
+
+Orient in this codebase and give the user a short map of it. Do not change any files.
+
+If the `codebase-onboarding` skill is available, follow it. Otherwise:
+
+1. Read the README, contributing guide, agent instruction files (such as `AGENTS.md` or `CLAUDE.md`) and the main manifest (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml` and similar).
+2. Map the top-level layout and find the entry points: main binaries, servers, CLI commands, route definitions.
+3. Find the build, test, lint and run commands from CI workflows, package scripts or the Makefile. Run the test command only if it is fast and safe; never run deploy, migration or release commands.
+4. Trace one representative request or command end to end through the code.
+5. Report:
+
+```
+## <project name>
+What it does: one or two sentences.
+Stack: languages, frameworks, datastores.
+Layout: top-level folders and what each holds.
+Commands: build, test, lint, run (and whether you ran them).
+How a request flows: entry point -> ... -> result, with file paths.
+Conventions: patterns and rules to follow here.
+Start here: three files to read first.
+Unknowns: what you could not determine.
+```
+
+Area or question from the user, if any: $ARGUMENTS

package/commands/orchestrate.md

@@ -0,0 +1,21 @@
+---
+name: orchestrate
+description: Split a large task into independent pieces, run them in parallel subagents, then verify and merge their results.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<the task>"
+  kete-loom/owner: "Kete-org"
+---
+
+Use the `parallel-agent-orchestration` skill if it is available. Otherwise:
+
+1. **Split.** Break the task into pieces that don't edit the same files and don't depend on each other's output. If it doesn't split cleanly, say so and do it in one pass instead.
+2. **Contract.** For each piece, write what it must do, which files it may touch, and exactly what it must return (for example a list of changed files and a one-line summary). Show the plan and ask before starting.
+3. **Run.** Start one subagent per piece in parallel, using this host's way of delegating work. Give each its contract and nothing it doesn't need.
+4. **Verify and merge.** Read every result; never trust a summary without checking the files. Resolve overlaps, then run the project's checks once over the combined change.
+5. **Report** per piece: done, failed or partly done, and what remains.
+
+Task: $ARGUMENTS

package/commands/plan-feature.md

@@ -0,0 +1,36 @@
+---
+name: plan-feature
+description: Turn a feature request into a step-by-step implementation plan with files to touch, risks and tests, without writing code.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: read-only
+  kete-loom/argument-hint: "<feature description>"
+  kete-loom/owner: "Kete-org"
+---
+
+Plan the feature below. Do not write or edit code; the output is a plan for the user to approve.
+
+If the user gave no feature description, ask for one and stop.
+
+If the `planner` agent is available, delegate to it with the feature description. If the feature changes system boundaries or adds a new service, also ask the `architect` agent for the design first. Otherwise:
+
+1. Search the codebase for the code the feature touches: entry points, data models, existing patterns to reuse, and the tests around them.
+2. List open questions. If any would change the design (scope, data shape, who calls it), stop and ask the user before planning further.
+3. Write the plan:
+
+```
+## Plan: <feature>
+Goal: one sentence. Out of scope: ...
+Steps
+1. <change> in <path>. Done when: <check>.
+2. ...
+Tests: what to add and where.
+Risks: migrations, breaking API changes, performance, security. Mitigation for each.
+Open questions: ...
+```
+
+Keep each step small enough to land and verify on its own, in an order where the build passes after every step.
+
+Feature: $ARGUMENTS