@ketecode/loom 0.0.0-stage → 0.1.0

package/skills/cold-outreach-sequences/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: cold-outreach-sequences
+description: Plans, writes and runs B2B cold outreach sequences to prospects who have not opted in - picking an ideal customer profile and a narrow segment, researching a genuine reason to write to each person, drafting short multi-touch email and LinkedIn steps with sensible spacing, staying within CAN-SPAM, GDPR and PECR, and judging results by positive replies and meetings rather than opens. Use when a founder or sales team wants an outbound prospecting sequence written or reviewed, asks why cold emails get no replies, or needs to know whether emailing a bought list of business contacts is allowed.
+license: MIT
+compatibility: Any Agent Skills host. Works from the user's prospect list, product notes and sending tool; it writes copy and plans and does not send email itself.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: read-only
+  kete-loom/owner: "Kete-org"
+---
+
+# Cold outreach sequences
+
+Write to a small number of well-chosen people with a reason that is true for each of them, ask for one easy next step, stop when they say no, and measure what actually produces meetings.
+
+This skill gives working rules, not legal advice. For anything beyond routine B2B prospecting (consumer lists, health or financial data, a regulator complaint, a new country), the user must check with a qualified privacy lawyer.
+
+## Ground rules
+
+1. **Narrow beats big.** One segment per sequence: a role, a company type and a trigger (hiring for X, just raised, new regulation, uses tool Y). If you cannot say why this group needs the product now, stop and ask the user.
+2. **Personalisation must be real and checkable.** Reference something the person or company actually did or published, with the source noted. Never invent a mutual connection, a compliment, a past conversation or a "saw your post" you have not seen. A merge field with their company name is not personalisation.
+3. **One ask, small.** A reply, a 15-minute call, or permission to send something. No calendar link in the first email unless the user insists.
+4. **Short.** First email under about 120 words, plain text, no images or attachments, at most one link. Follow-ups shorter.
+5. **Stop on any reply** that is negative, an out-of-office with a leaving date, or a request to stop. Suppress them across every tool and sender.
+6. **Protect the main domain.** Cold mail goes from a separate, authenticated domain or subdomain at modest daily volume per mailbox. Setting up SPF, DKIM, DMARC and warm-up belongs to the email-deliverability skill.
+
+## Compliance checks (before any copy)
+
+Ask where recipients are based and where the sender is based, then apply each that fits:
+
+| Rule | What it requires for cold B2B email |
+|---|---|
+| US CAN-SPAM | No B2B exemption. Truthful From, Reply-To and routing headers; a subject that matches the content; identify the message as an ad where it is one; a valid physical postal address; a clear opt-out that works for at least 30 days, honoured within 10 business days, with no fee or login. |
+| EU GDPR | A named work address is personal data. Most cold B2B outreach relies on legitimate interests: write a short legitimate-interests assessment, keep only data needed, tell them where you got their details (Article 14) no later than the first message you send them, and honour objections at once (Article 21). Country e-privacy laws vary; some require prior consent even for B2B. Germany's UWG § 7(2) No. 2 requires prior express consent for email advertising to any addressee, business or consumer (the § 7(3) existing-customer exception aside). |
+| UK PECR + UK GDPR | Emailing corporate subscribers (limited companies, LLPs, public bodies) without consent is allowed if you identify yourself and give an opt-out. Sole traders and some partnerships count as individuals and need consent. UK GDPR still applies to named work addresses. The ICO says this guidance is under review after the Data (Use and Access) Act 2025; check the current version at ico.org.uk. |
+| Canada CASL | Stricter: generally needs consent. Implied consent has narrow cases, such as an address the person conspicuously published without a "no unsolicited messages" statement, where the message is relevant to their business role (CASL s. 10(9)(b)). Stop and ask the user to confirm with counsel before emailing Canadian prospects. |
+
+**Stop and ask the user** if the list was bought or scraped and its source is unknown, if it contains personal (non-work) addresses, or if recipients are consumers. Do not write a sequence for those until the user confirms the legal basis.
+
+## Steps
+
+1. **Define the segment.** Write the ICP in one line, the trigger, the problem they likely have, and the proof you have (customer result, number, named customer the user may cite). Ask the user for proof if there is none; never make up results.
+2. **Check the list.** Required fields: name, role, company, work email, source, country, and one research note per person. Remove role addresses (`info@`, `sales@`), personal addresses, existing customers, open deals and anyone on the suppression list. Verify addresses with the user's verification tool before sending.
+3. **Research each prospect** for 2 to 5 minutes: recent company news, job posts, their own posts or talks. Record one fact and its URL. If nothing relevant turns up, use the segment-level trigger honestly instead of faking a personal line.
+4. **Write the sequence.** Default shape (adjust to the user's market):
+
+| Step | Day | Channel | Purpose |
+|---|---|---|---|
+| 1 | 0 | Email | Specific reason, the problem, one proof point, small ask |
+| 2 | 3 | Email (same thread) | One new angle or useful resource, no "just bumping this" |
+| 3 | 7 | LinkedIn (view, then connection request with no pitch) | Familiarity, optional |
+| 4 | 10 | Email | Short case or number relevant to their trigger |
+| 5 | 17 | Email | Polite close: "should I stop writing about this?" |
+
+   Four or five touches over two to three weeks is enough. Send on weekdays in the prospect's time zone.
+5. **Write each email** as: subject (2 to 5 words, lower-case is fine, no clickbait or "Re:" on a first message), opening line from the research note, one sentence on the problem in their words, one proof sentence, the ask, signature with the sender's real name, company, postal address and an opt-out line.
+6. **Review every draft** against the checklist below before handing it over.
+7. **Run a pilot** of 50 to 100 prospects. Change one thing at a time (segment, opening, offer) between batches.
+8. **Measure.** Track per step and per segment: delivered, bounced, replied, positive replies, meetings booked, opt-outs. Ignore open rates (Apple Mail Privacy Protection and image blocking make them unreliable). Rules of thumb (not provider or legal limits): bounce rate above about 3% suggests the list is bad; positive replies under about 1% after 200 sends suggests the segment or offer is wrong, not the wording.
+
+## Draft checklist
+
+- Is the personal line true, and is its source recorded?
+- Could this email be sent unchanged to 1,000 other people? If yes, rewrite.
+- One ask only? No attachments, tracking-heavy links or images?
+- Sender identity, postal address and opt-out present?
+- Any claim, number or customer name the user has not confirmed? Remove it.
+- No fake urgency, fake "Re:" or "Fwd:", or guilt-tripping in the break-up email.
+
+## Never
+
+- Send from the company's main domain at volume, or rotate many lookalike domains to dodge spam filters.
+- Keep emailing someone who asked to stop, or re-add them through another tool or sender.
+- Scrape personal data in breach of a site's terms, or guess personal email addresses.
+- Automate LinkedIn connection requests or messages beyond what LinkedIn permits.
+
+## Output format
+
+```
+Segment: role / company type / trigger        Region(s): ...   Legal basis: ...
+Proof points used: ... (user-confirmed)
+Sequence: step, day, channel, subject, body (per step)
+Personalisation notes: prospect -> fact -> source URL
+Compliance: footer text, opt-out method, suppression handling
+Pilot plan: batch size, what is being tested, metrics and thresholds
+Open questions for the user: ...
+```
+
+Primary sources: FTC CAN-SPAM guide (https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business), ICO electronic mail marketing (https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/), UWG § 7 (https://www.gesetze-im-internet.de/uwg_2004/__7.html), CASL s. 10 (https://laws-lois.justice.gc.ca/eng/acts/E-1.6/page-2.html).

package/skills/cold-outreach-sequences/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write a four-step cold email sequence to heads of finance at mid-size logistics firms in the UK",
+    "We sent 500 outbound emails and got two replies. Can you review the copy and targeting?",
+    "Is it legal to cold email business contacts in Germany and France that we found on LinkedIn?",
+    "Help me personalise opening lines for these 30 prospects without making stuff up",
+    "How many days should we wait between follow-ups in an outbound prospecting sequence?"
+  ],
+  "should_not_trigger": [
+    "Our newsletter emails started landing in spam after we switched provider, check our DKIM",
+    "Write a welcome email series for people who just signed up for our free trial",
+    "Repurpose our founder's podcast episode into five LinkedIn posts",
+    "Draft a proposal document for the client we met last week",
+    "Plan our product launch campaign across paid ads, email and events"
+  ]
+}

package/skills/content-repurposing/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: content-repurposing
+description: Breaks one finished long-form source (article, talk recording, podcast episode, webinar or report) into channel-native derivatives such as LinkedIn posts, X threads, newsletter sections, short video clip scripts and quote cards, by extracting the core claims with timestamps or paragraph references, matching each to a format, and checking every derivative against the source so nothing is exaggerated, misquoted or stripped of its caveats. Use when someone has a long piece already published or recorded and wants a set of social posts, threads, a newsletter or clips made from it, or wants derivatives checked for accuracy against the original.
+license: MIT
+compatibility: Any Agent Skills host. Needs the source as text (article or transcript with timestamps); clip cutting itself is done in the user's video tool.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: read-only
+  kete-loom/owner: "Kete-org"
+---
+
+# Content repurposing
+
+Turn one long piece into many short ones that each work on their own channel, and that all still say what the original said.
+
+## Ground rules
+
+1. **The source is the only source.** Every claim, number and quote in a derivative must trace to a paragraph or timestamp in the original. No new facts, statistics or examples unless the user supplies them.
+2. **Quotes are exact.** Quote marks mean the speaker's words verbatim from the transcript. Tidy filler words only with "[...]" or by paraphrasing without quote marks. Name the speaker as they are credited.
+3. **Keep the caveats.** If the source says "in our sample of 40 customers" or "early results", the derivative says it too. Do not turn "may help" into "proves".
+4. **Native, not pasted.** Each channel gets its own shape, length and opening; never post the same paragraph everywhere.
+5. **One idea per derivative.** A post that tries to summarise the whole piece usually says nothing.
+6. **Credit and link back** to the original where the channel allows it.
+
+## Steps
+
+1. **Get the source in text.** For audio or video, ask for a transcript with timestamps (or produce one with the user's transcription tool). Ask who the audience is, which channels they use, the brand voice guide if one exists, and the goal (traffic back to the piece, followers, sign-ups).
+2. **Extract a claim map.** List 5 to 15 standalone ideas: each a one-sentence claim, its support (data, story, example), the exact reference (paragraph number or `mm:ss`), and any caveat. Mark the 2 or 3 strongest. Show this map to the user before drafting if the piece is technical, regulated or about named people.
+3. **Match ideas to formats** with the table below. Pick only the channels the user actually uses.
+4. **Draft each derivative** from one row of the claim map. Write the hook first (the specific claim or result, not "In today's episode..."), then the support, then one call to action.
+5. **Accuracy pass.** For every derivative, check each sentence against its reference: same meaning, same numbers, caveats kept, quotes verbatim, speaker correct. Fix or drop anything that does not trace back.
+6. **Channel pass.** Check length, link placement and formatting against the platform's current limits. Posting or scheduling through APIs is the social-media-publishing skill's job.
+7. **Plan the release.** Space derivatives over 2 to 4 weeks, lead with the strongest idea, and vary formats so the same audience does not see the same point twice in a week.
+
+## Format guide
+
+| Format | Shape | Best for |
+|---|---|---|
+| LinkedIn post | Hook line, short paragraphs, one takeaway, link in the post or first comment per the user's practice | Lessons, results, opinions with reasoning |
+| X thread | First post states the payoff; 4 to 8 posts, one point each; last post links to the source | Step-by-step processes, lists, a story with a turn |
+| Single X post | One sharp claim or number with its context | The most quotable line |
+| Newsletter section | 150 to 400 words: why it matters to this reader, the key idea, link to the full piece | Existing subscribers; deeper context |
+| Short video clip (Reels, Shorts, TikTok, LinkedIn video) | 20 to 60 seconds; starts on the strongest sentence; burned-in captions; one idea | Talks, podcasts with video, demos |
+| Quote card | One verbatim line, speaker name, source title | Memorable lines; check the quote twice |
+| Carousel or slide set | One point per slide, 5 to 10 slides | Frameworks, checklists, before/after |
+
+## Clip selection (talks and podcasts)
+
+1. Scan the transcript for moments that stand alone: a clear claim, a story with an ending, a surprising number, a strong answer to a question.
+2. Record start and end timestamps with a few seconds of padding, and the first sentence the clip opens on.
+3. Reject clips that need earlier context to make sense, or whose meaning changes when cut (a joke, a hypothetical, a "some people say...").
+4. Write the caption and on-screen title for each clip; captions must match what is said.
+
+## Stop and ask the user
+
+- Before quoting or clipping a guest or a third party; confirm the user has permission to reuse their words and likeness.
+- When the source contains health, financial, legal or safety advice; derivatives must keep its qualifications, and a qualified reviewer should approve them.
+- When a strong derivative would need a fact the source does not contain.
+- Before using material marked internal, embargoed or unpublished.
+
+## Never
+
+- Invent statistics, quotes, customer names or results to make a post punchier.
+- Remove caveats, attribution or context that changes the meaning.
+- Present a paraphrase in quote marks.
+- Rewrite the whole source into a new long article; that is a separate article-writing job.
+
+## Output format
+
+```
+Source: title, link, length            Audience and goal: ...
+Claim map: # | claim | support | reference (para or mm:ss) | caveat
+Derivatives (one block each):
+  Channel / format:
+  Built from claim #:
+  Draft:
+  Accuracy check: pass | notes
+Clips: start-end | opening line | caption
+Release plan: date | channel | derivative
+Questions for the user: ...
+```

package/skills/content-repurposing/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Turn my 2,000-word blog post on pricing mistakes into a week of LinkedIn posts and an X thread",
+    "Here's the transcript of our podcast episode, find the best 30-second clips and write captions",
+    "Repurpose the keynote I gave last month into a newsletter section and some quote cards",
+    "Check these social posts we made from our research report, did we exaggerate anything?",
+    "We publish one long webinar a month. How do we get two weeks of social content out of each one?"
+  ],
+  "should_not_trigger": [
+    "Write a 1500-word blog post from scratch about remote onboarding",
+    "Our scheduled LinkedIn posts fail with a 401 from the Posts API",
+    "Write a cold email sequence for prospects in the healthcare sector",
+    "Define our brand voice with do and don't examples for the social team",
+    "Burn subtitles into this mp4 and trim the first ten seconds with ffmpeg"
+  ]
+}

package/skills/context-budget/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: context-budget
+description: Keeps a long agent task inside its context window by deciding what to read in full versus search for, reading files in slices, summarising findings into a running notes file, pushing bulky reads and log analysis to subagents that return short answers, and checkpointing before the window runs out. Use when a task spans many files or huge outputs (logs, lockfiles, generated code, large diffs), when earlier details start getting lost, or when the user warns the session is close to its context limit.
+license: MIT
+compatibility: Any Agent Skills host. Subagent delegation needs a host that supports subagents.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: meta
+  kete-loom/risk: writes-files
+  kete-loom/owner: "Kete-org"
+---
+
+# Context budget
+
+The context window is the agent's working memory. Everything you read, every command output and every long reply spends it. When it fills, the host compacts or truncates and early details (the goal, constraints, decisions) are the first to blur. Spend it on what changes your next action.
+
+## 1. Set the budget at the start
+
+1. Write the goal and the hard constraints in 3 to 5 lines in a notes file (for example `.handoff/notes.md` or the host's scratch area). This survives compaction; your memory does not.
+2. Estimate the size of the job: how many files, how big the outputs. If it clearly won't fit in one session, plan checkpoints now (section 6).
+
+## 2. Search before you read
+
+Decision rule for every file or output:
+
+| Situation | Do |
+|---|---|
+| You need to know *where* something is | Search (file name or text search). Don't open files to look. |
+| You need one function or section | Search for it, then read only that line range. |
+| File is small (under ~300 lines) and central to the change | Read it in full once. |
+| File is large, generated, minified, a lockfile or vendored | Never read in full. Search inside it or read a slice. |
+| You already read it and haven't changed it | Don't reread. Use your notes. |
+| You changed it | Reread only the edited region to confirm. |
+
+## 3. Keep command output small
+
+- Filter at the source: `grep`, `head -n 50`, `tail -n 50`, `wc -l`, `--stat`, `--name-only`, `--quiet`, a test runner's "only failures" flag.
+- Run the single failing test, not the whole suite, while iterating. Run the full suite once at the end.
+- Redirect huge output to a file, then search the file: `cmd > out.log 2>&1; grep -n "ERROR" out.log | head` (use the host's scratch or temp directory, not the repo, for `out.log`).
+- Never paste a full log, diff or dependency tree into the conversation when a count or the first error answers the question.
+
+## 4. Summarise as you go
+
+After each investigation step, append 1 to 3 lines to the notes file:
+
+```
+- auth: tokens are checked in src/middleware/auth.ts:40-88 (verifyToken). Refresh is NOT handled there.
+- tests: npm test -- auth -> 12 pass, 1 fail (refresh.test.ts "expired token")
+- decided: fix in verifyToken, not the client, because the client is shared by 3 apps
+```
+
+Write file paths and line numbers, so you can return to the source instead of keeping its text in context.
+
+## 5. Delegate bulky reads
+
+Hand work to a subagent when it means reading a lot to produce a little:
+
+- Scanning a large directory or many files for a pattern and judging each hit.
+- Reading a long log, trace or report to find the root error.
+- Surveying how a library or API is used across the codebase.
+
+Give the subagent a precise question and a return format with a size cap, for example: "Find every caller of `chargeCard`. Return a list of `path:line - one-line purpose`, max 30 lines. Don't propose fixes." Then verify one or two of its claims yourself before acting on them. If the host has no subagents, do the read in slices and summarise each slice before the next. See the `parallel-agent-orchestration` skill for splitting larger work.
+
+## 6. Checkpoint before you run out
+
+Checkpoint when any of these is true:
+
+- You have finished a coherent unit of work (tests green for one part).
+- The host shows the context is past roughly two thirds full, or warns about compaction.
+- You notice you are rereading things or have forgotten an earlier decision.
+
+A checkpoint is: update the notes file, commit coherent work if the user allows commits, and write a handoff note (the `session-handoff` skill has the format). Then either continue with a compacted context or tell the user that a fresh session should resume from the note.
+
+## 7. Keep your replies lean
+
+- Report results, not narration. Skip restating files you just read.
+- Show only the diff hunks that matter, not whole files.
+
+## Never
+
+- Never read an entire large file "to understand it" when a search would locate the part you need.
+- Never drop the goal or the user's constraints from your notes to save space.
+- Never trust a subagent's summary blindly for a decision that changes code; spot-check it.
+- Never keep working past a compaction without rereading your notes file first.

package/skills/context-budget/evals/triggers.json

@@ -0,0 +1,14 @@
+{
+  "should_trigger": [
+    "This repo is huge and you keep forgetting what we decided earlier, work more economically",
+    "The build log is 40,000 lines, find the real error without dumping it all into the chat",
+    "We're going to touch about 60 files in this refactor, plan how to do it without blowing the context window",
+    "You're close to the context limit, how should we keep going on this task without losing track"
+  ],
+  "should_not_trigger": [
+    "Save a handoff note so I can resume this in a fresh session tomorrow",
+    "Split this migration across four subagents working in parallel",
+    "Set up an unattended loop that keeps fixing lint errors until the count hits zero",
+    "Reduce the token cost of the system prompt in our customer support chatbot"
+  ]
+}

package/skills/conventional-commits/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: conventional-commits
+description: Writes and checks commit messages in the Conventional Commits 1.0.0 format - choosing the type and scope, marking breaking changes with "!" or a BREAKING CHANGE footer, writing a body that explains why the change was made, and adding issue footers - so changelog and semantic-version tooling can read the history. Use when composing a commit message, splitting staged work into well-labelled commits, fixing a message that commitlint rejected, or deciding whether a change counts as feat, fix or breaking.
+license: MIT
+compatibility: Any Agent Skills host. Needs git. Checking messages with commitlint needs Node.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/owner: "Kete-org"
+---
+
+# Conventional Commits
+
+A commit message is a record for the next person who runs `git blame`, and for the tools that build the changelog and pick the next version. Write it for both.
+
+## 0. Before writing
+
+1. Look for project rules first: `commitlint.config.*`, `.commitlintrc*`, a `commitlint` key in `package.json`, `CONTRIBUTING.md`, `.czrc`, or release config (`release-please-config.json`, `.releaserc*`). Allowed types and scopes there override this skill.
+2. Read recent history for the house style: `git log --oneline -20`. Match the scopes and casing already in use.
+3. Read what is actually staged: `git diff --cached --stat`, then `git diff --cached`. Write about the staged diff, not what you remember changing.
+4. If nothing is staged, **stop and ask** what should go in the commit. Don't `git add -A` on the user's behalf.
+
+## 1. One change per commit
+
+If the staged diff mixes unrelated things (a bug fix plus a rename plus a dependency bump), propose splitting it and say which files go where. If the user wants one commit anyway, use the type of the most significant change and mention the rest in the body.
+
+## 2. Format
+
+```
+<type>[optional scope][!]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+Rules from the specification:
+
+- `type` is a noun, followed by optional `(scope)`, optional `!`, then `: ` (colon and space) and the description.
+- The body starts after one blank line and is free text.
+- Footers start after one blank line. Each is `Token: value` or `Token #value`. Tokens use `-` instead of spaces (`Reviewed-by`), except `BREAKING CHANGE`.
+- `BREAKING CHANGE` must be uppercase. `BREAKING-CHANGE` means the same.
+
+House conventions on top of the spec (follow the project's config if it differs):
+
+- Description: imperative mood ("add", not "added"/"adds"), lower case first word, no trailing period, aim for 72 characters or fewer on the whole first line.
+- Wrap the body at about 72 characters.
+
+## 3. Choose the type
+
+| Type | Use for | Version effect with standard tooling |
+|---|---|---|
+| `feat` | New behaviour a user or caller can see | minor |
+| `fix` | Corrects wrong behaviour | patch |
+| `perf` | Faster or leaner, same behaviour | patch in most presets |
+| `refactor` | Code change with no behaviour change | none |
+| `docs` | Documentation only | none |
+| `test` | Adding or fixing tests only | none |
+| `build` | Build system, packaging, dependencies | none |
+| `ci` | CI configuration and scripts | none |
+| `style` | Formatting, whitespace; no code meaning change | none |
+| `chore` | Maintenance that fits nothing above | none |
+| `revert` | Reverts an earlier commit | depends on the tool |
+
+Only `feat` and `fix` have meaning in the specification itself; the rest are the widely used `@commitlint/config-conventional` set. Any type can carry a breaking change.
+
+Decision rules:
+
+- If a user-visible behaviour changes to correct a defect, it is `fix`, even if the code change is large.
+- If you are unsure between `feat` and `refactor`, ask: would the changelog reader care? Yes means `feat` or `fix`.
+- A dependency bump that fixes a user-facing bug is `fix(deps): ...`; a routine bump is `build(deps): ...` (or `chore(deps)` if that is the house style).
+
+## 4. Choose the scope
+
+- A scope names the area touched: a package, module or subsystem (`feat(auth): ...`, `fix(api): ...`).
+- Use scopes already in the history or config. Don't invent a new one per commit.
+- Leave the scope out rather than guess, or when the change spans the whole project.
+
+## 5. Breaking changes
+
+A change is breaking when existing callers, configs, data or users must change something to keep working: removed or renamed public API, changed defaults, changed output format, dropped runtime support, a required new setting.
+
+Mark it with either or both:
+
+```
+feat(api)!: remove v1 order endpoints
+
+BREAKING CHANGE: /v1/orders is gone. Call /v2/orders, which returns
+amounts in minor units instead of decimals.
+```
+
+- Prefer `!` plus a `BREAKING CHANGE:` footer that says **what breaks and what to do instead**. That footer text usually lands in the changelog verbatim.
+- If you think a change is breaking but the user hasn't said so, **stop and ask** before marking it; it decides a major release.
+- On a project still at `0.y.z`, a breaking change is still marked; the release tooling decides how to bump.
+
+## 6. Write a body that explains why
+
+The diff shows what changed. The body says:
+
+1. Why the change was needed (the bug, the requirement, the constraint).
+2. Why this approach, if it isn't obvious, and what was ruled out.
+3. Side effects a reviewer would not guess (migration needed, cache to clear, behaviour change at the edges).
+
+Skip the body only for changes whose reason is self-evident (`docs: fix typo in README`). Never restate the diff line by line, and never write "update file" or "misc fixes".
+
+## 7. Footers
+
+- Issue links: `Refs: #123`. On GitHub and GitLab, `Closes #123` or `Fixes #123` closes the issue when the commit reaches the default branch, so use those only when the commit really completes it.
+- Co-authors: `Co-authored-by: Name <email>`.
+- Reverts: `git revert --no-commit <sha>`, then commit as `revert: <original subject>` with the body line `This reverts commit <sha>.` and a `Refs: <sha>` footer. Plain `git revert` writes a `Revert "<subject>"` subject, which is not in the Conventional Commits format.
+
+## 8. Check before committing
+
+- If the project has commitlint, check the message: `echo "<message>" | npx commitlint`, or a range with `npx commitlint --from origin/main --to HEAD`.
+- Commit without opening an editor: `git commit -F <message-file>` or `git commit -m "<subject>" -m "<body>" -m "<footer>"`.
+- If a commit hook rejects the message, fix the message. Don't skip hooks with `--no-verify` unless the user asks.
+- If the commit is already pushed to a shared branch, don't amend it; the squash-merge title or a follow-up commit is the place to fix it.
+
+## Examples
+
+```
+fix(cart): reject negative quantities
+
+The quantity input accepted values below zero, which produced negative
+line totals and let users reduce an order's price. Validate on the
+server as well as in the form, since the API is called directly by the
+mobile app.
+
+Fixes #482
+```
+
+```
+perf(search): cache tokenised queries per request
+
+Profiling showed tokenisation was 40% of search latency for repeated
+filter queries. The cache lives only for the request, so there is no
+invalidation to manage.
+```
+
+## Report back
+
+Give the final message in a code block, the files it covers, and one line on why that type, scope and breaking flag were chosen. If you proposed a split, list each commit's message and files.

package/skills/conventional-commits/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write a conventional commit message for what I've staged",
+    "commitlint keeps failing with 'subject may not be empty', fix my commit message",
+    "Is removing the legacy config flag a feat or a breaking change? How do I mark it in the commit?",
+    "I've staged a bug fix and a refactor together, split them into properly typed commits",
+    "Rewrite this commit message so it explains why we changed the retry logic, not just what"
+  ],
+  "should_not_trigger": [
+    "Decide whether the next release should be 3.0.0 or 2.5.0 and publish it",
+    "My rebase onto main has conflicts in the lockfile, help me finish it",
+    "Write the pull request description for this branch",
+    "Generate release notes for v1.8.0 from the changelog",
+    "Recover the commits I lost after a bad interactive rebase"
+  ]
+}

package/skills/cpp-patterns/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: cpp-patterns
+description: Modern C++ (17/20/23) house rules for writing and restructuring code - RAII for every resource, unique_ptr/shared_ptr ownership, value semantics and the rule of zero, const-correctness, steering clear of undefined behaviour, concepts used sparingly, target-based CMake, plus sanitizer and clang-tidy setup. Use when writing new C++ code, modernising legacy C++98/03 code, deciding who owns an object, or setting up a CMake project with warnings, sanitizers and clang-tidy.
+license: MIT
+compatibility: Any Agent Skills host. Needs a C++17-or-later compiler (GCC, Clang or MSVC) and CMake for the build sections.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "cmake"
+  kete-loom/owner: "Kete-org"
+---
+
+# Modern C++ patterns
+
+Write C++ where ownership is visible in the types, resources clean themselves up, and the compiler plus sanitizers catch what review misses.
+
+## 0. Before you write code
+
+1. Find the language standard the project builds with: `CMAKE_CXX_STANDARD` or `target_compile_features(... cxx_std_NN)` in `CMakeLists.txt`, `-std=` in compile flags, or `compile_commands.json`. Never use a feature newer than that standard.
+2. Match the project's existing conventions (naming, error style, exceptions on or off, header layout). If the codebase builds with `-fno-exceptions`, do not introduce `throw`.
+3. If the change would alter a public header used by other libraries or shipped as a binary SDK, **stop and ask the user**: it may be an ABI break.
+
+## 1. Ownership and RAII
+
+Decision rules, in order:
+
+1. **Store by value** when the object has one owner and a known type. `std::vector<Widget>`, not `std::vector<Widget*>`.
+2. **`std::unique_ptr<T>`** for single ownership of a heap object (polymorphic types, pimpl, large or optional objects). Create with `std::make_unique<T>(...)`.
+3. **`std::shared_ptr<T>`** only when ownership is genuinely shared and lifetimes cannot be ordered. Create with `std::make_shared`. Break cycles with `std::weak_ptr`.
+4. **Raw pointer or reference = non-owning.** `T&` when it cannot be null, `T*` when it can. A raw pointer never gets `delete`d by the code that receives it.
+5. **Views do not own.** `std::string_view` and `std::span` must not outlive the buffer they point into; never return one that points at a local or a temporary.
+
+Every resource (file handle, socket, lock, OS handle, C library object) is wrapped in an object whose destructor releases it:
+
+```cpp
+struct FileCloser { void operator()(std::FILE* f) const noexcept { if (f) std::fclose(f); } };
+using File = std::unique_ptr<std::FILE, FileCloser>;
+
+File open_file(const char* path) { return File{std::fopen(path, "rb")}; }
+```
+
+Locks: `std::scoped_lock` (C++17) or `std::lock_guard`; `std::unique_lock` when you must unlock early or wait on a `std::condition_variable`. Never manual `lock()`/`unlock()`.
+
+Never write: naked `new`/`delete` in application code, `malloc`/`free` for C++ objects, `delete this`, `std::auto_ptr`, or a `shared_ptr` passed by value into a function that only reads it (pass `const T&` instead).
+
+## 2. Value semantics and special members
+
+- **Rule of zero:** if members are RAII types, declare no destructor, copy or move operations. The compiler-generated ones are correct.
+- **Rule of five:** if you must write one of destructor / copy ctor / copy assign / move ctor / move assign, write or `= delete` all five.
+- Mark move constructors and move assignment `noexcept`. A copyable type whose move constructor is not `noexcept` gets copied, not moved, when `std::vector` reallocates.
+- Pass parameters: cheap types (ints, pointers, `string_view`, `span`) by value; read-only larger objects by `const T&`; sink parameters (the callee keeps a copy) by value then `std::move` into place.
+- Return by value. Do not write `return std::move(local);`; it blocks copy elision.
+- Never use an object after `std::move` from it except to assign to it or destroy it.
+- Make single-argument constructors `explicit` unless implicit conversion is the point.
+
+## 3. Const-correctness
+
+- Variables are `const` (or `constexpr`) unless they are mutated.
+- Member functions that do not change observable state are `const`. `mutable` only for caches and mutexes.
+- Prefer `constexpr` functions and `static_assert` for things knowable at compile time.
+- Mark functions `[[nodiscard]]` when ignoring the result is almost always a bug (error codes, `expected`-style results, factory functions).
+
+## 4. Avoiding undefined behaviour
+
+Check each of these in code you write or touch. Details and examples: `references/undefined-behaviour.md`.
+
+- Signed integer overflow, shifting by >= the bit width, and division by zero.
+- Out-of-bounds indexing: use `.at()` in non-hot code, range-for, or `std::span`; check indices from input.
+- Dangling references: returning a reference or view to a local, lambdas capturing locals by reference that outlive the scope, iterators or references into a `vector` after `push_back`/`insert`/`erase`.
+- Uninitialised variables: initialise at declaration (`int n{};`, `T x = make();`).
+- Strict aliasing and type punning: use `std::memcpy` or `std::bit_cast` (C++20), not `reinterpret_cast` between unrelated types.
+- Data races: any variable written by one thread and read by another needs a mutex or `std::atomic`.
+- Deleting through a pointer to a polymorphic base class whose destructor is neither `virtual` nor `protected`.
+
+## 5. Errors
+
+- Follow the project's existing strategy. If none: exceptions for errors the immediate caller cannot handle, return values for expected failures (`std::optional`, `std::expected` in C++23, or the project's own result type).
+- Destructors, move operations and `swap` are `noexcept` and never throw.
+- Give every function the strong or basic exception guarantee: on throw, state is unchanged or still valid, and nothing leaks (RAII makes this automatic).
+
+## 6. Templates and concepts in moderation
+
+- Write a plain function or class first. Add a template only when there are two real call sites with different types.
+- In C++20, constrain templates with standard concepts (`std::integral`, `std::ranges::range`) or a short named `concept`, instead of `enable_if`.
+- Keep template definitions in headers. No template metaprogramming where `if constexpr` or an overload does the job.
+- Prefer standard algorithms and ranges (`std::ranges::sort`, `std::ranges::find_if`) over hand-written loops when they read more clearly.
+
+## 7. Project structure and CMake
+
+Use target-based CMake; never set flags globally with `CMAKE_CXX_FLAGS` edits or `include_directories()`.
+
+```cmake
+cmake_minimum_required(VERSION 3.20)
+project(app LANGUAGES CXX)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
+add_library(core src/core.cpp)
+target_include_directories(core PUBLIC include)
+target_compile_features(core PUBLIC cxx_std_20)
+
+add_executable(app src/main.cpp)
+target_link_libraries(app PRIVATE core)
+```
+
+- Layout: `include/<project>/` public headers, `src/` sources and private headers, `tests/` tests.
+- `PUBLIC` when consumers need it (it appears in your headers), `PRIVATE` when only your `.cpp` files need it.
+- Get dependencies with `find_package` (fed by vcpkg or Conan) or `FetchContent`; do not vendor copies.
+- Out-of-source builds only: `cmake -S . -B build && cmake --build build`.
+
+Warnings, sanitizers, clang-tidy and a `CMakePresets.json` example: `references/cmake-and-tooling.md`.
+
+## 8. Tooling loop
+
+1. Build with warnings on: GCC/Clang `-Wall -Wextra -Wpedantic -Wshadow -Wconversion`, MSVC `/W4`. Treat new warnings in touched files as errors.
+2. Run the tests under AddressSanitizer + UndefinedBehaviorSanitizer (`-fsanitize=address,undefined -fno-omit-frame-pointer`). Run ThreadSanitizer (`-fsanitize=thread`) in a **separate** build for concurrent code; it cannot be combined with ASan.
+3. Run `clang-tidy` on changed files using `compile_commands.json` (`clang-tidy -p build <files>`). Fix findings in code you touched; do not mass-fix the rest of the codebase unasked.
+4. Format with the project's `.clang-format` if one exists (`clang-format -i <files>`). Do not add one unasked.
+
+## Rules
+
+- Never silence a warning or sanitizer report with a cast, pragma or suppression file without explaining the root cause to the user.
+- Never change a public header's layout, virtual functions or inline functions in a shipped library without asking (ABI).
+- Do not modernise unrelated code in the same change. Keep diffs focused.
+- If you cannot build the project locally, say so; do not claim code compiles.
+
+## Report back
+
+End with: files changed, the build and test commands you ran (with sanitizer flags), their results, and any warnings or clang-tidy findings left unresolved.

package/skills/cpp-patterns/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Rewrite this class so it stops using raw new and delete and uses smart pointers instead",
+    "Should this member be a unique_ptr, a shared_ptr or just a value?",
+    "Set up a new C++20 CMake project with warnings, sanitizers and clang-tidy",
+    "Modernise this old C++03 parser to C++17 style with RAII and string_view",
+    "Write a thread-safe connection pool class in modern C++"
+  ],
+  "should_not_trigger": [
+    "Write GoogleTest unit tests for the Matrix class and hook them into CTest",
+    "Review my C++ pull request for dangling references and data races",
+    "The linker says undefined reference to vtable for Widget, fix the build",
+    "Refactor this Rust module to avoid cloning and use borrowed slices",
+    "Add idiomatic error handling with errors.Is to this Go service"
+  ]
+}