@ketecode/loom 0.0.0-stage → 0.2.0

package/skills/prisma-patterns/references/prisma-8.md

@@ -0,0 +1,46 @@
+# Prisma 8 differences
+
+Prisma 8 replaces the generated `PrismaClient` with a contract-based client. At the time this was written (October 2026) it was a **release candidate** and the docs said details may still change. Check https://www.prisma.io/docs/orm/release-status and the "Coming from Prisma ORM 7" guide before relying on anything here, and keep using the 6/7 rules in `SKILL.md` for projects that haven't migrated.
+
+Prisma 7 remains supported (bug fixes and security updates for 18 months after Prisma 8 reaches general availability). Do not migrate a project to Prisma 8 unless the user asks.
+
+## Databases
+
+PostgreSQL, SQLite and MongoDB. There is no MySQL support, so a MySQL project stays on Prisma 7.
+
+## Files
+
+- Contract: `src/prisma/contract.prisma`, first line `// use prisma-8`. No `generator` or `datasource` block; connection settings go in the `orm` section of `prisma.config.ts`.
+- Database types are field types: `VarChar(255)` instead of `String @db.VarChar(255)`. `Json` means PostgreSQL `json`; use `Jsonb` for `jsonb`.
+- SQL defaults use `` sql`...` `` instead of `dbgenerated(...)`. `cuid()` is written `cuid(2)`.
+- Implicit many-to-many relations need an explicit join model.
+
+## Commands
+
+| Prisma 7 | Prisma 8 |
+|---|---|
+| `prisma generate` | `prisma contract emit` |
+| `prisma migrate dev` | `prisma db update`, or `prisma migration plan` then `prisma db migrate` |
+| `prisma migrate deploy` | `prisma db migrate` |
+| `prisma db pull` | `prisma contract infer` |
+| `prisma migrate diff` | `prisma db update --dry-run` or `prisma migration show` |
+| `prisma migrate reset`, `prisma db seed` | none |
+
+## Client and queries
+
+- Create `db` once (for PostgreSQL in `src/prisma/db.ts`, with `postgres<Contract>(...)` from `@prisma/orm-postgres/runtime`).
+- Models live under `db.orm.<schema>.<Model>`, for example `db.orm.public.User`.
+- `findMany` → `.where(...).all()`; `findFirst`/`findUnique` → `.first()` (returns `null`); `select` → `.select("id", "email")`; `take`/`skip` → `.limit()`/`.offset()`.
+- Relations: `.include("posts")`. Nested writes are limited to `create`, `connect` and `disconnect`. `relationLoadStrategy` is gone.
+- Errors carry codes such as `RUNTIME.NO_ROWS` and `error.sqlState`; the `P2002`-style codes are gone.
+
+## Transactions
+
+- `db.transaction(async (tx) => { ... })`, querying through `tx.orm`. There is no array form; write the steps one after another in the callback.
+- No `timeout`, `maxWait` or `isolationLevel` options and no automatic retries. Set a database-side limit (PostgreSQL `idle_in_transaction_session_timeout`, or `transaction_timeout` on PostgreSQL 17+) and run `SET TRANSACTION ISOLATION LEVEL ...` as the first statement when you need another level.
+- Transactions don't nest: pass `tx` into helpers instead of starting another transaction.
+- The MongoDB client has no `db.transaction`; use the MongoDB driver's session API.
+
+## Raw SQL
+
+`$queryRaw`, `$executeRaw`, `Prisma.sql`, `Prisma.join`, `Prisma.raw` and TypedSQL are gone. Raw SQL goes through the `db.raw.sql` tagged template: reads end in `.returnsRow({...}).build()` and run with `db.runtime().query(...)`; writes end in `.affectedCount()` and run with `db.runtime().execute(...)`. The injection rule stays the same: values are parameters, identifiers come from an allow-list.

package/skills/prisma-patterns/references/workflow.md

@@ -0,0 +1,50 @@
+# Prisma migration workflow (Prisma 6 and 7)
+
+Read this before creating, editing or deploying a migration. For Prisma 8, use `references/prisma-8.md` instead.
+
+## Local development
+
+1. Edit `schema.prisma`.
+2. Create and apply the migration on your **local** database:
+   ```
+   npx prisma migrate dev --name add_order_status
+   ```
+   It diffs the schema against the migration history using a shadow database, writes `prisma/migrations/<timestamp>_add_order_status/migration.sql`, and applies it.
+3. On Prisma 7, run `npx prisma generate` afterwards; `migrate dev` no longer generates the client for you.
+4. Read the generated SQL. Edit it before committing when Prisma can't infer intent:
+   - A renamed column shows up as drop plus add, which loses data. Replace it with `ALTER TABLE ... RENAME COLUMN`.
+   - A new required column on a table with rows needs a default or a backfill step.
+   - Large tables: on PostgreSQL, change `CREATE INDEX` to `CREATE INDEX CONCURRENTLY` in its own migration file (it can't run inside a transaction).
+5. Use `npx prisma migrate dev --create-only` to write the file without applying it, when you need to edit it first.
+6. Commit the migration folder together with the schema change.
+
+## Deploy (CI, staging, production)
+
+```
+npx prisma migrate deploy
+```
+
+- Applies pending migrations in order. It never creates migrations, never resets, and needs no shadow database.
+- Run it once per deploy, from one place (a release step or job), not from every app instance at boot.
+- Use a direct, unpooled connection.
+- Check state first with `npx prisma migrate status`.
+
+## Expand and contract for zero downtime
+
+Old and new app versions run side by side during a deploy, so split breaking changes:
+
+1. **Expand**: add the new column or table (nullable or with a default). Deploy code that writes both and reads the old.
+2. **Backfill** in batches from a script.
+3. Deploy code that reads the new column.
+4. **Contract**: drop the old column in a later migration.
+
+## When things go wrong
+
+| Situation | Action |
+|---|---|
+| Drift detected in development | `npx prisma migrate dev` offers a reset; fine only on a local throwaway database |
+| A deploy failed half way | Fix the database by hand, then `npx prisma migrate resolve --applied <name>` or `--rolled-back <name>` |
+| Existing database with no migration history | Baseline: write `prisma/migrations/0_init/migration.sql` with `prisma migrate diff --from-empty --to-schema prisma/schema.prisma --script` (older Prisma 6 releases call this flag `--to-schema-datamodel`; check `npx prisma migrate diff --help`), then `prisma migrate resolve --applied 0_init` |
+| Need the SQL between two states | `prisma migrate diff` with `--from-*` and `--to-*` flags. Prisma 7 removed the URL flags; use `--from-config-datasource` / `--to-config-datasource`, and treat "No difference detected" as suspect until you've confirmed the datasource is configured |
+
+Never run `migrate reset` or `db push` on a shared database; both can drop data. Ask the user before running `migrate resolve` anywhere except locally.

package/skills/privacy-compliance/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: privacy-compliance
+description: Turns data protection law (EU/UK GDPR, Ghana Data Protection Act 2012, Nigeria Data Protection Act 2023, Kenya Data Protection Act 2019) into engineering work on personal data, covering data mapping, lawful basis and consent records, retention and deletion jobs, subject access and erasure requests, cross-border transfers to cloud vendors, and breach notice timelines. It is engineering guidance, not legal advice. Use when a feature collects or shares personal data, when adding consent banners or account deletion, when answering a data subject request, or when preparing for a privacy audit in Europe or Africa.
+license: MIT
+compatibility: Any Agent Skills host. Works on any codebase; no CLI needed. Statutory detail lives in references/jurisdictions.md and must be checked against the regulator's current text.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: compliance
+  kete-loom/risk: writes-files
+  kete-loom/owner: "Kete-org"
+---
+
+# Privacy compliance
+
+Build systems that know what personal data they hold, why they hold it, where it goes and how to delete it. Most privacy failures are engineering failures: data nobody mapped, logs nobody purged, a vendor nobody listed.
+
+## Boundary: this is not legal advice
+
+- You help with design and code. You do not decide whether processing is lawful, which law applies, or whether a breach must be reported. A lawyer or the organisation's data protection officer (DPO) decides those.
+- Say this once, plainly, when the user asks a legal question, then carry on with the engineering work.
+- **Stop and ask the user** who their DPO or privacy counsel is before you write a privacy notice, a consent text, a breach notice, or a reply to a regulator. Draft it for their review; never present it as final.
+
+## Step 1: find out which laws are in play
+
+Ask, or find in the codebase and docs:
+
+1. Where the organisation is established, and where its users live (GDPR, for example, reaches non-EU companies that target people in the EU).
+2. Which countries the data is stored or processed in (cloud regions, vendors, support teams).
+3. Whether it processes special categories: health, biometrics, religion, ethnicity, sexual life, children's data, financial or national ID numbers. These raise the bar everywhere.
+4. Whether the processing is high risk (large-scale special category data, profiling, systematic monitoring, new tech such as biometrics). GDPR and the Nigerian and Kenyan Acts all expect a data protection impact assessment (DPIA) for this. **Stop and ask the user** whether a DPIA exists before building such a feature; offer to supply the data map and controls for it.
+
+Then read `references/jurisdictions.md` for the regulator, registration duty, breach clock and transfer rules of each law. If the user's country is not listed, say so and do not guess its rules.
+
+## Step 2: map the data
+
+Search the codebase for personal data before changing anything. Look at:
+
+- Database schemas and migrations (names, emails, phone numbers, addresses, IPs, device IDs, national IDs such as Ghana Card or NIN, location, photos).
+- API request and response types, form fields, analytics events, logs, error trackers, backups, data warehouse exports, queues and caches.
+- Every third-party SDK or API the data reaches (email, SMS, payments, analytics, crash reporting, AI APIs).
+
+Write the map as a table and keep it in the repo (for example `docs/privacy/data-map.md`):
+
+| Data item | Where stored | Purpose | Lawful basis | Retention | Shared with (country) |
+|---|---|---|---|---|---|
+
+A row with an empty purpose is a finding: data with no purpose should not be collected. This table is also the core of a GDPR Article 30 record of processing.
+
+## Step 3: lawful basis and consent
+
+1. Every purpose needs one lawful basis. The usual six are consent, contract, legal obligation, vital interests, public task and legitimate interests; the African laws use the same family of grounds. Record the basis per purpose, not per user.
+2. Use consent only when the user has a real choice. If the service cannot work without the data, the basis is usually contract, not consent.
+3. When consent is the basis, build it properly:
+   - Opt-in, unticked by default, separate for each purpose (marketing email, analytics, personalised ads).
+   - Store a consent record: user id, purpose, the text or version shown, timestamp, channel, and withdrawal timestamp.
+   - Withdrawal must be as easy as giving consent and must stop the processing (unsubscribe the list, stop the analytics tag).
+   - Non-essential cookies and trackers load only after consent. Check that the tag manager actually waits.
+4. Children: if the product may be used by children, **stop and ask the user** for the age threshold their counsel has set, and build age checks and parental consent to that rule.
+
+## Step 4: minimise and protect
+
+- Collect only the fields the purpose needs. Drop "nice to have" fields such as date of birth when an over-18 checkbox will do.
+- Never write personal data into logs, URLs, analytics event names or error messages. Log user ids, not emails or phone numbers. Add a redaction filter to the logger and the error tracker.
+- Encrypt in transit (TLS) and at rest. Put national IDs and special category data in separate columns or tables with stricter access.
+- Use pseudonymous ids in analytics and data warehouses.
+- Restrict production data access by role, and keep an audit log of who read or exported personal data.
+- Never copy production personal data into development, test or staging. Use synthetic or masked data.
+
+## Step 5: retention and deletion
+
+1. Give every data item a retention period with a reason (for example "invoices: as long as tax law requires; ask finance for the number").
+2. Build a scheduled deletion or anonymisation job per table. Make it idempotent, log counts (not contents), and alert when it fails.
+3. Account deletion must reach every copy: primary database, search index, caches, object storage, analytics, the CRM and email vendors (via their deletion APIs), and backups. Backups may age out on their normal cycle if restores re-apply deletions; record that rule.
+4. Where you must keep records (tax, fraud, legal holds), keep the minimum, restrict access, and document why.
+5. Test deletion: create a user, use every feature, delete the account, then search every store for their id and email.
+
+## Step 6: data subject requests
+
+Build one internal workflow that handles access, correction, deletion, objection and portability requests:
+
+1. Verify identity using what you already hold (signed-in session, email or SMS code). Do not demand new documents you would then have to store.
+2. Log the request with a received timestamp and a due date from the applicable law (see `references/jurisdictions.md`).
+3. Access and portability: export the user's data from every system in the data map as JSON or CSV, with a readable summary.
+4. Deletion: run the Step 5 deletion path, then confirm to the user what was deleted and what was kept and why.
+5. Keep a record that the request was handled, without keeping the exported data.
+
+## Step 7: cross-border transfers and vendors
+
+- For each vendor in the data map, record its processing country and the contract that covers it (a data processing agreement, and for transfers a recognised mechanism such as an adequacy decision or standard contractual clauses).
+- Prefer cloud regions in the user's country or region when the law or the customer demands it. Check `references/jurisdictions.md` for transfer limits, and **stop and ask the user** before moving data to a new country.
+- Sending personal data to an AI or LLM API is a transfer to a processor. Check its data retention and training terms, and strip identifiers you don't need.
+
+## Step 8: breach readiness
+
+- Breach clocks are short (72 hours to the regulator is common). Build for it before it happens:
+  - Audit logs that show what data was accessed, by whom, and when.
+  - An incident runbook naming who decides on notification (DPO or counsel, not the engineer on call).
+  - A way to list affected users and their contact details quickly.
+- On a suspected breach: contain it, preserve logs, record the time the organisation became aware, and escalate to the decision maker immediately. Do not delete evidence, contact users, or post publicly unless that person tells you to.
+
+## Never
+
+- Never claim a system "is GDPR compliant" or "is NDPA compliant". Say what controls exist and what gaps remain.
+- Never invent statute numbers, deadlines or fines. If it's not in `references/jurisdictions.md` and you can't check the official text, say it is unknown.
+- Never ship pre-ticked consent boxes, dark-pattern banners, or tracking that fires before consent.
+- Never log, export or paste real user personal data into tickets, prompts or chat while doing this work.
+
+## Report format
+
+When reviewing a codebase or feature, return:
+
+```
+Privacy review: <feature or repo>
+Laws considered: <list, with why>
+Data map: <path to table, or inline table>
+Findings (highest risk first):
+  1. [High|Medium|Low] <what> at <file:line or system>: <why it matters> -> <fix>
+Gaps needing legal input: <questions for the DPO or counsel>
+Not checked: <systems or vendors you could not see>
+This is engineering guidance, not legal advice.
+```

package/skills/privacy-compliance/evals/triggers.json

@@ -0,0 +1,18 @@
+{
+  "should_trigger": [
+    "We're launching our fintech app in Nigeria and Kenya, what do we need to build for the NDPA and the Kenya Data Protection Act?",
+    "Add a cookie consent banner that actually blocks Google Analytics until the user opts in",
+    "A user emailed asking for a copy of all the data we hold about them under GDPR, how do we export it?",
+    "Build an account deletion flow that removes the user from Postgres, S3, Mailchimp and our analytics",
+    "Map all the personal data our Django app stores and tell me what retention we should set for each table",
+    "Is it okay to store Ghanaian customers' data in an AWS region in Europe? What does the Data Protection Act 843 require?"
+  ],
+  "should_not_trigger": [
+    "Our telehealth app stores patient visit notes, what HIPAA safeguards and BAAs do we need?",
+    "How do we keep card numbers out of our servers so we only need SAQ A?",
+    "Review this login endpoint for SQL injection and broken access control",
+    "Draw a threat model for our new file upload service",
+    "Write a migration that adds a nullable phone_number column to the users table",
+    "Implement JWT refresh tokens with rotation in our Express API"
+  ]
+}

package/skills/privacy-compliance/references/jurisdictions.md

@@ -0,0 +1,51 @@
+# Jurisdiction notes
+
+Engineering summary only, not legal advice. Laws, regulations and regulator guidance change: before you rely on a figure here in code, a runbook or a notice, check the regulator's current text and have the DPO or counsel confirm it. Where a cell says "confirm", this skill could not verify the figure, so do not hard-code a value.
+
+## Quick comparison
+
+| | EU / UK GDPR | Ghana: Data Protection Act, 2012 (Act 843) | Nigeria: Data Protection Act, 2023 (NDPA) | Kenya: Data Protection Act, 2019 |
+|---|---|---|---|---|
+| Regulator | National supervisory authority (UK: ICO) | Data Protection Commission (DPC) | Nigeria Data Protection Commission (NDPC) | Office of the Data Protection Commissioner (ODPC) |
+| Register with regulator | No general duty (UK: ICO data protection fee) | Yes, data controllers register with the DPC | Data controllers and processors "of major importance" register with the NDPC | Yes, controllers and processors register with the ODPC (s.18), with a small-entity exemption |
+| Breach notice to regulator | Within 72 hours of awareness, unless unlikely to risk individuals (Art. 33) | s.31 (security compromises): notify the Commission; timing and strength of the duty disputed, confirm | Within 72 hours of awareness where likely to risk individuals' rights (s.40) | Within 72 hours of awareness (s.43) |
+| Breach notice to individuals | Without undue delay when high risk (Art. 34) | s.31 also names the data subject; confirm | Required where high risk; confirm wording with counsel | In writing, within a reasonably practicable period, where there is a real risk of harm |
+| Subject access deadline | One month, extendable by two more for complex requests (Art. 12(3)) | Confirm (rights in ss.32 to 35) | Confirm | Confirm (see the Data Protection (General) Regulations, 2021) |
+| Cross-border transfer | Chapter V: adequacy, SCCs, BCRs, or narrow derogations | Confirm with counsel | Part VIII (ss.41 to 43): adequacy of protection or another listed basis | Part VI: appropriate safeguards or another listed basis; some processing may need to stay in Kenya under the regulations |
+
+## EU and UK GDPR
+
+- Lawful bases (Art. 6): consent, contract, legal obligation, vital interests, public task, legitimate interests. Special category data needs an extra condition (Art. 9).
+- Consent must be freely given, specific, informed, unambiguous and as easy to withdraw as to give (Art. 4(11), Art. 7).
+- Children and online services (Art. 8): default age 16; member states may lower it to no less than 13. The UK uses 13.
+- Records of processing (Art. 30), processor contracts (Art. 28), DPIA for high-risk processing (Art. 35), DPO in certain cases (Art. 37).
+- Rights: access (Art. 15), rectification (16), erasure (17), restriction (18), portability (20), objection (21), automated decisions (22).
+- Engineering impact: consent records, DSAR export, erasure across systems, a vendor list with transfer mechanisms, 72-hour breach runbook.
+
+## Ghana: Data Protection Act, 2012 (Act 843)
+
+- Regulator: Data Protection Commission (dataprotection.org.gh). Controllers register with the Commission, and registration is renewed periodically; confirm the current fee and renewal cycle there.
+- Security (s.28): appropriate, reasonable technical and organisational measures against loss, damage and unauthorised access.
+- Security compromise (s.31): where there are reasonable grounds to believe personal data was accessed or acquired by an unauthorised person, the Act provides for notifying the Commission and the data subject. Commentators disagree on how strong this duty is (some privacy maps say there is no explicit statutory requirement, only Commission guidance) and on its timing, so confirm with counsel and the DPC. Build for prompt notice anyway; do not hard-code a deadline.
+- Data subject access and correction: ss.32 to 35. Confirm the response deadline before building a due-date timer.
+- Engineering impact: registration evidence, security controls, a breach runbook with a named decision maker, access and correction workflow.
+
+## Nigeria: Data Protection Act, 2023 (NDPA)
+
+- Regulator: Nigeria Data Protection Commission (ndpc.gov.ng). It replaced the NDPR 2019 regime; check the NDPC site for its General Application and Implementation Directive (GAID) and current filing duties.
+- Data controllers and processors of major importance must register with the NDPC; the NDPC publishes a register.
+- Breach (s.40): processors notify the controller that engaged them; controllers notify the NDPC within 72 hours of becoming aware where the breach is likely to risk individuals' rights; keep a record of all breaches. The NDPC may make a public communication if the controller's notice to individuals is inadequate.
+- Cross-border transfer (Part VIII, ss.41 to 43): allowed where the recipient is subject to adequate protection, or on another basis the Act lists. Record the basis for each vendor outside Nigeria.
+- Engineering impact: breach records table, 72-hour runbook, transfer basis per vendor, registration status.
+
+## Kenya: Data Protection Act, 2019
+
+- Regulator: Office of the Data Protection Commissioner (odpc.go.ke).
+- Registration (s.18 and the Registration Regulations, 2021): controllers and processors must register before processing. The ODPC states an exemption for entities with turnover under KES 5 million and fewer than 10 employees, unless they process for listed purposes such as health care, education or financial services. Certificates are time-limited and must be renewed.
+- Breach (s.43): notify the Data Commissioner within 72 hours of becoming aware; tell affected data subjects in writing within a reasonably practicable period where there is a real risk of harm. The ODPC has enforced the 72-hour window strictly; a short preliminary notice followed by details is common practice.
+- Cross-border transfer: Part VI of the Act and the Data Protection (General) Regulations, 2021. Some processing may be required to happen in Kenya; ask counsel before choosing a non-Kenyan region for that data.
+- Engineering impact: registration before launch, 72-hour runbook, region choice, written notice templates.
+
+## Countries not listed
+
+Say so. Ask the user for the law and the regulator, and do not borrow another country's deadlines.

package/skills/production-scheduling/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: production-scheduling
+description: Production and job-shop scheduling for factories, print shops, kitchens and other work centres, covering capacity checks, finding the bottleneck, dispatching rules such as SPT, EDD and Johnson's rule, sequence-dependent changeovers, time and WIP buffers, rescheduling after a breakdown or rush order, and when to move from heuristics to a constraint solver like OR-Tools CP-SAT. Use when building or fixing a production schedule or scheduling tool, deciding job order across machines or lines, or replanning after a disruption.
+license: MIT
+compatibility: Any Agent Skills host. Works in a spreadsheet or code; the solver path assumes Python with the ortools package, installed only if the user agrees.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: writes-files
+  kete-loom/owner: "Kete-org"
+---
+
+# Production scheduling
+
+Produce a schedule that is feasible first (capacity, routing, calendars), good second (the user's objective), and stable third (small changes when something breaks).
+
+## 0. Model the shop, or stop and ask
+
+Collect:
+
+1. **Jobs**: ID, product, quantity, release date (material available), due date, priority.
+2. **Routings**: ordered operations per product, which machine or machine group each can run on, run time per unit, setup time.
+3. **Resources**: machines, lines, people with skills, tooling; shift calendars, planned maintenance.
+4. **Changeovers**: setup matrix from product family to product family if setups depend on sequence.
+5. **Objective**: on-time delivery (minimise lateness or late jobs), throughput (minimise makespan), or cost (minimise changeovers or overtime). If more than one, ask for the order of priority.
+
+If the objective or the routing data is missing, **stop and ask the user**. A schedule optimised for the wrong goal looks fine and fails on the floor.
+
+## 1. Check capacity before sequencing
+
+- Load per resource per period = sum of (setup + run time) of operations assigned there. Compare with available hours from the calendar after maintenance and expected downtime.
+- Any resource above ~85 to 90% load will queue badly; any above 100% makes the due dates impossible. Report it now: options are overtime, alternate routing, outsourcing, splitting lots or moving due dates. The user decides.
+- The **bottleneck** is the resource with the highest load. Its schedule sets the plant's output.
+
+## 2. Pick a method
+
+| Situation | Method |
+|---|---|
+| One machine or one bottleneck dominates | Sequence that resource with a dispatching rule, then schedule others around it |
+| Two machines in series, same order for all jobs | Johnson's rule (optimal for makespan) |
+| Many jobs, real-time dispatch on the floor | Priority rules at each machine when it frees up |
+| Sequence-dependent setups matter | Group by family (campaigns), then order families to minimise total changeover |
+| Many machines, alternative routings, hard constraints, tens to thousands of operations | Constraint solver (section 4) |
+
+Dispatching rules and what they are good for:
+- **SPT** (shortest processing time first): minimises average flow time and WIP on a single machine; can starve long jobs.
+- **EDD** (earliest due date first): minimises maximum lateness on a single machine.
+- **Critical ratio** (time to due / remaining work): balances urgency and work left; recompute at each dispatch.
+- **FIFO**: fair and simple, ignores due dates.
+- **Moore-Hodgson** (add jobs in EDD order; whenever the last added job is late, remove the longest job scheduled so far and put it at the end): minimises the number of late jobs on one machine.
+
+Johnson's rule: list jobs with times on M1 and M2. Repeatedly take the smallest remaining time; if it is on M1, put that job as early as possible; if on M2, as late as possible.
+
+## 3. Changeovers and buffers
+
+- Build the setup matrix; sequence light to dark, small to large, or by tooling family as the shop does. Big batches cut setups but raise WIP and lateness; show the trade-off.
+- Protect the bottleneck (drum-buffer-rope): a time buffer of work queued before it so it never starves, release material at the bottleneck's pace, and keep non-bottleneck resources free to catch up.
+- Add buffers before due dates for high-risk jobs rather than padding every operation.
+
+## 4. Solver path
+
+Use when heuristics break the constraints or the user needs a provably better plan. With OR-Tools CP-SAT (Python, `pip install ortools`, ask first):
+
+Current releases use snake_case names (older code shows the CamelCase aliases, such as `NewIntervalVar`); confirm against the installed `cp_model` module.
+
+1. One `new_interval_var` per operation (start, size, end); for alternative machines, one `new_optional_interval_var` per machine with its own Boolean presence literal, and `add_exactly_one` over those literals.
+2. `add_no_overlap` per machine over its intervals.
+3. Precedence: `end(op_k) <= start(op_k+1)` in each routing; release dates as lower bounds on start.
+4. Calendars: block non-working time with fixed intervals in the machine's no-overlap set.
+5. Sequence-dependent setups: use `add_circuit` over the jobs on a machine with setup-time arcs, or a simpler family-level model.
+6. Objective: makespan (`add_max_equality`), weighted tardiness (`max(0, end - due)`), or a weighted sum. Set a time limit (`solver.parameters.max_time_in_seconds`); if the status is `FEASIBLE` rather than `OPTIMAL`, report the gap between `solver.objective_value` and `solver.best_objective_bound`.
+7. Validate the solution independently: no overlaps, precedence held, calendars respected.
+
+Keep a heuristic schedule as the fallback and as a sanity check; if the solver is worse on the objective, the model is wrong.
+
+## 5. Rescheduling on disruption
+
+Breakdown, late material, rush order, absent operator:
+
+1. Freeze what is running and a short frozen window (for example the current shift) unless the user says otherwise.
+2. Right-shift affected operations as the default; it keeps the plan recognisable.
+3. Re-optimise only the unfrozen part if lateness grows past a threshold, adding a penalty for moving jobs between machines to keep stability.
+4. Report which jobs moved, new due-date risk, and what the user must tell customers.
+
+## Rules
+
+- Never schedule beyond a resource's calendar or ignore a precedence to make the plan look on time.
+- Never quietly move a committed due date; flag it for the user.
+- Never write a schedule into an MES or ERP without the user's confirmation.
+- Do not claim optimality from a heuristic; say which rule was used.
+
+## Report
+
+```
+resource | job | operation | start | end | setup | due | lateness
+```
+
+Then: objective value (makespan, late jobs, total tardiness, total setup time), bottleneck load %, infeasibilities found, assumptions, and for a reschedule the list of changed jobs.

package/skills/production-scheduling/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Sequence these 40 orders across our two injection moulding machines to minimise late jobs",
+    "Our paint line loses hours on colour changeovers, find a better job order for the week",
+    "Model our job shop in OR-Tools CP-SAT with alternative machines and shift calendars",
+    "Machine 3 just broke down for six hours, reschedule the rest of the day with minimal disruption",
+    "Which machine is our bottleneck and can we hit all the due dates this month?"
+  ],
+  "should_not_trigger": [
+    "Forecast next quarter's demand for our spare parts and set reorder points",
+    "Write an on-call rota for our SRE team across three time zones",
+    "Write a runbook for restarting the factory's MES database server",
+    "Set up a schedule in our CI to run nightly integration tests",
+    "Estimate how many sprints the new scheduling feature will take"
+  ]
+}

package/skills/prompt-engineering/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: prompt-engineering
+description: Writes, diagnoses and rewrites production prompts for language models, using clear task instructions with the context the model lacks, a few well-chosen examples, an explicit output format, splitting a hard job into chained steps, and proving each revision against a fixed set of test inputs before it ships. Use when drafting a system prompt for a new feature, fixing a prompt that gives inconsistent or off-format answers, shortening a bloated prompt, or comparing two prompt versions.
+license: MIT
+compatibility: Any Agent Skills host. Model- and provider-neutral.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: ai
+  kete-loom/risk: runs-commands
+  kete-loom/owner: "Kete-org"
+---
+
+# Prompt engineering
+
+A production prompt is code: it has a spec, a version and tests. This skill is for the words sent to the model. For the surrounding code (retries, schemas, caching) use `llm-app-patterns`; for building a full eval suite and graders use `llm-evals`.
+
+## 0. Gather before writing
+
+1. Find the current prompt in the codebase (search for the system prompt string, prompt templates or a `prompts/` folder) and how it is versioned and called.
+2. Collect 5 to 20 real inputs: a few typical, a few hard, at least one adversarial or empty. Pull them from logs or ask the user. If none exist and the user can't provide any, write them yourself and say so.
+3. Write down what a good output looks like for each input (or the rule that decides it). If you can't say what "good" is, **stop and ask the user**; no rewrite can fix an undefined target.
+4. Run the current prompt on that set and record the outputs. This is the baseline.
+
+## 1. Structure of a prompt
+
+Write in this order, keeping stable parts first so they can be cached:
+
+1. **Role and goal**: one or two sentences on who the output is for and what it is used for. Purpose beats persona.
+2. **Context**: facts the model can't know: the product, the audience, definitions of domain terms, policies. Leave out what any capable model already knows.
+3. **Instructions**: numbered steps or rules. Say what to do, not only what to avoid. Give the reason for a rule when it isn't obvious; models generalise from reasons.
+4. **Examples** (section 3).
+5. **Output format** (section 4).
+6. **Input**: the variable content, inside delimiters such as `<document>...</document>`, with a note that text inside is data, not instructions.
+
+## 2. Rules for instructions
+
+- Be specific: "Reply in 2 to 4 sentences" beats "be concise". "Use British spelling" beats "use proper English".
+- One instruction per line; no contradictions. Search the prompt for rules that conflict (for example "be brief" and "explain fully") and decide which wins.
+- Handle the edge cases you found in step 0 explicitly: missing data, off-topic input, ambiguous requests. Tell the model what to output then (for example `{"status": "insufficient_input"}`), so it doesn't invent an answer.
+- Don't shout. Emphatic wording (ALL CAPS, "CRITICAL", "you MUST") can make recent models over-apply a rule in cases where it doesn't fit. State the rule plainly, once, and add emphasis only if tests show the rule being ignored.
+- Remove instructions that no test case depends on. Shorter prompts are easier to debug.
+- Give the model room to think when the task needs reasoning: ask it to reason before the final answer, and put the answer in a separate tagged block or field your code can extract.
+
+## 3. Examples
+
+- Use 2 to 5 examples that differ from each other in the ways real inputs differ. Identical-looking examples get copied too literally.
+- Include at least one edge case example (missing field, refusal, "none found").
+- Wrap them in tags (`<example>`) so the model can tell them from instructions.
+- **Never reuse test-set inputs as examples.** That makes the evaluation meaningless.
+
+## 4. Output format
+
+- Specify the exact shape: a JSON schema, a template with headings, or a fixed list of labels. Show one complete example output.
+- For output that code parses, prefer the provider's structured output or tool calling (see `llm-app-patterns`) over asking nicely for JSON.
+- For classification, list every allowed label and what each means, plus an "other/unknown" label.
+- Say what must not appear (no preamble, no Markdown fences) only if tests show it appearing.
+
+## 5. Decomposition
+
+Split a prompt into a chain when one call is doing several jobs and failing at one of them:
+
+1. Typical split: extract → decide → write. Each step gets its own prompt, its own output schema and its own test cases.
+2. Pass only the previous step's structured output forward, not its whole transcript.
+3. Validate between steps in code; stop the chain on invalid output.
+4. Don't split when one call already passes the tests; chains add latency and cost.
+
+## 6. Iterate against the fixed set
+
+1. Change one thing at a time (an instruction, an example, the format section).
+2. Re-run the **same** inputs. Compare against the baseline case by case, not by eyeballing one output.
+3. Keep the change only if it fixes failures without breaking cases that passed. Model outputs vary, so run each case more than once (3 runs is a reasonable start) when results are close.
+4. When a new failure shows up in production, add it to the set before fixing it.
+5. Bump the prompt version and record what changed and the before/after pass counts.
+
+If after three focused revisions a case still fails, stop and report: the case, what you tried, and whether the fix needs code (decomposition, retrieval, a tool) or a different model rather than more wording.
+
+## Never
+
+- Never claim a prompt is "better" without running it on the fixed set.
+- Never tune the prompt on the same cases you report the score on and call it a fair result; keep a held-out portion (see `llm-evals`).
+- Never put secrets, internal URLs or personal data into a prompt as examples.
+- Never rely on the prompt alone to enforce security or permissions.
+
+## Report back
+
+```
+Prompt: <file or identifier>  version <old> → <new>
+Test set: <n> cases (<where they came from>)
+Baseline: <passed>/<n>   New: <passed>/<n>   (runs per case: <k>)
+Changes: <one line each>
+Still failing: <case ids and why>
+```

package/skills/prompt-engineering/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "The system prompt for our refund bot keeps answering in the wrong tone, rewrite it",
+    "Write a prompt that extracts invoice fields into JSON and handles missing totals",
+    "This 3000-word prompt is a mess, tighten it up without losing behaviour",
+    "Should I add few-shot examples to this classification prompt? Try it and show me the difference",
+    "Compare prompt v3 and v4 on these twenty sample tickets and tell me which to ship"
+  ],
+  "should_not_trigger": [
+    "Wrap the Anthropic API call in retries and a timeout",
+    "Set up a regression dashboard that scores every model release on our eval set",
+    "Grade our agent's last 100 transcripts against the rubric and summarise failures",
+    "Write the marketing copy for our launch email",
+    "Design how the planner and worker agents hand off tasks in our harness"
+  ]
+}

package/skills/prospect-research/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: prospect-research
+description: B2B prospect list building and enrichment from public sources such as company websites, filings, job posts, press and public directories, with a written ideal-customer-fit scorecard, a 0-100 fit score and a cited reason per account, buying-committee roles to contact, and warm-introduction paths found in the user's own contacts and investors, while keeping to platform terms and privacy law with no scraping behind logins. Use when a founder or sales team needs a target account list researched, scored and enriched before any outreach is written, or wants to know who in their network can introduce them to a target company.
+license: MIT
+compatibility: Any Agent Skills host. Web access helps for public research; the user supplies their own contact exports. Not legal advice on data protection.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: business
+  kete-loom/risk: network
+  kete-loom/owner: "Kete-org"
+---
+
+# Prospect research
+
+Produce a short, ranked list of accounts that fit, the people to approach at each, and the warmest way in, with a source for every fact. Writing the outreach itself is the job of `cold-outreach-sequences`; sizing the whole market is `market-research`.
+
+## Ground rules
+
+1. **Public and permitted sources only.** Company websites, annual reports and company registries, regulator registers, press releases and news, job postings, conference speaker lists, public GitHub orgs, app store listings, and data providers the user already licenses. Never log in to a site to collect data, never bypass a paywall, rate limit or robots.txt, and never automate collection from a platform whose terms forbid it (LinkedIn's User Agreement forbids scraping and automated access; the user may look profiles up by hand).
+2. **Cite or drop.** Every fact on the list carries a source URL or document and an access date. A guess is marked as a guess or left out.
+3. **Business data, minimum personal data.** Collect name, role, company and a business contact route only. No home addresses, personal phone numbers, family details, photos or anything about health, religion, politics or other special categories.
+4. **No guessed emails sent blind.** Pattern-guessed addresses are marked "unverified" and are not a substitute for a lawful basis to contact someone.
+5. **The user's network data stays theirs.** Contact exports the user shares are used for matching only, are not added to the prospect file wholesale, and are not sent to any third-party service without the user's say-so.
+
+## Step 1: Write the ideal-customer-fit scorecard
+
+Ask the user for their best five to ten current customers (or design partners) and what made each a good fit. From that, agree on four to six criteria with weights that sum to 100, for example:
+
+| Criterion | Weight | Evidence that counts |
+|---|---|---|
+| Industry / segment | 25 | registry SIC/NAICS code, website |
+| Size (staff or revenue band) | 20 | filings, registry, headcount on careers page |
+| Trigger event in last 6 months | 25 | funding, new market, hiring for a role, regulation change |
+| Tech or process fit | 20 | job posts naming tools, public integrations, docs |
+| Geography / language | 10 | registered office, markets served |
+
+Add **disqualifiers** (too small, existing competitor customer under contract, sanctioned country, already a customer). Stop and ask the user to confirm the scorecard before researching any account.
+
+## Step 2: Build the account list
+
+1. Start from sources that list many companies at once: industry association member lists, registries filtered by code and region, event exhibitor lists, investor portfolio pages, marketplace or integration directories.
+2. Deduplicate by legal entity and domain; note parent companies and subsidiaries.
+3. Aim for 1.5 to 2 times the number of accounts the user wants, because scoring will cut some.
+
+## Step 3: Enrich and score each account
+
+For each account record: legal name, domain, country, size band, segment, the trigger (with date and source), tech or process signals, and any disqualifier. Score each criterion 0, half or full weight from the evidence, sum to a 0-100 fit score, and write one line saying why. Mark accounts with fewer than three sourced criteria as "thin evidence" instead of scoring them high.
+
+Tiers: **A** 75+, **B** 50-74, **C** below 50 (park, don't contact).
+
+## Step 4: Map the buying committee
+
+For A and B accounts, list the roles that matter (economic buyer, champion or user, technical evaluator, possible blocker) and the named person only where a public source shows them in that role now. Note the source and date; people move, so anything older than 12 months is "check before contact".
+
+## Step 5: Find warm-intro paths
+
+Ask the user for what they are willing to share: a contacts export, a list of investors, advisers, past employers, customers who would refer, alumni groups. Match on company domain and past employers. For each A account, rank the paths:
+
+1. A current customer or investor who knows someone at the account.
+2. A former colleague who now works there or recently did.
+3. A shared investor, adviser or community.
+4. A public route: speaking at the same event, a mutual open-source project.
+
+For each path, write who to ask, what to ask them for, and a two-line forwardable blurb. Never contact anyone on the user's behalf.
+
+## Privacy and compliance checks
+
+- **EU and UK prospects:** personal data about named people is covered by the GDPR and UK GDPR even in a B2B context. The user needs a lawful basis (usually legitimate interests, with a documented balancing test), and Article 14 requires telling a person whose data you collected from elsewhere, at the latest within one month or at the first communication. Keep a record of the source of each person's data.
+- **Electronic marketing rules differ by country** (for example PECR in the UK, national rules in Germany that are stricter about unsolicited email). Flag the country; leave the decision on whether to email to the user and `cold-outreach-sequences`.
+- **Opt-outs and existing suppression lists** from the user's CRM must be checked before anyone is added.
+- This skill is not legal advice; for a large programme or a regulated sector, recommend the user's data protection lead or counsel reviews the basis and notices.
+
+## Stop and ask the user
+
+- Before research starts, to confirm the scorecard, target count and regions.
+- If a requested source needs a login, a paid seat the user has not mentioned, or automated collection from a platform that forbids it.
+- If the user asks for personal data beyond business contact details, or for people in a country whose rules you have not checked.
+
+## Output
+
+Return a table (or a CSV the user can import) and a summary:
+
+```
+Account | Domain | Country | Size | Fit | Tier | Why (one line) | Trigger (date, source) | Roles / named people (source, date) | Warm path | Evidence gaps
+```
+
+Then: the scorecard used, how many accounts were found, scored and parked, the sources used with access dates, accounts marked "thin evidence", and the privacy points the user must act on before outreach.

package/skills/prospect-research/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Build me a list of 50 mid-size logistics companies in Kenya that fit our ICP, scored and with sources",
+    "Define our ideal customer profile from these ten customers and score this list of target accounts against it",
+    "Who in my LinkedIn connections export or our investor list could introduce me to people at these 20 target companies?",
+    "Enrich this account list with company size, recent funding and hiring signals before our sales team starts outreach",
+    "Find the economic buyer and technical evaluator at each of these fintechs using public sources only"
+  ],
+  "should_not_trigger": [
+    "Write a four-step cold email sequence to the heads of operations on our prospect list",
+    "Size the market for fleet management software in East Africa with TAM, SAM and SOM",
+    "Our outbound emails are going to spam since we started a new sending domain, fix our DMARC",
+    "Plan our launch campaign channels, calendar and budget for next quarter",
+    "Triage my inbox this morning and draft replies to the urgent ones"
+  ]
+}