@ketecode/loom 0.0.0-stage → 0.2.0

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

package/commands/postmortem.md

@@ -0,0 +1,42 @@
+---
+name: postmortem
+description: Write a blameless postmortem for an incident, with timeline, impact, root cause, contributing factors and owned action items.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<incident summary, ticket or notes file>"
+  kete-loom/owner: "Kete-org"
+---
+
+Write a blameless postmortem for the incident below.
+
+If the user gave no incident details, ask for a summary, notes or a link and stop.
+
+If the `incident-postmortem` skill is available, follow it. Otherwise:
+
+1. Collect the facts from what the user gave: notes, chat logs, alerts, deploy and commit history (`git log --since=<start> --until=<end>` for the incident window). Do not guess timestamps or numbers; mark unknowns as `TBD`.
+2. Build a timeline in one time zone (state which), from first trigger to full recovery.
+3. Find the root cause and contributing factors by asking "why" until you reach a process or system cause, not a person.
+4. Write:
+
+```
+# Postmortem: <title>
+Date: <date>. Severity: <sev>. Status: draft. Authors: <names>
+## Summary (2-3 sentences)
+## Impact (who, how many, how long, data loss yes/no)
+## Timeline (<time zone>)
+- HH:MM: event
+## Root cause
+## Contributing factors
+## What went well / What went poorly
+## Action items
+| Action | Type (prevent/detect/mitigate) | Owner | Due |
+```
+
+5. Ask where to save it before writing the file.
+
+Blameless means: describe actions and the conditions that made them reasonable, never "X failed to". Remove names from the narrative unless the user asks to keep them. Every action item needs an owner or `TBD`.
+
+Incident: $ARGUMENTS

package/commands/pr-describe.md

@@ -0,0 +1,39 @@
+---
+name: pr-describe
+description: Draft a pull request title and description for the current branch from its commits and diff against the base branch.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/argument-hint: "[base branch or extra context]"
+  kete-loom/owner: "Kete-org"
+---
+
+Write a pull request title and description for the current branch. Do not push or open the pull request unless the user asks.
+
+1. Find the base branch: the one the user named below, otherwise the repository's default branch (`git symbolic-ref --short refs/remotes/origin/HEAD`, falling back to `main`). Run `git fetch` first if you can, and compare against `origin/<base>` so a stale local base branch does not add unrelated commits. Uncommitted changes are not part of the pull request; mention them to the user if `git status` shows any.
+2. Read `git log --oneline <base>..HEAD` and `git diff <base>...HEAD --stat`, then the diff itself for the files that matter.
+3. If the repository has a pull request template (for example `.github/pull_request_template.md`), fill it in instead of the format below.
+4. Write:
+
+```
+Title: <Conventional Commits style summary, under about 72 characters>
+
+## Summary
+What changed and why, in two to four sentences.
+
+## Changes
+- one bullet per meaningful change, not per file
+
+## Testing
+How it was verified: commands run, tests added, manual checks.
+
+## Notes
+Breaking changes, migrations, config or rollout steps, follow-ups. Omit if none.
+```
+
+Describe only what the diff shows. If the purpose is unclear from commits and code, ask the user rather than guessing. Link issues only when the commits or branch name reference them. Add any attribution lines the project or host requires.
+
+Base branch or context from the user, if any: $ARGUMENTS

package/commands/pr.md

@@ -0,0 +1,22 @@
+---
+name: pr
+description: Open a pull request for the current branch: check it is ready, write the title and description, push, and create the PR, asking before anything leaves the machine.
+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: "[base branch] [draft]"
+  kete-loom/owner: "Kete-org"
+---
+
+Open a pull request for the current branch.
+
+1. **Ready?** Make sure the branch is not the default branch, the working tree is clean (or ask what to do with uncommitted changes), and the project's checks pass (`/verify`). If checks fail, stop and report.
+2. **Base.** Use the base given below, or the repository's default branch. Show `git log --oneline <base>..HEAD` and `git diff --stat <base>...HEAD`.
+3. **Title and description.** Write them as `/pr-describe` does: a Conventional Commits style title, what changed and why, how it was tested, and risks. Show them to the user.
+4. **Push and create, after the user agrees.** Push with `git push -u origin <branch>` (never force). Create the PR with the GitHub CLI if it is installed (`gh pr create --base <base> --title ... --body-file ...`, add `--draft` if asked), otherwise give the user the compare URL and the text to paste.
+5. Report the PR URL.
+
+Request: $ARGUMENTS

package/commands/prd.md

@@ -0,0 +1,41 @@
+---
+name: prd
+description: Draft a product requirements document for a feature, with problem, users, requirements, success metrics and open questions.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<feature or problem>"
+  kete-loom/owner: "Kete-org"
+---
+
+Draft a product requirements document (PRD) for the feature below. Do not write implementation code.
+
+If the user gave no feature or problem, ask for one and stop.
+
+If the `prd-writing` skill is available, follow it. Otherwise:
+
+1. Gather context: search the repo for existing docs, related features and any linked issue the user mentioned. Note what you could not find.
+2. Ask the user, in one message, for anything that would change the PRD: target users, the problem evidence, constraints (deadline, platforms, compliance) and how success is measured. If they cannot answer, mark each gap as an open question rather than inventing it.
+3. Write the PRD:
+
+```
+# PRD: <feature>
+Status: draft. Owner: <name or TBD>. Date: <today>
+## Problem
+## Users and use cases
+## Goals / Non-goals
+## Requirements
+- R1 (must): ... Acceptance: ...
+- R2 (should): ...
+## Success metrics (baseline -> target)
+## Risks and dependencies
+## Open questions
+```
+
+4. Ask where to save it (suggest `docs/prd/<feature-slug>.md`) before writing the file.
+
+Never state user research, metrics or dates you were not given; label assumptions as assumptions.
+
+Feature: $ARGUMENTS

package/commands/production-readiness.md

@@ -0,0 +1,45 @@
+---
+name: production-readiness
+description: Audit a service before launch for health checks, observability, rollback, backups, limits, secrets and runbooks, and return a go/no-go list with evidence.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[service path or name]"
+  kete-loom/owner: "Kete-org"
+---
+
+Audit this service for production readiness. Do not edit files and do not run anything that changes infrastructure or data; read the code, config and docs, and run only read-only commands.
+
+1. Find the service: the path or name below, or the repository root. Identify how it is built, deployed (Dockerfile, Kubernetes manifests, Helm, Terraform, CI workflows) and configured.
+2. Check each area, using the matching Kete Loom skill as the standard when it is available:
+   - **Health checks**: liveness and readiness endpoints, wired into the deploy config, readiness checking real dependencies (`kubernetes-patterns`, `deployment-strategies`).
+   - **Observability**: structured logs with trace IDs, RED metrics, traces, SLOs, alerts that link to runbooks, an on-call dashboard (`observability`).
+   - **Rollback**: a tested way back to the previous version, and schema changes that the old version survives (`deployment-strategies`, `database-migrations`).
+   - **Backups**: automated backups of every stateful store, retention, and a restore that has actually been tested.
+   - **Limits**: CPU and memory requests and limits, timeouts and retries with backoff on outbound calls, rate limits, connection pool sizes, autoscaling bounds.
+   - **Secrets**: no secrets in the repo or images, read from a secret store or environment, rotation possible (`security-review` for depth).
+   - **Runbooks and ownership**: an owner, an on-call rotation, a runbook for each paging alert (`runbook-writing`).
+   - **Dependencies and images**: pinned base images, no known critical vulnerabilities (`dependency-audit`, `docker-patterns`).
+3. For deeper infrastructure review delegate to the `infra-reviewer` agent if it is available. If none of the skills are installed, apply the checks above directly.
+4. Mark each item from evidence: a file and line, a command output, or a link. If you cannot find evidence, mark it **unknown**, not pass. Ask the user about anything that lives outside the repo (backup restore tests, on-call rotation).
+
+Return:
+
+```
+## Production readiness: <service>
+Verdict: GO | GO WITH CONDITIONS | NO-GO
+Blockers (must fix before launch)
+- <area>: <finding>. Evidence: <path:line or output>. Fix: <action>
+Conditions (fix within <agreed time> after launch)
+- ...
+Passed
+- <area>: <evidence>
+Unknown (needs an answer from the team)
+- <question>
+```
+
+Any blocker means NO-GO. Health checks, rollback, backups for stateful data and secrets handling are blockers when missing.
+
+Service or focus from the user, if any: $ARGUMENTS

package/commands/project-init.md

@@ -0,0 +1,21 @@
+---
+name: project-init
+description: Set a repository up for coding agents: write or improve AGENTS.md, install the Kete Loom packs for its stack, and fix what the readiness audit flags.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "[focus]"
+  kete-loom/owner: "Kete-org"
+---
+
+Prepare this repository for working with coding agents. Ask before each change.
+
+1. **Audit.** Run `npx @ketecode/loom audit` and show the scorecard.
+2. **Instructions.** If there is no `AGENTS.md` (or `CLAUDE.md`), draft one with the `codebase-onboarding` skill: what the project is, how to build, test and run it (exact commands), the layout, conventions, and what agents must not do. If one exists, propose specific improvements; keep it under a few hundred lines.
+3. **Packs.** Run `npx @ketecode/loom profiles` here and recommend a profile (usually `core`, or `developer` to include the safety hooks). Install it after the user agrees: `npx @ketecode/loom install --profile <name>` (add `--project` to share it with the team through the repository).
+4. **Fix the rest** of the audit's findings that are quick and safe (for example `.gitignore` for `.env`), and list the others.
+5. Run the audit again and report the new score. Don't commit.
+
+Focus: $ARGUMENTS

package/commands/refactor-clean.md

@@ -0,0 +1,24 @@
+---
+name: refactor-clean
+description: Find and remove dead code, unused exports and unused dependencies, verifying with the build and tests after each removal.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[directory or package]"
+  kete-loom/owner: "Kete-org"
+---
+
+Remove dead code without changing behaviour.
+
+If the `refactor-cleaner` agent is available, delegate to it with the scope below. Otherwise:
+
+1. Confirm the working tree is clean or committed, so every removal can be reverted. If it is not, ask the user before continuing.
+2. Run the project's tests once to get a green baseline. If they already fail, stop and report that.
+3. Find candidates with the language's own tools where the project has them (for example `knip` for TypeScript and JavaScript files, exports and dependencies, `vulture` for Python, `staticcheck` (check U1000) or `deadcode` for Go, `go mod tidy` for unused Go modules, compiler and linter unused warnings), and confirm each by searching the whole repository for references.
+4. Treat as not dead, and leave alone unless the user says otherwise: public API of a published package, anything loaded by name (reflection, dependency injection, routes, plugins, CLI entry points, config files), and code used only by tests or scripts. For unused dependencies, also check build config, scripts and dynamic imports before removing them.
+5. Remove in small batches. After each batch run the build and tests; revert the batch if anything fails.
+6. Report: what was removed (path and symbol), what was kept as uncertain and why, and the final build and test result.
+
+Scope from the user, if any: $ARGUMENTS

package/commands/resume-session.md

@@ -0,0 +1,22 @@
+---
+name: resume-session
+description: Resume work from the latest session handoff note, checking it against the repository before taking the next step.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: read-only
+  kete-loom/argument-hint: "[note path or slug]"
+  kete-loom/owner: "Kete-org"
+---
+
+Pick up work from a saved session handoff note.
+
+If the `session-handoff` skill is available, follow its resume steps. Otherwise:
+
+1. Find the note: the path or slug the user gave below, otherwise the note for the current branch, or the most recently updated note, in the project's handoff location (`HANDOFF.md`, `.handoff/` or `docs/handoff/`). If there is none, say so and stop.
+2. Read it, then check it against reality: current branch, last commit and `git status`. Point out anything that changed since the note was written, such as new commits, a different branch or missing uncommitted work.
+3. Summarise for the user in a few lines: the goal, where things stand, and the next step from the note.
+4. Ask the user to confirm before acting on the next step, unless they already asked you to continue. If the note conflicts with the repository state, ask which one to trust.
+
+Note to resume from the user, if any: $ARGUMENTS

package/commands/review.md

@@ -0,0 +1,35 @@
+---
+name: review
+description: Review the current changes for bugs, risky patterns and missing tests, routed to the reviewer for the language that changed.
+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 focus]"
+  kete-loom/owner: "Kete-org"
+---
+
+Review the current changes. Do not edit any files; this is a read-only review.
+
+1. Find the change set. If the user named files or a range below, use that. Otherwise use the staged and unstaged diff against `HEAD` (`git diff HEAD`) plus untracked files from `git status --short`, which `git diff` does not show; if that is empty, use the branch diff against its merge base with the default branch (`git diff $(git merge-base HEAD origin/main)`, adjusting the branch name).
+2. Group the changed files by language from their extensions.
+3. Delegate each group to the matching Kete Loom reviewer agent if it is available: `typescript-reviewer`, `python-reviewer`, `go-reviewer`, `rust-reviewer`, `java-reviewer`, `kotlin-reviewer`, `csharp-reviewer`, `fsharp-reviewer`, `cpp-reviewer`, `swift-reviewer`, `dart-reviewer`, `php-reviewer`, `ruby-reviewer`, `perl-reviewer`. For framework code prefer the specific one (`react-reviewer`, `vue-reviewer`, `flutter-reviewer`, `django-reviewer`, `fastapi-reviewer`); for SQL and migrations use `database-reviewer`; for Dockerfiles, Kubernetes and Terraform use `infra-reviewer`; for payment provider code (Paystack, Stripe, MoMo, M-Pesa webhooks and charges) use `payments-reviewer`; for retrieval and embedding pipelines use `rag-reviewer`; for UI markup add `accessibility-reviewer`. For a security-focused review, use `/security-scan` instead.
+4. If no specific reviewer is available, use the `code-reviewer` agent. If that is missing too, review the diff yourself: correctness first, then security, error handling, tests and readability. Read the surrounding code before reporting, and drop any finding you cannot point to a line for.
+5. Merge the results into one report, most severe first:
+
+```
+## Review: <scope>
+Blocking
+- path:line: problem. Why it matters. Suggested fix.
+Should fix
+- ...
+Nits
+- ...
+Verdict: approve | approve with changes | request changes
+```
+
+If there are no changes to review, say so and stop.
+
+Scope or focus from the user, if any: $ARGUMENTS

package/commands/save-session.md

@@ -0,0 +1,37 @@
+---
+name: save-session
+description: Save a handoff note recording the current goal, progress, decisions and next steps so a later session can resume.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "[note title or focus]"
+  kete-loom/owner: "Kete-org"
+---
+
+Write a session handoff note so this work can be picked up later by you or another agent.
+
+If the `session-handoff` skill is available, follow it. Otherwise:
+
+1. Gather the facts: the goal, what is done, what is in progress, decisions made and why, dead ends tried, and the exact next step. Check `git status` and the recent commits if this is a repository, and note uncommitted work.
+2. Use the location the project already uses for handoff notes (an existing `HANDOFF.md`, `.handoff/` or `docs/handoff/`). If there is none, write `.handoff/<branch-or-topic>.md` at the repo root, creating the folder if needed; update that file rather than adding a new one for the same line of work.
+3. Use this format:
+
+```
+# Session: <title>
+Updated: <YYYY-MM-DD HH:MM, timezone>  Branch: <branch>  Last commit: <short sha>
+## Goal
+## Done
+## In progress
+## Decisions
+## Tried and rejected
+## Next steps
+1. <first concrete action, with file paths and commands>
+## Open questions
+```
+
+4. Never put secrets, tokens or personal data in the note. Ask the user whether the note should be committed or kept local; do not commit it or edit `.gitignore` unless they say so.
+5. Print the path of the note.
+
+Title or focus from the user, if any: $ARGUMENTS

package/commands/security-scan.md

@@ -0,0 +1,32 @@
+---
+name: security-scan
+description: Scan the current change for vulnerabilities, leaked secrets and unsafe dependencies, and report findings by severity.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[files, commit range or area]"
+  kete-loom/owner: "Kete-org"
+---
+
+Run a security review of the current change. Do not edit files; report only.
+
+If the `security-reviewer` agent is available, delegate to it with the scope below. Otherwise, if the `security-review` skill is available, follow it. If neither is available:
+
+1. Take the change set from the scope below, or the diff against `HEAD` plus untracked files, or the branch diff against the default branch.
+2. Check the diff for: injection (SQL, shell, template, path traversal), missing authentication or authorisation checks, unsafe deserialisation, SSRF, secrets or tokens in code or config, weak crypto, sensitive data in logs, and unvalidated input at trust boundaries.
+3. If dependency manifests or lockfiles changed, run the ecosystem's audit command if installed (for example `npm audit`, `pip-audit`, `govulncheck ./...`, `cargo audit`, `bundle-audit check`).
+4. Confirm each finding by reading the code path from input to sink. Drop anything you cannot trace.
+5. Report:
+
+```
+## Security scan: <scope>
+- [critical|high|medium|low] path:line: issue. How it is exploited. Fix.
+Dependencies: audit command and result, or "not run: <reason>".
+Verdict: no issues found | issues found
+```
+
+If you find a live secret, tell the user at the top of the report to rotate it; removing it from the code is not enough.
+
+Scope from the user, if any: $ARGUMENTS

package/commands/sessions.md

@@ -0,0 +1,21 @@
+---
+name: sessions
+description: List the session handoff notes in this repository with their branch, date and next step, and tidy up ones that are finished, only with the user's go-ahead.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "[list | prune]"
+  kete-loom/owner: "Kete-org"
+---
+
+Handoff notes are written by the `session-handoff` skill (or `/save-session`) to `.handoff/<branch>.md`, `HANDOFF.md` or `docs/handoff/`.
+
+**List** (default): find every note in those places. For each, show the path, last modified date, the branch it names, its one-line state, and its first next step. Mark notes whose branch no longer exists (`git branch --list`) or has been merged (`git branch --merged`).
+
+**Prune** (`prune`): propose notes to remove: those for merged or deleted branches, and those untouched for more than 30 days. Show the list and ask before deleting anything. If a note is tracked by git, delete it with `git rm` so the user can review it before committing; never commit on their behalf.
+
+To continue from a note, use `/resume-session`.
+
+Request: $ARGUMENTS

package/commands/skill-create.md

@@ -0,0 +1,21 @@
+---
+name: skill-create
+description: Create a new Agent Skill for a repeated workflow, to the Kete Loom spec, with trigger evals, and check it before use.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/argument-hint: "<the workflow to capture>"
+  kete-loom/owner: "Kete-org"
+---
+
+Use the `skill-authoring` skill if it is available; it has the full method. In short:
+
+1. Capture the workflow: what it does, what "done" looks like, 3 to 5 requests that should load it and 3 to 5 near misses that should not, the steps and the stop-and-ask points. If it is really a one-line rule, suggest `/learn` instead.
+2. Choose the location: the project's skill folder (for example `.claude/skills/<name>/` or `.agents/skills/<name>/`) or, for Kete Loom itself, `skills/<name>/`. Ask if unclear.
+3. Write `SKILL.md` (portable frontmatter, a description that says what it does and "Use when …", a short body) and `evals/triggers.json`.
+4. Check it: `npx @ketecode/loom check <folder>`, and fix every error.
+5. Suggest trying the should-trigger requests in a new session to see it load.
+
+Workflow: $ARGUMENTS

package/commands/tdd.md

@@ -0,0 +1,36 @@
+---
+name: tdd
+description: Implement the requested change test-first, writing one failing test, the smallest code to pass it, then refactoring, step by step.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: testing
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "<feature or bug to implement>"
+  kete-loom/owner: "Kete-org"
+---
+
+Implement the change below test-first.
+
+If the user gave no change, ask for one and stop.
+
+If the `tdd-workflow` skill is available, follow it. Otherwise:
+
+1. Find the test runner and existing tests near the code you will change. Run the suite once; if it already fails, report that and ask before going on.
+2. Break the change into small behaviours. For each one:
+   - Write one test for it and run it. It must fail for the expected reason; if it passes, the test is wrong or the behaviour already exists.
+   - Write the smallest code that makes it pass. Run the tests.
+   - Refactor with the tests green.
+3. For a bug fix, the first test reproduces the bug.
+4. Never weaken, skip or delete an existing test to get green. If one blocks you, stop and ask.
+5. Finish with the full suite and report:
+
+```
+## TDD: <change>
+Tests added: path::name (one line each)
+Code changed: path: what
+Suite: <command> -> <pass/fail counts>
+Not covered: ...
+```
+
+Change: $ARGUMENTS

package/commands/test-coverage.md

@@ -0,0 +1,24 @@
+---
+name: test-coverage
+description: Find untested behaviour in the current change and add focused tests for it, then show the coverage before and after.
+license: MIT
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: testing
+  kete-loom/risk: runs-commands
+  kete-loom/argument-hint: "[files or area to cover]"
+  kete-loom/owner: "Kete-org"
+---
+
+Close the test gaps in the current change.
+
+1. If the `pr-test-analyzer` agent is available, ask it to list the untested behaviour in the current diff, ranked by risk.
+2. If the `test-coverage-improvement` skill is available, follow it to add the tests. Otherwise:
+   - Find the project's test command and coverage command in CI, package scripts or the Makefile. Run the coverage command once to get a baseline.
+   - For each changed function or branch without a test, add a test next to the existing tests, in their style and framework. Cover the error paths and edge cases, not just the happy path.
+   - Test behaviour through the public interface. Do not change production code to make it testable without asking the user first.
+   - Never weaken or delete an existing test, and never write a test that only asserts the code runs.
+3. Run the new tests and the full suite. If a new test fails because the code is wrong, stop and report the bug instead of changing the test to pass.
+4. Report: tests added (file and what each covers), coverage before and after if measured, and any gaps you left with the reason.
+
+Files or area from the user, if any: $ARGUMENTS