@ketecode/loom 0.0.0-stage → 0.2.0

package/skills/clinical-decision-support/references/regulatory-boundaries.md

@@ -0,0 +1,37 @@
+# Regulatory boundaries for clinical software
+
+This is a map of questions to raise, not a determination. Regulatory affairs or counsel decides whether a product is a medical device, and the rules change: check the current text of each source before relying on it.
+
+## United States (FDA)
+
+- Basis: section 520(o)(1)(E) of the FD&C Act (added by the 21st Century Cures Act) excludes some CDS software from the device definition. FDA's "Clinical Decision Support Software" guidance explains how it reads the criteria; FDA lists a final version dated January 2026, which replaced the September 2022 version. Secondary summaries say it relaxed FDA's position on software that gives a single recommendation and refined its approach to time-critical use. Read the FDA text itself before relying on either point.
+- All four criteria must be met for the exclusion:
+  1. Not intended to acquire, process or analyse a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system.
+  2. Intended to display, analyse or print medical information about a patient or other medical information (such as peer-reviewed studies and guidelines).
+  3. Intended to support or provide recommendations to a healthcare professional about prevention, diagnosis or treatment.
+  4. Intended to enable the healthcare professional to independently review the basis for the recommendations, so they don't rely primarily on the software.
+- Red flags that push toward device regulation: image or waveform analysis; patient- or caregiver-facing recommendations; time-critical alerts; outputs a clinician cannot independently check (opaque ML); automatic actions.
+- Related: FDA guidance on device software functions and mobile medical applications, and general wellness products, describe other functions FDA does or does not focus on.
+
+## European Union (MDR 2017/745)
+
+- Software intended by its manufacturer for a medical purpose (diagnosis, prevention, monitoring, prediction, prognosis, treatment) can be a medical device (MDR Article 2). MDCG 2019-11 is the guidance on qualifying and classifying software.
+- Annex VIII Rule 11: software that provides information used to take decisions with diagnostic or therapeutic purposes is class IIa; class IIb where those decisions could cause a serious deterioration of health or a surgical intervention; class III where they could cause death or an irreversible deterioration. Few decision support products are class I under the MDR.
+- The EU AI Act also applies to AI systems that are, or are safety components of, devices requiring notified-body assessment.
+
+## United Kingdom
+
+- Medical devices: MHRA under the UK MDR 2002 (as amended); MHRA publishes guidance on software and AI as a medical device.
+- NHS clinical safety (applies to health IT deployed in the NHS in England whether or not it is a device): DCB0129 for manufacturers and DCB0160 for deploying organisations. They require a clinical risk management process, a hazard log, a clinical safety case report and a named Clinical Safety Officer (a registered clinician).
+
+## Other markets
+
+Check the national regulator (for example Health Canada, TGA in Australia, and national authorities across Africa and Asia). Many follow IMDRF "Software as a Medical Device" concepts, which classify by the significance of the information to the decision and the state of the condition.
+
+## Engineering practices that help in every regime
+
+- A written intended-use statement for each feature.
+- A hazard log: what could go wrong (wrong patient, wrong unit, missing data, outage), severity, likelihood, mitigations, residual risk.
+- Traceability from requirement to rule version to test case to release.
+- Software lifecycle practices aligned with IEC 62304 and risk management with ISO 14971 where the product is, or may become, a device.
+- Post-release monitoring of fire rates, overrides and incidents, with a route to report safety issues.

package/skills/code-tour/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: code-tour
+description: Authors a step-by-step guided walkthrough of a codebase or a single feature as an ordered list of stops, each pinned to a file:line reference with a short explanation of what that code does and why it matters, written so a new contributor can follow it in one sitting. Use when asked to create a code walkthrough, a feature tour, a "follow the request" guide, or contributor-facing reading order for part of a project.
+license: MIT
+compatibility: Any Agent Skills host. Needs git to pin the tour to a commit.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: writes-files
+  kete-loom/requires: "git"
+  kete-loom/owner: "Kete-org"
+---
+
+# Code tour
+
+A code tour is a reading order. It takes a newcomer through the code that matters, one stop at a time, so they understand a feature without reading the whole repo. A good tour has 6 to 15 stops, follows the path execution takes, and every stop points at real code.
+
+## 1. Agree the scope
+
+Before writing, settle with the user:
+
+- **Subject:** the whole codebase at high level, or one feature or flow (for example "how a login request is handled").
+- **Reader:** new contributor, reviewer, new team member, or future maintainer. This sets how much background each stop needs.
+- **Where it lives:** a Markdown file in the repo (default `docs/tours/<topic>.md`), or reply only.
+
+If the subject is "everything" for a large repo, propose splitting into one overview tour plus one tour per major flow, and ask which to write first.
+
+## 2. Find the path
+
+1. Locate the entry point for the subject: a route, command handler, event consumer, UI action or public function.
+2. Follow the call chain by reading code and searching for callers and definitions. Don't trust names; open each function.
+3. Note each place a reader must understand: where input arrives, where it's validated, where the core decision is made, where state changes, where it leaves the system, and where errors are handled.
+4. Find the test that exercises this path. It makes a good last stop.
+
+Drop stops that are pure plumbing (re-exports, trivial wrappers) unless skipping them would confuse the reader.
+
+## 3. Pin it to a commit
+
+Line numbers drift. Record the current commit with `git rev-parse --short HEAD` and put it in the tour header. If `git status --porcelain -- <cited paths>` shows uncommitted changes in files the tour cites, tell the user the references may move once they commit.
+
+## 4. Write the stops
+
+Each stop has:
+
+- a numbered title that says what happens, not the file name ("3. Validate the payload", not "3. validators.ts");
+- a `path:line` or `path:start-end` reference, relative to the repo root;
+- 2 to 5 sentences: what this code does, why it's here, and what to notice;
+- optionally, a short excerpt (at most 10 lines) when the point is a specific construct.
+
+Rules for stops:
+
+- Order follows execution or data flow, not the directory tree.
+- Each stop should connect to the next ("the validated payload is handed to...").
+- Explain intent and non-obvious decisions. Don't narrate code line by line.
+- Flag gotchas the reader would otherwise hit: hidden side effects, global state, ordering requirements, surprising config.
+- Keep ranges tight. A stop pointing at a 300-line file teaches nothing.
+
+## 5. Use this format
+
+```markdown
+# Tour: <subject>
+
+> Commit `<sha>` · Reader: <audience> · About <N> minutes
+
+**You'll learn:** <one or two sentences>
+**Before you start:** <prerequisites, such as how to run the app or which concepts to know>
+
+## 1. <What happens here>
+`path/to/file.ext:12-30`
+
+<2 to 5 sentences.>
+
+## 2. <Next step>
+`path/to/other.ext:44`
+
+<...>
+
+## Where to go next
+- <related tour, doc, or the test to run: `<command>`>
+```
+
+## 6. Verify before you hand it over
+
+1. Open every cited range and confirm it still shows what the stop describes. Fix or drop any that don't.
+2. Confirm every path exists, using the exact case.
+3. Read the tour top to bottom as the target reader. If a stop uses a term no earlier stop or prerequisite introduced, add a sentence or a link.
+4. If the tour includes a command, run it, or mark it as not run.
+
+## Never
+
+- Invent a file, function or line number. If you couldn't find something, say so in the tour.
+- Edit source code to make the tour easier to write.
+- Overwrite an existing tour without asking; offer an updated version alongside it.
+
+## Report back
+
+Return the tour (or its path), the commit it is pinned to, the number of stops, and any references you could not verify. For getting yourself oriented rather than writing for others, use `codebase-onboarding`; for README or API docs, use `technical-writing`.

package/skills/code-tour/evals/triggers.json

@@ -0,0 +1,14 @@
+{
+  "should_trigger": [
+    "Write a guided tour of how a login request moves through this app, with file and line references for each stop",
+    "Create a walkthrough of the billing module for new contributors so they know what to read and in what order",
+    "Can you make a step-by-step code tour of the plugin loader for the docs folder?",
+    "Our new hire starts Monday. Put together a feature tour of the search indexing pipeline pinned to the current commit"
+  ],
+  "should_not_trigger": [
+    "I just cloned this project, help me figure out how to build it and where the entry points are",
+    "Write API reference docs for the public functions in the sdk package",
+    "Update the README and CHANGELOG to reflect the renamed config flag",
+    "Explain what this one regular expression in utils.py matches"
+  ]
+}

package/skills/codebase-onboarding/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: codebase-onboarding
+description: Gets you productive in an unfamiliar repository fast by locating its entry points, building and running it locally, mapping modules and the main data flow, reading the tests as a specification, and ending with a one-page orientation note. Use when someone has just cloned or inherited a project, asks "how does this codebase work", "where do I start", or needs to understand a repo before changing it.
+license: MIT
+compatibility: Any Agent Skills host. Needs git and whatever build tool the project uses.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: docs
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "git"
+  kete-loom/owner: "Kete-org"
+---
+
+# Codebase onboarding
+
+Turn an unknown repository into a mental map you can act on. The goal is not to read everything: it is to find the few files that matter, prove you can build and run the thing, and write down what you learned so the next person starts faster.
+
+Work read-first. Do not edit tracked files during onboarding. The only files you may create are git-ignored local config copies (step 2) and the orientation note, and the note only where the user agrees.
+
+## 1. Get the lay of the land (5 minutes)
+
+1. List the top level of the repo and read, in this order, whichever exist: `README*`, `CONTRIBUTING*`, `AGENTS.md`, `CLAUDE.md`, `docs/` index, `ARCHITECTURE*`.
+2. Identify the stack from manifests: `package.json`, `pyproject.toml`, `requirements*.txt`, `go.mod`, `Cargo.toml`, `pom.xml`, `build.gradle*`, `*.csproj`, `Gemfile`, `composer.json`, `pubspec.yaml`, `Package.swift`, `CMakeLists.txt`, `Makefile`.
+3. Note the scripts or tasks they define (for example `scripts` in `package.json`, targets in a `Makefile`, `[project.scripts]` in `pyproject.toml`). These are the project's own answer to "how do I build, test and run this".
+4. Check recent history: `git log --oneline -20` and `git shortlog -sn --since="6 months ago"` show what is active and who knows it.
+5. Check CI config (`.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `.circleci/`). CI is the most reliable record of the real build and test commands.
+
+If it is a monorepo (workspaces, `packages/`, `apps/`, `services/`), ask the user which package they care about before going further. Onboarding to everything at once produces nothing useful.
+
+## 2. Build and run it
+
+1. Install dependencies with the command the README or CI uses. Prefer the lockfile-respecting form (`npm ci`, `pip install -r`, `go mod download`, `bundle install`).
+2. Run the test suite once. Record the command, pass/fail counts and duration.
+3. Start the app, CLI or service the way the README says, and hit one real path (a request, a command, a page).
+4. Copy environment templates (`.env.example`, `config/*.sample`) only into files that `git check-ignore <path>` confirms are ignored, and never overwrite an existing `.env`.
+
+Stop and ask the user when:
+
+- setup needs credentials, a paid service, production data or access you don't have;
+- a step would install system-wide packages, change global config or run a database migration against anything but a local database;
+- the build fails and the fix is not obvious after one attempt. Report the exact error instead of guessing.
+
+Never run deploy, publish, release or data-deleting scripts while onboarding, even if they sit next to the build scripts.
+
+## 3. Find the entry points
+
+Search for where execution starts. Typical signs:
+
+| Kind | Look for |
+|---|---|
+| Web server | route or controller registration, `listen(`, app factory, framework config |
+| CLI | `bin` field in `package.json`, `[project.scripts]`, `main` packages, argument parsers |
+| Library | the package's public export file (`index.*`, `__init__.py`, `lib.rs`, `mod.rs`) |
+| Workers and jobs | queue consumers, cron or scheduler definitions, serverless handlers |
+| Frontend | the root component, router definition, HTML entry |
+
+List at most five entry points with `path:line`. If you find more, group them.
+
+## 4. Map modules and data flow
+
+1. Sketch the module layout from directory names, then confirm by reading one file in each major directory. Directory names lie; imports don't.
+2. Pick one representative request or command and trace it end to end: entry point, validation, business logic, persistence or external call, response. Write each hop as `path:line — what happens`.
+3. Note where state lives: databases (look for migrations and schema files), caches, queues, files, third-party APIs.
+4. Note the cross-cutting pieces: config loading, logging, auth, error handling, dependency injection.
+
+## 5. Read the tests as a spec
+
+- Find the test layout and the fixtures or factories.
+- Read the tests for the flow you traced. They show intended behaviour and edge cases the code alone hides.
+- Note what has no tests. That is where changes are risky.
+
+## 6. Write the orientation note
+
+Ask the user where it should go (reply only, a scratch file, or `docs/ONBOARDING.md`). Do not overwrite an existing onboarding doc; propose additions instead. Keep it to one page, in this format:
+
+```markdown
+# <project> orientation
+
+**What it is:** <one sentence>
+**Stack:** <languages, frameworks, datastores>
+
+## Run it
+- Install: `<command>`
+- Test: `<command>` (<N> passed, <duration>)
+- Start: `<command>`, then <how to see it working>
+
+## Entry points
+- `path:line` — <what starts here>
+
+## How a request flows
+1. `path:line` — <step>
+
+## Where things live
+- <directory> — <responsibility>
+
+## Gotchas
+- <surprising thing, flaky test, required env var>
+
+## Open questions
+- <things you could not confirm>
+```
+
+## Rules
+
+- Every claim in the note points to a file or a command output. If you inferred it, say "probably".
+- Don't summarise files you didn't open.
+- Don't paste secrets from `.env` or config into the note or the reply.
+- Keep it short. A note nobody reads is worse than none.
+
+## Report back
+
+Return the orientation note (or its path), the commands you ran with their results, and the open questions the user should take to a maintainer. For a walkthrough meant for other contributors, hand off to the `code-tour` skill; for polished project docs, to `technical-writing`.

package/skills/codebase-onboarding/evals/triggers.json

@@ -0,0 +1,14 @@
+{
+  "should_trigger": [
+    "I just inherited this repo and have no idea how it fits together, help me get oriented",
+    "Where do I even start with this codebase? Figure out how to build and run it",
+    "Map out the modules and how a request flows through this service before I change anything",
+    "New job, first day, cloned their monorepo. Give me a quick lay of the land for the payments package"
+  ],
+  "should_not_trigger": [
+    "Write a guided tour of the checkout feature for our new contributors, with file and line stops",
+    "Rewrite our README so a new user can install the CLI in five minutes",
+    "I changed the config loader, update the docs and changelog to match",
+    "Propose how we should split this monolith into separate services and write up the trade-offs"
+  ]
+}

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"
+  ]
+}