@ketecode/loom 0.0.0-stage → 0.2.0

package/skills/brand-strategy/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: brand-strategy
+description: Brand identity strategy run as a structured interview, one question block at a time, covering purpose, positioning against named alternatives, the primary audience and their job to be done, three to five values tied to behaviours, personality traits and a naming brief, then written up as a one-page brand brief with open questions marked. Use when a founder or team is starting or rebranding a company or product and needs its positioning, audience, values and personality decided before voice guides, names, logos or campaigns are made.
+license: MIT
+compatibility: Any Agent Skills host. No tools needed beyond reading what the user shares and writing the brief.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: writes-files
+  kete-loom/owner: "Kete-org"
+---
+
+# Brand strategy
+
+Turn what the founders know (and argue about) into a short brand brief that later work can build on: the `brand-voice` guide, a naming round, a logo brief, a `marketing-campaign` plan. The brief records decisions, not adjectives.
+
+## Ground rules
+
+1. **Interview, don't invent.** Every line in the brief traces to something the user said or chose. Where you propose wording, mark it as a proposal until they accept it.
+2. **One block at a time.** Ask the questions for one block, wait, play back what you heard in two or three lines, then move on. Never send all the questions at once.
+3. **Specific beats aspirational.** "Innovative, trusted, customer-first" fits every company and decides nothing. Push each answer until it would exclude someone or something.
+4. **Name the alternative.** Positioning only means something against what the customer would do instead (a named competitor, a spreadsheet, a cousin who does it for free, doing nothing).
+5. **Evidence over hope.** If an answer about customers is a guess, say so and record it as an assumption to test, not a fact.
+
+## Before you start
+
+Ask for anything that already exists: pitch deck, website, customer interviews, reviews, sales call notes, a competitor list, an earlier brand doc. Read it first and skip questions it already answers; confirm those answers instead of asking again.
+
+Confirm the scope: a company brand, a product brand under a parent, or a rebrand. For a rebrand, ask what is wrong with the current brand and what must survive (name, colour, equity customers recognise).
+
+## The interview
+
+Work through these blocks in order. Each has a goal; the questions are a starting point, so follow up where answers are vague.
+
+1. **Purpose.** Why the business exists beyond revenue, and what changes for customers if it succeeds. Ask: "What would your best customers lose if you shut down tomorrow?" and "What do you refuse to do even if it would make money?"
+2. **Audience.** One primary audience, described by situation and job to be done, not demographics alone. Ask who buys, who uses, who blocks the purchase, what triggers them to look for a solution, and what they use today. If they name three equal audiences, ask which one they would serve if they could only serve one.
+3. **Positioning.** Fill the frame: *For [audience] who [need or trigger], [brand] is the [category] that [key benefit], unlike [named alternative], because [reason to believe].* Ask for the proof behind the "because" (a feature, a number, a process, a founder fact).
+4. **Values.** Three to five values, each with a behaviour that shows it and a trade-off it implies ("Plain speaking: we tell customers about a fee before they find it, even when it costs a sale"). Drop any value nobody can give a behaviour for.
+5. **Personality.** Three to five traits as "this, not that" pairs on sliders (playful to serious, expert to peer, bold to calm). Ask: "If the brand were a person at a dinner party, who would it be, and who would it never be?" This feeds `brand-voice`; do not write the voice guide here.
+6. **Naming brief** (only if a name is needed or under review). Capture what the name must signal, what it must avoid, markets and languages it must work in, the preferred name type (descriptive, invented, metaphor, founder, acronym), length, and must-haves such as a .com or a matching handle. Generate candidates only if asked, and never present one as available.
+7. **Proof and constraints.** Claims the brand can make today with evidence, claims it cannot make yet, regulatory limits on claims in its sector, and existing assets that must be kept.
+
+## Decision rules
+
+- Two founders disagree on a block: record both positions side by side and ask them to choose. Do not average them into a vague middle.
+- The user wants to be everything to everyone: show what each audience would need the positioning to say; usually the conflict makes the choice obvious.
+- No reason to believe exists yet: keep the positioning but list the proof as a gap to build.
+- A value or trait contradicts how the business actually behaves (for example "transparent" with hidden fees): say so plainly and ask which one changes.
+
+## Stop and ask the user
+
+- Before writing the brief, if any of purpose, primary audience or positioning is still undecided.
+- Before suggesting a name be used publicly: trademark clearance and domain checks are needed, and clearance in each market is a job for a trademark professional, not this skill.
+- If a positioning claim is a comparative or health, financial or environmental claim, flag that it may need legal review before it is published.
+
+## Never
+
+- Never fill the brief with stock adjectives the user did not choose.
+- Never claim a name is free to use, trademarked or not, or that a domain is available, without a check the user can see.
+- Never design logos, colour palettes or typography here; write the brief a designer would work from.
+
+## Output: the brand brief
+
+Write one page in Markdown (to a file if the user wants one), in this shape:
+
+```
+# <Brand> brand brief  (v<n>, <date>)
+
+Purpose: <one sentence>
+Primary audience: <situation + job to be done>; secondary: <if any>
+Positioning: For ... who ..., <brand> is the ... that ..., unlike ..., because ...
+Proof: <evidence for the "because">; gaps: <proof still to build>
+Values: <value>: <behaviour> / <trade-off>   (3-5 lines)
+Personality: <this, not that>   (3-5 pairs)
+Naming brief: <must signal / must avoid / markets / type / constraints>  (if in scope)
+Can claim today: ...   Cannot claim yet: ...
+Keep from current brand: ...
+Assumptions to test: ...
+Open questions: ...
+Next: brand-voice guide, naming round, visual identity brief, campaign plan
+```
+
+Close by listing which open questions block the next step, and which items are proposals the user has not yet accepted.

package/skills/brand-strategy/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "We're launching a new fintech startup and haven't decided who we're really for or how we're different. Can you interview us and write a brand brief?",
+    "Help me work out our brand positioning statement against the big banks and mobile money apps",
+    "We're rebranding our bakery chain. Walk us through purpose, values and personality before we hire a designer.",
+    "My co-founder and I disagree on what our brand stands for. Run a structured brand workshop with us.",
+    "Write a naming brief for our new product line so an agency can start generating names"
+  ],
+  "should_not_trigger": [
+    "Create a voice and tone guide with do and don't rewrites for our support team",
+    "Size the market for our school management software in Nigeria with TAM, SAM and SOM",
+    "Plan the four-week launch campaign for our new app with a budget split",
+    "Design a logo and a colour palette for our coffee shop",
+    "Does this homepage copy sound like our brand? Here is the style guide."
+  ]
+}

package/skills/brand-voice/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: brand-voice
+description: Defines a company's written brand voice as three to five attributes with "this, not that" boundaries, paired do and don't rewrites, a preferred and banned vocabulary list and tone shifts by context, then checks or rewrites copy against that guide. Use when a team needs a voice and tone guide, wants marketing, product, support or social copy made consistent, or asks whether a piece of text sounds on-brand.
+license: MIT
+compatibility: Any Agent Skills host. No tools required; reads existing copy, a website or docs the user points to.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: read-only
+  kete-loom/owner: "Kete-org"
+---
+
+# Brand voice
+
+Voice is who the brand is, and stays constant. Tone is how that voice adjusts to the moment. This skill has two modes: **define** a voice guide, or **apply** one to copy.
+
+Ask which mode, or infer it: "create our voice guide" is define; "make this sound like us" or "is this on-brand?" is apply. If applying and no guide exists, offer to define a short one first.
+
+## Define mode
+
+### 1. Gather inputs
+
+1. What the company does, for whom, and its positioning against alternatives.
+2. Audience: who reads the copy and what they need from it.
+3. Existing material: website, app copy, emails, support replies, social posts. Ask for 5-10 pieces the team likes and 2-3 they dislike.
+4. Values or personality words the team already uses.
+5. Markets and languages (formality and humour travel differently).
+
+### 2. Find the voice in the evidence
+
+Read the material the team likes. Note recurring traits: sentence length, formality, humour, jargon, how the reader is addressed, use of "we".
+Compare with the disliked pieces: what exactly is wrong with them?
+
+### 3. Write three to five voice attributes
+
+Each attribute has a boundary so it cannot be misread:
+
+| Attribute | This | Not that | Sounds like |
+|---|---|---|---|
+| Plain-spoken | Short words, direct claims | Blunt, curt | "Your payout lands tomorrow." |
+| Warm | Helpful, human, uses "you" | Gushing, over-familiar | "Thanks for waiting, here's what happened." |
+| Confident | States facts, recommends | Arrogant, salesy | "This plan fits teams of 5-50." |
+
+Rules for attributes: specific enough that two writers would apply them the same way; no generic words without boundaries ("innovative", "professional"); at least one attribute should distinguish the brand from its main competitors.
+
+### 4. Do and don't examples
+
+For each attribute, give at least two pairs of real or realistic lines from the brand's own contexts:
+
+```
+Don't: "We are thrilled to announce our revolutionary new feature!!!"
+Do:    "You can now schedule payouts. Pick a date and we'll handle the rest."
+Why:   Plain-spoken and confident: says what changed and what to do.
+```
+
+### 5. Vocabulary
+
+- **Use**: product names (exact spelling and capitalisation), preferred terms ("customer" vs "user"), phrases that carry the brand.
+- **Avoid**: jargon, clichés ("seamless", "cutting-edge", "game-changer"), words that conflict with the voice, and terms with legal or regulatory weight that need approval (for example "guaranteed", "free", "secure" in regulated industries).
+- **Mechanics**: spelling variant (US or UK), date and currency formats, contractions, emoji policy, capitalisation of headings, punctuation choices (Oxford comma, exclamation marks).
+
+### 6. Tone by context
+
+Show how the voice flexes, with one example line each:
+
+| Context | Tone shift | Example |
+|---|---|---|
+| Marketing / landing page | Most energetic, benefit-led | |
+| Product UI and errors | Brief, calm, tells the user what to do | |
+| Support replies | Patient, specific, owns problems | |
+| Incident or bad news | Serious, direct, no jokes, no spin | |
+| Social | Conversational, can be playful | |
+| Legal / billing | Precise, neutral, plain words | |
+
+Ask the user to confirm the attributes before writing the full guide if the evidence was thin.
+
+### Guide output
+
+```
+# <Brand> voice and tone guide
+## Who we're talking to
+## Our voice in one sentence
+## Voice attributes (table with This / Not that / Sounds like)
+## Do and don't (pairs with why)
+## Vocabulary (use / avoid / mechanics)
+## Tone by context (table)
+## Quick checklist for writers (5-8 yes/no questions)
+```
+
+## Apply mode
+
+1. Load the guide (from the user, the repo, or the one just defined). Do not apply a voice you made up.
+2. Identify the context of the copy (UI, marketing, support...) and the tone that context needs.
+3. Review against each attribute, the vocabulary list and mechanics. Quote each problem line.
+4. Rewrite only what is off-voice. Keep the meaning, facts, claims, legal wording and length constraints (UI strings, character limits) intact.
+5. If a rewrite would change a factual or legal claim, flag it instead of changing it.
+
+### Review output
+
+```
+## Voice review: <piece>
+Verdict: on-brand | mostly on-brand | off-brand
+| # | Line | Issue (attribute or rule) | Suggested rewrite |
+## Revised copy (if requested)
+```
+
+## Rules
+
+- Never copy another company's voice guide or tagline; derive the voice from this brand's own material.
+- Never introduce claims, numbers or promises while rewriting.
+- Keep inclusive, accessible language: no idioms that exclude, no ableist or gendered defaults, reading level suited to the audience.
+- Writing a whole new article is the `article-writing` skill's job; this skill shapes how it sounds.

package/skills/brand-voice/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Create a voice and tone guide for our fintech app, with do and don't examples",
+    "Does this onboarding email sound like us? Here's our style guide and the draft.",
+    "Our website, support macros and app error messages all sound different. Help us define one consistent brand voice.",
+    "Rewrite these push notifications so they match our playful-but-clear brand personality",
+    "Make a list of words our copywriters should use and avoid, plus how tone changes for incident messages"
+  ],
+  "should_not_trigger": [
+    "Write a 2000-word article about the history of mobile money in Ghana",
+    "Design a logo and colour palette for our new brand",
+    "Plan our product launch campaign with channels and a budget",
+    "Check our landing page meta titles and structured data for SEO problems",
+    "Draft the one-pager we send to angel investors"
+  ]
+}

package/skills/browser-qa/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: browser-qa
+description: Exploratory, manual-style QA session on a running web app through a real browser, walking the critical user journeys, abusing forms and validation, spot-checking small screens, keyboard use and contrast, and watching the console and network panel, then filing reproducible bug reports. Use when someone wants a site or staging build clicked through and checked before a release, demo or handover, rather than automated tests written.
+license: MIT
+compatibility: Any Agent Skills host with a browser-control capability (a browser automation tool or MCP server). Without one, produce the test plan and ask the user to run it.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: testing
+  kete-loom/risk: runs-commands
+  kete-loom/owner: "Kete-org"
+---
+
+# Browser QA pass
+
+Act as a careful human tester. You are looking for what a real user would hit, and you prove each problem with exact steps. You do not write automated tests here; if the user wants those, use the `e2e-testing-playwright` skill instead.
+
+## 0. Agree the scope
+
+Before opening the browser, confirm:
+
+1. **The URL** and the environment (local, staging, preview). **Never test against production** with real data or payments unless the user says so explicitly in this conversation.
+2. **Test accounts** and roles. Don't sign up with a real person's email or phone number. If you need an account and have none, **stop and ask**.
+3. **What changed** or what matters most, if anything. Weight the pass toward it.
+4. **What is off limits**: sending emails or SMS, real payments, deleting shared data. When an action would have an external effect you weren't cleared for, stop and ask.
+
+If you have no way to control a browser, write the checklist from steps 1 to 5 and hand it to the user.
+
+## 1. Map the critical journeys
+
+List 3 to 7 journeys from the navigation, the README or the user: for example sign up, log in, log out, password reset, search, create/edit/delete the core object, checkout. Do them first, end to end, on a desktop-size window. Note every journey you could not complete and why.
+
+## 2. Forms and validation
+
+For each important form:
+
+- Submit empty. Each required field should show a clear message tied to that field.
+- Wrong formats: bad email, letters in a number, a date in the past where only future dates make sense, an amount of 0 and a negative one.
+- Boundaries: very long text (500+ characters), emoji and non-Latin text (`Kwame Nkrumah`, `Ɔkɔmfo`, `Zoë`, `日本`), leading and trailing spaces, pasted text.
+- Double submit: click the submit button twice quickly. Exactly one record or charge should result.
+- Server errors: does a failed request show a helpful message and keep what the user typed?
+- Navigation: back button after submit, refresh mid-flow, opening the same flow in two tabs.
+
+## 3. Responsive spot check
+
+Resize to about 375 px wide (phone), 768 px (tablet) and 1280 px (desktop), or use device emulation. On each: no horizontal scrolling, nothing cut off, menus open and close, tap targets are not crammed together, modals fit and can be closed.
+
+## 4. Accessibility spot check
+
+This is a quick screen, not an audit:
+
+- Tab through each journey with the keyboard only. Focus is visible, the order makes sense, nothing traps focus, and Escape closes dialogs.
+- Every input has a visible label; icon-only buttons have an accessible name.
+- Images that carry meaning have alt text.
+- Text contrast looks sufficient, and information is not conveyed by colour alone.
+- Zoom to 200 %: content still usable.
+
+For a full WCAG review, recommend the `accessibility-reviewer` agent or the `web-accessibility` skill.
+
+## 5. Console and network
+
+Keep the console and network log open during every journey.
+
+- Console: uncaught errors, failed hydration, React or Vue warnings, CSP violations, mixed-content warnings.
+- Network: any 4xx or 5xx, requests that take more than a couple of seconds, duplicate requests for the same thing, secrets or personal data in URLs or responses that shouldn't be there.
+- Note which user action produced each one.
+
+## 6. Verify before you report
+
+For each issue: reproduce it a second time from a fresh page load. If it doesn't reproduce, report it as intermittent with what you observed, not as a confirmed bug. Check it isn't caused by your own test data or an expired session.
+
+## Bug report format
+
+One block per bug:
+
+```
+### BUG-<n>: <short title stating the wrong behaviour>
+Severity: blocker | major | minor | cosmetic
+Where: <URL or screen>, <browser and window size>, <account/role>
+Steps:
+  1. ...
+  2. ...
+Expected: ...
+Actual: ...
+Evidence: <console error text, failing request + status, screenshot name>
+Reproduced: 2/2 | intermittent (1/3)
+```
+
+Severity guide: **blocker** stops a critical journey or loses data or money; **major** breaks a feature but has a workaround; **minor** is wrong but low impact; **cosmetic** is visual only.
+
+## Final summary
+
+End with:
+
+1. Environment, browser and build tested, and the time.
+2. A table of journeys with pass / fail / not tested.
+3. Bugs ordered by severity (the blocks above).
+4. What you did not cover (browsers, roles, screens, payments), stated plainly.
+
+Never call a build "ready to ship"; report what you saw and let the user decide.

package/skills/browser-qa/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Can you click through our staging site and find bugs before tomorrow's launch?",
+    "Do a QA pass on the signup and checkout pages at localhost:5173 and write up anything broken",
+    "Smoke test the new dashboard in the browser on mobile and desktop sizes",
+    "Go through the app like a real user and tell me if the forms handle bad input properly",
+    "Check the preview deploy for console errors and failed requests while you use it"
+  ],
+  "should_not_trigger": [
+    "Write Playwright specs for the login and checkout flows",
+    "Do a full WCAG 2.2 accessibility review of our component library",
+    "Our e2e suite is flaky on CI, find out why and fix it",
+    "Measure our Largest Contentful Paint and suggest how to bring it down",
+    "Review the tests added in PR 482 for weak assertions"
+  ]
+}

package/skills/bun-runtime/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: bun-runtime
+description: Working with Bun as a JavaScript runtime, package manager, test runner and bundler, and knowing where it differs from Node and npm, including bun.lock and trustedDependencies, bunfig.toml, bun test with bun:test mocks, bun build and --compile, Bun.serve, automatic .env loading, Node API compatibility gaps, and when to stay on Node. Use when adopting or migrating to Bun, debugging something that works on Node but fails under Bun, setting up bun test or bun install in CI, or deciding whether Bun is a safe choice for a project.
+license: MIT
+compatibility: Any Agent Skills host. Needs the bun CLI. Bun changes quickly; confirm version-specific behaviour against bun.com/docs for the installed version (bun --version).
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "bun"
+  kete-loom/owner: "Kete-org"
+---
+
+# Bun runtime
+
+Bun is four tools in one binary: a runtime (JavaScriptCore, not V8), a package manager, a test runner and a bundler. A project can adopt any of them separately. Decide which ones you are using before changing anything.
+
+## First, look at the project
+
+1. Run `bun --version` and read `package.json`, `bunfig.toml` (if any) and the lockfile name: `bun.lock` (text, Bun 1.2+), `bun.lockb` (older binary format), or another manager's lockfile.
+2. Note what runs in production: Bun, Node, or a serverless platform. The deploy target decides which Bun APIs are safe to use.
+3. Search the code for `Bun.`, `bun:` imports and native addons (`.node` files, `node-gyp`, `prebuild` in dependencies).
+
+Stop and ask the user before switching the production runtime from Node to Bun, or replacing the project's package manager, test runner or bundler. Each is a separate decision.
+
+## Package manager
+
+- `bun install` reads `package.json` and writes `bun.lock`. Commit it; delete other managers' lockfiles only when the team has agreed to switch.
+- Convert an old `bun.lockb` with `bun install --save-text-lockfile --frozen-lockfile --lockfile-only`, then remove `bun.lockb`.
+- CI: `bun install --frozen-lockfile` (or `bun ci`). Bun does not enable frozen mode automatically in CI.
+- **Lifecycle scripts of dependencies do not run** unless the package is listed in `trustedDependencies` in `package.json`. A package that needs a `postinstall` (native builds, binary downloads such as some image, database or browser packages) often fails later at runtime instead of during install. Add it to `trustedDependencies` deliberately and reinstall; never trust everything blindly.
+- Linker: workspaces created on recent Bun default to the `isolated` layout (pnpm-like, no phantom dependencies); single packages and older projects default to `hoisted`. Code that imports an undeclared transitive dependency breaks under `isolated`: declare the dependency rather than switching linker.
+- `bunx <pkg>` is the `npx` equivalent. `bun run <script>` runs `package.json` scripts; CLIs with a `#!/usr/bin/env node` shebang (vite, next) still run under Node unless you use `bun run --bun <script>`.
+
+## Runtime differences from Node
+
+- **TypeScript and JSX run directly** with no build step, but **Bun does not type-check**. Keep `tsc --noEmit` in the check pipeline.
+- **`.env` is loaded automatically** (`.env`, then `.env.<NODE_ENV>`, `.env.local` (skipped when `NODE_ENV=test`), `.env.<NODE_ENV>.local`). This can surprise tools that load env themselves (Vite warns about it) and can leak local values into tests. Use `--env-file <path>` to choose files, or `--no-env-file` / `env = false` in `bunfig.toml` to turn it off.
+- ESM and CommonJS can be mixed in one file, and `require` of ESM works. Code that relies on this will not run on Node; keep shared libraries Node-compatible.
+- Bun-only APIs: `Bun.serve`, `Bun.file`, `Bun.write`, `Bun.spawn`, `Bun.password`, `bun:sqlite`, `bun:ffi`. Use them only in code that will never run on Node; otherwise use `node:` modules.
+- Native addons: N-API addons generally work; addons that use V8's C++ API directly do not, because there is no V8.
+- `Bun.serve({ fetch(req) { ... } })` uses web `Request`/`Response`. Express and Fastify also run on Bun through its `node:http` implementation; benchmark before assuming a speed-up for your workload.
+
+## Known Node compatibility gaps
+
+Bun publishes a per-module compatibility page (bun.com/docs/runtime/nodejs-compat). Check it for the installed version before relying on any of these. Gaps that commonly matter:
+
+| Area | What breaks |
+|---|---|
+| `async_hooks.createHook` | Stubbed; APM/tracing agents that depend on it lose context. `AsyncLocalStorage` itself works. |
+| `node:v8`, `node:inspector` | Partial: `v8.serialize` uses JavaScriptCore's format, and the inspector covers only some domains. Profilers and heap tools written for V8 may not work. |
+| `node:crypto` | Partial: Bun uses BoringSSL, so some algorithms and APIs are missing. Test the exact algorithm you need on Bun. |
+| `node:cluster` | Partial: HTTP servers in workers each bind their own socket, so do not assume Node's load balancing. |
+| `node:test` | Partial: works only when files run under `bun test`; prefer `bun:test`. |
+| `node:sea` | Not supported; use `bun build --compile`. |
+
+When something works on Node but fails on Bun: reproduce with a minimal script on both, check the compatibility page and Bun's issue tracker, then either work around it or keep that piece on Node. Never patch `node_modules`.
+
+## bun test
+
+- Discovers `*.test.*`, `*_test.*`, `*.spec.*`, `*_spec.*`. Import from `bun:test`: `test`, `describe`, `expect`, `beforeEach`, `mock`, `spyOn`.
+- Jest-compatible but not complete: `jest.fn()` works, `mock.module('pkg', () => ({ ... }))` replaces a module, but some Jest matchers and config options are missing. When migrating, run the whole suite and fix gaps one by one; do not mix Jest and `bun test` on the same files.
+- Setup files: `bun test --preload ./test/setup.ts`, or `[test] preload = ["./test/setup.ts"]` in `bunfig.toml`. DOM tests need a preload that registers happy-dom (`@happy-dom/global-registrator`).
+- Useful flags: `--watch`, `--coverage` (`--coverage-reporter=lcov` for CI), `--timeout <ms>` (default 5000), `-u` to update snapshots, `--bail`.
+- Bun runs test files in a single process by default: tests that mutate globals, env or `mock.module` state leak into other files. Restore mocks in `afterEach`, or pass `--parallel` to spread files across CPU cores (check that your Bun version has this flag).
+
+## bun build
+
+- `bun build ./src/index.ts --outdir dist --target node|bun|browser`. Add `--minify`, `--sourcemap=linked`, `--splitting`, `--external <pkg>` as needed. JS API: `await Bun.build({ entrypoints, outdir, target })`.
+- It does not emit `.d.ts` files; libraries still need `tsc --emitDeclarationOnly`.
+- `bun build --compile ./src/cli.ts --outfile mycli` makes a standalone executable with the runtime embedded (large binary, but no install step for users).
+- For browser apps with HMR, dev server and framework plugins, a dedicated tool (Vite, see the `vite-patterns` skill) is usually the better fit.
+
+## When not to use Bun
+
+Recommend staying on Node (or keeping Node in production while using Bun for install/test) when:
+
+- The service depends on an APM, profiler or tracing agent that needs V8 or `async_hooks` hooks.
+- It uses native addons built against V8, or crypto primitives BoringSSL lacks.
+- The hosting platform has no first-class Bun runtime and a custom runtime is not acceptable to the team.
+- The team needs long-term-support guarantees comparable to Node LTS.
+- A library the project depends on documents Bun as unsupported.
+
+## Never
+
+- Commit both `bun.lock` and another manager's lockfile as sources of truth.
+- Add every dependency to `trustedDependencies` to make an install error go away.
+- Use `Bun.*` APIs in a package published for Node users.
+- Drop `tsc` because "Bun runs TypeScript".
+
+## Report
+
+When asked to evaluate or migrate, return: what was switched (runtime / package manager / tests / bundler), commands now used for install, test, build and start, any compatibility gap found and its workaround, and the test and type-check results on Bun.

package/skills/bun-runtime/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Migrate our Jest suite to bun test and get mock.module working",
+    "This package's postinstall never ran after bun install, the native binary is missing",
+    "Is it safe to run our production API on Bun? We use Datadog tracing",
+    "Our app works on Node but crashes under Bun with a crypto curve error",
+    "Make a single-file executable of our CLI with bun build --compile"
+  ],
+  "should_not_trigger": [
+    "Add graceful shutdown and rate limiting to our Express service running on Node",
+    "Configure Vite library mode to publish our component package",
+    "Set up Vitest for our TypeScript utilities package",
+    "Write a GitHub Actions workflow that runs npm ci and the tests",
+    "Fix the circular dependency between two NestJS modules"
+  ]
+}

package/skills/change-impact-analysis/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: change-impact-analysis
+description: Blast-radius analysis for a code change, built from the real dependency graph rather than guesswork, using import search, the build graph and monorepo tooling (nx affected, turbo --affected, bazel query rdeps, go list, pnpm filters, Maven -amd, Gradle buildDependents) to find downstream consumers, then running the tests of changed modules and every dependent, and reconciling the predicted impact against the actual diff. Use when asked what a change could break, which packages or services consume a module, which tests must run for a diff, or whether a shared library edit is safe to merge.
+license: MIT
+compatibility: Any Agent Skills host. Needs git and the project's own build or test tooling; monorepo commands apply only where that tool is already in use.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/owner: "Kete-org"
+---
+
+# Change impact analysis
+
+Answer "what can this change break?" with evidence: a list of consumers found from the dependency graph, the tests that cover them, and the results of running those tests. Never answer from intuition alone.
+
+## When to run it
+
+- **Before** a change: predict impact so the plan and the review cover every consumer.
+- **After** a diff exists: compute actual impact, run the affected tests, compare with the prediction.
+- Both, for shared libraries, public APIs, database schemas, config keys and anything published.
+
+## 1. Pin down the change
+
+1. Get the changed files: `git diff --name-only <base>...HEAD` (base is usually `origin/main`; use the merge base, not the tip). Include untracked files from `git status --short`.
+2. For each file, list the changed **symbols**: exported functions, classes, types, routes, events, CLI flags, env vars, config keys, DB columns, message schemas. A file-level graph over-reports; symbols tell you which consumers really care.
+3. Classify each symbol change: internal only, signature change, behaviour change with the same signature, removal, or new addition. Additions rarely break consumers; behaviour changes are the ones people miss.
+
+## 2. Build the consumer graph from the tooling the repo already has
+
+Detect the build system first (look for `nx.json`, `turbo.json`, `WORKSPACE`/`MODULE.bazel`, `go.mod`, `pnpm-workspace.yaml`, `pom.xml`, `settings.gradle(.kts)`, `Cargo.toml` workspaces). Use the tool's own graph; it knows about generated code and path aliases that grep misses. Commands are in `references/graph-commands.md`.
+
+- **Monorepo tool present**: ask it for affected projects between base and head (for example `nx show projects --affected -t test --base=origin/main`, `turbo run test --affected`, `bazel query "rdeps(//..., //pkg:target)"`).
+- **No graph tool**: search the codebase for imports of the changed module and for each changed symbol name, then repeat one level up for every hit until no new consumers appear. Note this is a search result, not a graph.
+- **Outside the code graph** (tools can't see these, search for them by name):
+  - string-keyed references: route paths, event or queue names, feature-flag keys, env vars, config keys, SQL column names, reflection and dependency-injection names;
+  - other repositories, deployed services, mobile apps on old versions, and third parties that call a public API;
+  - generated clients, fixtures, snapshots, docs and examples that embed the old shape;
+  - CI, deploy and infrastructure files that reference changed paths.
+
+## 3. Rate the blast radius
+
+For each consumer record: name, how it depends (import, HTTP, event, schema, config), what it uses, and risk:
+
+| Risk | Meaning |
+|---|---|
+| High | Uses a removed or changed signature or behaviour; deployed separately; no tests cover the usage |
+| Medium | Uses the changed symbol, tests exist and will run |
+| Low | Depends on the package but not on the changed symbols |
+
+**Stop and ask the user** when a High consumer is outside this repository, when the change touches a published package, public API, database schema or message format, or when the graph says more than about 20 projects are affected (confirm the change should be split or staged).
+
+## 4. Run the affected tests
+
+1. Run the tests of the changed modules first, then every downstream consumer. Use the tool's affected mode (`nx affected -t test`, `turbo run test --affected`, `bazel test` on the rdeps test set, `go test` on the reverse-dependency packages, `mvn -pl <module> -amd verify`, `./gradlew :<module>:buildDependents`).
+2. Inside a single package, narrow with the runner's related-test mode where it exists (`jest --findRelatedTests <files>`, `vitest related <files> --run`, `pytest --testmon` if pytest-testmon is installed), and still run the full package suite before calling it safe.
+3. Include type-checks and builds of consumers; a signature change often breaks compilation, not tests.
+4. If a consumer has **no** test touching the changed symbol, list it as a coverage gap. Do not report it as safe.
+5. Shallow CI clones make affected detection treat everything as changed or nothing as changed; fetch enough history for the base.
+
+## 5. Reconcile planned vs actual
+
+After the diff is final, rerun step 1 and step 2 and compare with the prediction:
+
+- Files or symbols changed that the plan didn't mention: explain each or flag it as scope creep.
+- Consumers predicted but not actually affected: fine, note them.
+- Consumers affected but not predicted: these are the important ones; run their tests and add them to the review.
+
+## Never
+
+- Never declare a change safe because one package's tests pass.
+- Never skip consumers outside the build graph because the tool didn't list them.
+- Never edit consumers to make the analysis pass without telling the user; that's a new change.
+
+## Report
+
+```
+## Impact: <change>
+Base: <ref>  Head: <ref>
+Changed symbols: <symbol> (<kind of change>) ...
+Consumers
+- <name> | via <import/http/event/schema/config> | uses <symbol> | risk High/Med/Low | tests: <ran: pass/fail | none>
+Outside the graph: <string-keyed refs, other repos, external callers, or "none found">
+Commands run: <command> -> <result>
+Coverage gaps: <consumer: what is untested>
+Planned vs actual: <unplanned changes, unpredicted consumers, or "matches">
+Verdict: safe to merge | merge after <action> | needs staged rollout or split
+```

package/skills/change-impact-analysis/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "I changed the signature of formatCurrency in packages/shared-utils. Which apps in the monorepo use it and could break?",
+    "What's the blast radius of renaming the user_status column? Find every consumer before I merge.",
+    "Run nx affected for my branch and tell me which downstream projects need testing",
+    "Before I bump the logging library interface, map every service and package that depends on it and run their tests",
+    "My diff ended up touching more than I planned. Compare what I expected to affect against what actually changed."
+  ],
+  "should_not_trigger": [
+    "Break this feature request into ordered implementation steps before I start coding",
+    "Rename the parseDate helper across the codebase without changing behaviour",
+    "Run lint, type-check and the test suite before I open a pull request",
+    "Scan our npm dependencies for known vulnerabilities",
+    "Explain how this repository is structured, I just cloned it"
+  ]
+}

package/skills/change-impact-analysis/references/graph-commands.md

@@ -0,0 +1,28 @@
+# Dependency graph commands by build system
+
+Use only the tool the repository already uses. Check flags against the installed version with `--help`.
+
+| Tool | Affected or reverse-dependency query | Run affected tests |
+|---|---|---|
+| Nx | `nx show projects --affected -t test --base=origin/main --head=HEAD`; `nx graph --affected` to view | `nx affected -t test --base=origin/main --head=HEAD` (or set `NX_BASE` / `NX_HEAD`) |
+| Turborepo | `turbo run test --affected --dry-run` lists tasks; `--filter=...[origin/main]` selects changed packages and their dependents | `turbo run test --affected` (base defaults to `main`; override with `TURBO_SCM_BASE`, head with `TURBO_SCM_HEAD`) |
+| Bazel | `bazel query "rdeps(//..., //path/to:target)"`; tests only: `bazel query "kind('.*_test', rdeps(//..., //path/to:target))"` | `bazel test $(bazel query "kind('.*_test', rdeps(//..., //path/to:target))")` |
+| Go modules | No built-in reverse lookup. `go list -test -f '{{.ImportPath}} {{join .Deps " "}}' ./... \| grep -E ' <changed/import/path>( \|$)' \| awk '{print $1}' \| grep -v '\.test$' \| sort -u` lists packages whose code or tests depend on it directly or transitively; add the changed package itself | `go test <listed packages>` plus `go vet` |
+| pnpm workspaces | `pnpm --filter "...[origin/main]" list --depth -1` (changed packages and their dependents); `pnpm --filter "...<pkg>"` for one package | `pnpm --filter "...[origin/main]" test` |
+| Maven | `mvn -pl <module> -amd validate` prints the dependents in the Reactor Build Order (don't pass `-q`, it hides that list) | `mvn -pl <module> -amd verify` |
+| Gradle | No built-in reverse-dependency listing; `buildDependents` runs them | `./gradlew :<module>:buildDependents` (builds and tests the project and every project that depends on it) |
+| Cargo workspace | `cargo tree -i <crate> --workspace` (inverted tree) | `cargo test -p <crate> -p <each dependent>` |
+| Python (no monorepo tool) | Search imports: `git grep -nE "^(from\|import) <package>"`; `pipdeptree -r -p <dist>` for installed distributions | `pytest <dirs>`; `pytest --testmon` with pytest-testmon for test-level selection |
+
+## Related-test modes inside one package
+
+- Jest: `jest --findRelatedTests <changed files>`, `jest --changedSince=origin/main`
+- Vitest: `vitest related <changed files> --run`, `vitest --changed origin/main`
+- Go: `go test ./<pkg>/...` is already scoped; there is no file-level mode.
+
+These follow static imports only. Dynamic imports, string-keyed lookups, DI containers and reflection need a codebase search.
+
+## CI notes
+
+- Fetch enough history to contain the merge base (`fetch-depth: 0`, or a blobless clone with `--filter=blob:none`); a too-shallow clone makes turbo treat every package as changed.
+- Use the last green commit on the default branch as the base when the tool supports it (Nx recommends this).