@ketecode/loom 0.0.0-stage → 0.1.0

package/skills/dependency-audit/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: dependency-audit
+description: Software supply-chain audit of a project's third-party packages across npm, pnpm, Yarn, pip/uv, Cargo, Go modules and similar ecosystems. Runs the ecosystem's vulnerability scanner, checks that lockfiles exist and are enforced in CI, vets new or suspicious packages for typosquatting, install scripts and abandoned maintainers, and sets a pinning, update-cadence and SBOM policy. Use when a scanner or Dependabot reports a vulnerable package, before adding a new library, when asked whether the project's dependencies are safe, or when setting up dependency hygiene and an SBOM for a release.
+license: MIT
+compatibility: Any Agent Skills host. Needs the project's package manager; audit tools such as pip-audit, cargo-audit, govulncheck or osv-scanner are used when installed. Advisory lookups need network access.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: network
+  kete-loom/owner: "Kete-org"
+---
+
+# Dependency audit
+
+Find the third-party code that can hurt this project, and leave behind a policy that keeps it from creeping back. Report first; change manifests or lockfiles only when the user asks.
+
+## 1. Inventory
+
+1. Find every manifest and lockfile: `package.json` + `package-lock.json` / `pnpm-lock.yaml` / `yarn.lock` / `bun.lock`, `pyproject.toml` + `uv.lock` / `poetry.lock` / `requirements*.txt`, `Cargo.toml` + `Cargo.lock`, `go.mod` + `go.sum`, `Gemfile.lock`, `composer.lock`, `*.csproj` / `packages.lock.json`, Dockerfiles and CI files that install tools.
+2. Flag any manifest with **no lockfile**, or a lockfile not committed. An application without a committed lockfile is a finding on its own.
+3. Note which package manager CI uses and whether it installs from the lockfile strictly (`npm ci`, `pnpm install --frozen-lockfile`, `yarn install --immutable`, `uv sync --locked`, `cargo build --locked`, `pip install --require-hashes -r requirements.txt`).
+
+## 2. Scan for known vulnerabilities
+
+Run the scanner for each ecosystem present. Exact commands and flags are in `references/tools.md`; the defaults:
+
+| Ecosystem | Command |
+|---|---|
+| npm | `npm audit --omit=dev` (then without `--omit` for dev tooling) |
+| pnpm / Yarn | `pnpm audit`, `yarn npm audit` (Yarn Berry) |
+| Python | `pip-audit -r requirements.txt` or `pip-audit` in the project env |
+| Rust | `cargo audit` |
+| Go | `govulncheck ./...` |
+| Any (lockfile based) | `osv-scanner scan -r .` |
+
+If a tool is not installed, say so and suggest the install command; **ask before installing** anything globally.
+
+For each advisory, decide reachability before ranking it:
+
+- Is the package in production code, or only dev/build/test tooling?
+- Is the vulnerable function or code path used? `govulncheck` reports this for Go; elsewhere, search the codebase for the affected API.
+- Is it exposed to untrusted input (HTTP bodies, uploads, user-supplied URLs, parsers)?
+
+A critical CVE in a test-only dependency is lower priority than a moderate one in the request parser.
+
+## 3. Vet risky packages
+
+Do this for packages added in the change under review, and for any package the scan or the user flags.
+
+1. **Typosquatting**: compare the name against the well-known package it resembles (`reqeusts` vs `requests`, `lodahs` vs `lodash`, scope swaps like `@type/node`). Check the registry page: download count, repository link, first publish date, maintainer.
+2. **Install scripts**: look for `preinstall`, `install`, `postinstall` in the package's `package.json`, or `setup.py` / build backends that run code at install. Network calls, obfuscated code, or reading env vars in an install script is a **stop and tell the user** finding.
+3. **Health**: last release, open security issues, single maintainer, archived repository, recent maintainer change followed by a new major or patch with unexplained binary or minified code.
+4. **Necessity**: can a few lines of standard library replace it? Fewer dependencies is the best mitigation.
+
+Never install, import or run a suspect package to "see what it does".
+
+## 4. Fix
+
+Prefer the smallest safe change, in this order:
+
+1. Bump to the lowest patched version within the same major (`npm audit fix` without `--force`; `cargo update -p <crate>`; `go get <module>@<version>` then `go mod tidy`).
+2. If the vulnerable package is transitive, update the direct parent first. Use an override (`overrides` in npm, `pnpm.overrides`, `resolutions` in Yarn, `[tool.uv] override-dependencies`) only when the parent has no fixed release, and leave a comment with the advisory ID and a date to remove it.
+3. A major-version bump, a replacement library, or `npm audit fix --force` changes behaviour: **stop and ask** before doing it.
+4. If no fix exists, document the advisory, why it is or is not reachable, and the compensating control. Record ignores in the tool's own config (for example `audit.toml` for cargo-audit, `--ignore-vuln` for pip-audit) with a reason and expiry, never by deleting the check.
+
+After any change, run the project's install from the lockfile, the build and the tests, then re-run the scanner to show the advisory is gone.
+
+## 5. Policy to leave behind
+
+Recommend what is missing, briefly:
+
+- **Pinning**: applications commit lockfiles and install strictly in CI. Libraries keep compatible ranges in the manifest but still commit a lockfile for their own CI. Pin CI actions and container base images by digest or full commit SHA, not a moving tag.
+- **Install scripts**: disable by default where the tool supports it (`npm ci --ignore-scripts`; pnpm 10+ only runs build scripts for packages you allow) and allow-list the packages that need them.
+- **Release-age cooldown**: if the package manager supports a minimum release age, set a few days so a freshly hijacked release is not picked up at once (see `references/tools.md`).
+- **Updates**: automated update PRs (Dependabot or Renovate) grouped weekly for patch/minor, security updates immediately, majors reviewed by hand. Every update PR runs the full test suite.
+- **Gate**: the scanner runs in CI and fails on high or critical in production dependencies (`npm audit --omit=dev --audit-level=high`).
+- **SBOM**: generate one per release in CycloneDX or SPDX (`npm sbom --sbom-format cyclonedx`, `syft <dir-or-image> -o cyclonedx-json`, `cargo cyclonedx`) and store it with the release artifacts. Details in `references/tools.md`.
+- **Registry**: for private scoped packages, map the scope to the private registry explicitly so a public package with the same name cannot be resolved (dependency confusion).
+
+## Never
+
+- Never run `npm audit fix --force`, delete a lockfile, or bump a major without asking.
+- Never silence an advisory without a recorded reason.
+- Never paste registry tokens or `.npmrc` / `pip.conf` credentials into output.
+- Never call a project "safe": state which ecosystems and lockfiles were scanned and when.
+
+## Report format
+
+```
+## Dependency audit: <project> (<date>)
+Scanned: <ecosystems, lockfiles, tools and versions>   Not scanned: <what and why>
+
+### Findings
+1. [critical|high|medium|low] <package>@<version> (<direct|transitive via X>, <prod|dev>)
+   Advisory: <ID> <one line>   Reachable: <yes/no/unknown + evidence>
+   Fix: <exact version or action>   Breaking: <yes/no>
+
+### Supply-chain risks
+- <typosquat / install script / unmaintained / no lockfile / unpinned CI action>
+
+### Policy gaps
+- <missing item from section 5, one line each>
+```

package/skills/dependency-audit/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Dependabot flagged a critical vulnerability in a transitive dependency, how do I fix it safely?",
+    "Audit our Python and Rust dependencies for known vulnerabilities",
+    "Is this npm package safe to add? It has a postinstall script and only 200 weekly downloads",
+    "Set up a dependency update and pinning policy plus an SBOM for our releases",
+    "Check if we're exposed to any supply chain attacks through our lockfiles and CI installs"
+  ],
+  "should_not_trigger": [
+    "Upgrade our app from React 18 to React 19 and fix the breaking changes",
+    "The build fails with a module not found error after npm install",
+    "Scan the diff on this branch for hardcoded secrets and SQL injection",
+    "Set up a GitHub Actions workflow that runs tests on every pull request",
+    "Threat model how an attacker could tamper with our deployment pipeline"
+  ]
+}

package/skills/dependency-audit/references/tools.md

@@ -0,0 +1,124 @@
+# Dependency audit: tool reference
+
+Read this when you need the exact command for an ecosystem. Flags change between releases: if a command fails, check `<tool> --help` and the tool's docs before guessing.
+
+## Vulnerability scanners
+
+### npm
+
+```
+npm audit                          # all dependencies
+npm audit --omit=dev               # production dependencies only
+npm audit --audit-level=high       # exit non-zero only at high or critical (does not filter the report)
+npm audit --json                   # machine-readable
+npm audit signatures               # verify registry signatures and provenance attestations of installed packages
+npm audit fix                      # semver-compatible fixes only
+npm ls <package>                   # who pulls in a transitive dependency
+```
+
+`npm audit fix --force` can install breaking majors. Ask first.
+
+### pnpm and Yarn
+
+```
+pnpm audit [--prod] [--audit-level high]
+pnpm audit --ignore <GHSA-ID>             # documented exception, saved to pnpm-workspace.yaml
+pnpm why <package>
+yarn npm audit [--all] [--recursive]      # Yarn Berry (2+)
+yarn why <package>
+```
+
+### Python
+
+```
+pip-audit                          # current environment
+pip-audit -r requirements.txt      # a requirements file
+pip-audit --ignore-vuln <ID>       # documented exception
+```
+
+For uv projects, export the lock first if needed (`uv export --format requirements-txt > /tmp/req.txt`) and run `pip-audit -r` on it.
+
+Hash-checked installs: `pip install --require-hashes -r requirements.txt` (generate hashes with `pip-compile --generate-hashes` or `uv pip compile --generate-hashes`).
+
+### Rust
+
+```
+cargo install cargo-audit --locked     # once
+cargo audit                            # RustSec advisory DB against Cargo.lock
+cargo tree -i <crate>                  # who depends on a crate
+```
+
+Ignores go in `.cargo/audit.toml` under `[advisories] ignore = ["RUSTSEC-..."]`. `cargo deny check` (cargo-deny) adds licence, banned-crate and duplicate checks.
+
+### Go
+
+```
+go install golang.org/x/vuln/cmd/govulncheck@latest
+govulncheck ./...                  # reports only vulnerabilities your code can reach
+go mod why -m <module>
+```
+
+### Others
+
+| Ecosystem | Command |
+|---|---|
+| Ruby | `bundle audit check --update` (bundler-audit) |
+| PHP | `composer audit` |
+| .NET | `dotnet list package --vulnerable --include-transitive` |
+| Java/Kotlin | OWASP Dependency-Check, or `osv-scanner` on the Gradle/Maven lockfile |
+| Containers | `trivy image <image>` or `grype <image>` |
+
+### osv-scanner (multi-ecosystem)
+
+```
+osv-scanner scan -r .                  # every lockfile under the directory
+osv-scanner scan -L package-lock.json  # one lockfile
+```
+
+## Strict installs in CI
+
+| Tool | Command |
+|---|---|
+| npm | `npm ci` |
+| pnpm | `pnpm install --frozen-lockfile` |
+| Yarn Berry | `yarn install --immutable` |
+| uv | `uv sync --locked` |
+| Poetry | `poetry install` with the lock committed; `poetry check --lock` |
+| Cargo | `cargo build --locked` |
+| Go | `go mod verify` (checks downloaded modules against go.sum) |
+
+## Install scripts
+
+- npm: `ignore-scripts=true` in `.npmrc`, or `npm ci --ignore-scripts`. Scripts you run by name (`npm test`, `npm run build`) still run; their pre/post hooks do not.
+- pnpm 10+: dependency lifecycle scripts do not run unless allowed. Older 10.x releases use `pnpm.onlyBuiltDependencies`; newer releases document `allowBuilds` in `pnpm-workspace.yaml`. `pnpm approve-builds` and `pnpm ignored-builds` manage the list. Check the docs for the installed version.
+- Python: source distributions run build code at install. Prefer wheels (`pip install --only-binary :all:` where feasible) for untrusted packages.
+
+## Release-age cooldown
+
+Delays picking up versions published in the last few days. Units differ; check the docs for your installed version before relying on these:
+
+| Tool | Setting | Unit |
+|---|---|---|
+| npm | `min-release-age` in `.npmrc` | days |
+| pnpm | `minimumReleaseAge` | minutes |
+| uv | `exclude-newer` (absolute timestamp; recent releases accept durations) | timestamp or duration |
+
+Automated update tools have their own equivalent (Renovate `minimumReleaseAge`, Dependabot `cooldown` with `default-days`). Dependabot's cooldown applies to version updates, not security updates.
+
+## SBOM
+
+```
+npm sbom --sbom-format cyclonedx > sbom.cdx.json   # from package-lock.json
+npm sbom --sbom-format spdx > sbom.spdx.json
+pnpm sbom --sbom-format cyclonedx                  # pnpm 11+
+syft . -o cyclonedx-json > sbom.cdx.json           # a directory; or syft <image>
+cargo cyclonedx                                    # after: cargo install cargo-cyclonedx
+```
+
+Generate the SBOM from the exact lockfile or image that ships, attach it to the release, and scan it later (for example `grype sbom:sbom.cdx.json`) when new advisories appear.
+
+## Pinning CI and images
+
+- GitHub Actions: `uses: actions/checkout@<full 40-char commit SHA> # vX.Y.Z`.
+- Containers: `FROM node:22-slim@sha256:<digest>`.
+- Tools installed with `curl | sh` in CI: pin a version and verify a checksum.

package/skills/deployment-strategies/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: deployment-strategies
+description: Plans and runs low-risk production releases with blue-green switches, progressive canary rollouts, feature flags that separate deploy from release, expand-and-contract database changes ordered so old and new code both work, readiness and liveness health checks, rollback triggered automatically by error and latency signals, and smoke tests after every deploy. Use when shipping a risky change to production, designing a rollout or rollback plan, deploying alongside a schema change, or deciding between blue-green, canary and flags.
+license: MIT
+compatibility: Any Agent Skills host and any platform (Kubernetes, ECS, Cloud Run, App Service, VMs). Commands depend on the project's deploy tooling.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: runs-commands
+  kete-loom/owner: "Kete-org"
+---
+
+# Deployment strategies
+
+Ship so that a bad release reaches few users, is detected by numbers rather than by complaints, and can be undone in minutes without losing data. CI pipeline mechanics are in `github-actions-ci`; migration tooling in `database-migrations`; tags and changelogs in `release-management`.
+
+## Ground rules
+
+1. **Rollback must be possible before you roll forward.** Know the exact rollback command and that the previous version still runs against the current database. If you can't say how to undo a deploy, **stop and ask** before deploying.
+2. **Deploy is not release.** Code can reach production switched off behind a flag; releasing is turning it on for users.
+3. **Build once, promote the same artifact** (image digest, not a tag like `latest`) through staging to production.
+4. **Every version must run against the schema of its neighbour.** During any rollout old and new code run at the same time.
+5. **Decide health by signals agreed in advance:** error rate, latency (p95/p99), saturation, and one business metric (checkouts, sign-ins). Write the thresholds down before you start.
+6. **Production changes need the user's go-ahead.** Ask before each promotion step unless the user has approved an automated rollout with defined thresholds.
+
+## Choosing a strategy
+
+| Situation | Strategy |
+|---|---|
+| Small low-risk change, good tests, fast rollback | Rolling update with health checks |
+| Need instant full cutover and instant revert, can afford double capacity briefly | Blue-green |
+| Risky change, enough traffic for statistics | Canary (1% → 5% → 25% → 50% → 100%) |
+| Behaviour change you want to target, test in prod, or kill quickly | Feature flag (with any deploy method) |
+| Schema change | Expand and contract, always, combined with one of the above |
+
+Low-traffic services can't produce meaningful canary statistics; use blue-green plus a flag instead.
+
+## Health checks
+
+- **Readiness:** "can this instance serve traffic now?" Checks the app is initialised and can reach its required dependencies. Load balancers and orchestrators route only to ready instances.
+- **Liveness:** "is this process stuck?" Checks only the process itself. Never make liveness depend on a database or downstream service, or one outage restarts every pod.
+- **Startup grace:** give slow-starting apps a startup probe or initial delay so they aren't killed while booting.
+- Implement graceful shutdown: on SIGTERM stop accepting new requests, finish in-flight ones, then exit.
+
+## Blue-green
+
+1. Deploy the new version (green) beside the live one (blue), on the same database.
+2. Run smoke tests against green directly.
+3. Switch traffic at the router (load balancer target, DNS weight, slot swap, service selector).
+4. Watch the signals for an agreed window. Keep blue running and untouched.
+5. Revert by switching back. Remove blue only after the window passes.
+
+## Canary
+
+1. Route a small slice of traffic (or an internal cohort) to the new version.
+2. Compare canary vs baseline on the agreed signals, not against last week.
+3. Promote in steps, holding at each long enough to see real traffic. Automate with the platform's progressive delivery tool (Argo Rollouts, Flagger, ECS/CodeDeploy, Cloud Run traffic splitting, App Service slots with traffic percentage) where available.
+4. **Automatic rollback:** if any threshold is breached, shift all traffic back and alert. A human decides when to retry.
+
+## Feature flags
+
+- Default off; ship the code dark, then enable for staff, then a percentage, then everyone.
+- Flag checks happen server-side for anything that matters for security or money.
+- Every flag has an owner and a removal date. Delete the flag and the dead branch once it is at 100% and stable.
+- A kill switch for a risky dependency is a flag too: test that turning it off works.
+
+## Database-compatible ordering (expand and contract)
+
+Never ship a schema change and code that needs it in a single step. For renaming a column, for example:
+
+1. **Expand:** add the new column (nullable or with a default). No code change. Old code ignores it.
+2. **Dual write:** deploy code that writes both columns and reads the old one.
+3. **Backfill** existing rows in batches, outside the deploy.
+4. **Switch reads:** deploy code that reads the new column (still writing both).
+5. **Stop writing the old column:** deploy.
+6. **Contract:** drop the old column in a later release, once no running or rollback-target version uses it.
+
+Rules: additive changes go before the code that uses them; destructive changes go after the code stops using them. Avoid migrations that lock big tables during a deploy; see `database-migrations`. **Stop and ask** before any step that drops or rewrites data.
+
+## Post-deploy verification
+
+1. Confirm the running version is the one you meant (version endpoint, image digest).
+2. Run smoke tests for the critical paths: sign-in, the main read, the main write, payment if any.
+3. Check the dashboards for the agreed signals over the hold window, and the error tracker for new error types.
+4. Confirm background workers and scheduled jobs picked up the new version too.
+5. Announce completion, or roll back and announce that.
+
+## Never
+
+- Deploy on top of a failing or unknown-state production.
+- Run destructive migrations in the same release as the code change.
+- Remove the old environment or the rollback artifact before the hold window ends.
+- Turn off alerts "to get through the deploy".
+
+## Rollout plan format
+
+Produce this before deploying anything non-trivial:
+
+```
+Change: <what ships>
+Strategy: <rolling | blue-green | canary | flag> and why
+Schema steps: <expand/contract steps and which release each goes in>
+Signals and thresholds: <metric: limit>
+Steps: <numbered, with hold time per step>
+Rollback: <exact command or action, and how long it takes>
+Verification: <smoke tests and dashboards>
+Approval needed at: <steps where you stop for the user>
+```

package/skills/deployment-strategies/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "We need to rename a column in production without downtime while the new code rolls out",
+    "Design a canary release for the new search service with automatic rollback on error rate",
+    "Blue-green or canary for our monolith that gets very little traffic?",
+    "Put the new pricing page behind a feature flag so we can deploy it dark and turn it on later",
+    "What should our readiness and liveness probes check, and how do we verify a deploy worked?"
+  ],
+  "should_not_trigger": [
+    "Write the Alembic migration that adds an index to the orders table",
+    "Add a matrix build to our GitHub Actions workflow",
+    "Tag version 2.4.0 and write the release notes",
+    "Choose between App Service and Container Apps on Azure",
+    "Our Kubernetes pods are stuck in CrashLoopBackOff, help me read the events"
+  ]
+}

package/skills/django-patterns/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: django-patterns
+description: Django project conventions for building and changing apps, covering app layout, ORM query efficiency with select_related and prefetch_related, safe migrations, forms and model validation, auth and permission checks, per-environment settings, Celery tasks that run after commit, and production security settings. Use when adding a Django model, view, form or Celery task, fixing slow querysets, planning a schema migration, or hardening Django settings for deployment.
+license: MIT
+compatibility: Any Agent Skills host. Needs Python and the project's Django manage.py. Guidance targets currently supported Django releases.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "python"
+  kete-loom/owner: "Kete-org"
+---
+
+# Django patterns
+
+Write Django code that follows the project's existing shape, issues a predictable number of queries, and keeps schema changes reversible.
+
+## 0. Before you change anything
+
+1. Find the settings module (`DJANGO_SETTINGS_MODULE` in `manage.py`, `wsgi.py`, `asgi.py` or the env) and the Django version in `pyproject.toml` or `requirements*.txt`.
+2. Find how tests run (`pytest` with `pytest-django`, or `python manage.py test`). Run them once and record the result. If they already fail, **stop and tell the user**.
+3. Run `python manage.py check`. Fix nothing unrelated; just note warnings.
+4. Copy the conventions already there: class-based or function views, DRF or plain views, where services and selectors live.
+
+## 1. App structure
+
+- One app per bounded area (`billing`, `accounts`), not per model. Avoid cyclic imports between apps; refer to other apps' models with the `"app_label.Model"` string in `ForeignKey`.
+- Keep views thin: parse input, call a function, return a response. Put multi-model business logic in a plain module (`services.py`) and read-heavy query building in `selectors.py` or a custom `QuerySet`/`Manager`, if the project does that.
+- Always reference the user model with `settings.AUTH_USER_MODEL` (in models) or `get_user_model()` (in code), never `django.contrib.auth.models.User` directly.
+- Define `__str__` on every model. Set `Meta.ordering` only when every query needs that order (it adds an `ORDER BY` to every query). Put invariants in `Meta.constraints` (`UniqueConstraint`, `CheckConstraint`) rather than relying on form validation alone.
+
+## 2. Query efficiency
+
+Count queries before and after. In tests use `django_assert_num_queries` (pytest-django) or `self.assertNumQueries(n)`.
+
+| Access pattern | Use |
+|---|---|
+| Forward `ForeignKey` / `OneToOne` used in a loop or template | `select_related("author")` (SQL join) |
+| Reverse FK or `ManyToMany` used in a loop | `prefetch_related("tags")` (one extra query) |
+| Prefetch with a filter or its own `select_related` | `Prefetch("items", queryset=Item.objects.select_related("sku"))` |
+| Only need a few columns | `only(...)`, `values(...)` or `values_list(..., flat=True)` |
+| Counting or existence | `.count()`, `.exists()`, never `len(qs)` or `if qs:` on a big queryset |
+| Per-row totals | `annotate(Count(...), Sum(...))`, not a query per row |
+| Bulk writes | `bulk_create`, `bulk_update`, `qs.update(...)`; remember these skip `save()` and signals |
+| Race-free increments | `F("stock") - 1` with `update()`, or `select_for_update()` inside `transaction.atomic()` |
+
+Rules:
+- Any loop over a queryset that touches a relation is an N+1 until proven otherwise.
+- DRF serializers with nested serializers need the matching `select_related`/`prefetch_related` in the view's `get_queryset`.
+- Iterate huge tables with `.iterator(chunk_size=...)`; paginate anything user-facing.
+- Raw SQL: use `params=[...]` with `raw()` or `cursor.execute(sql, params)`. **Never** build SQL with f-strings or `%` formatting on user input, and never pass user input to `extra()` or `RawSQL` without params.
+
+## 3. Migrations
+
+1. Change models, then run `python manage.py makemigrations <app>`. Read the generated file; rename it if the auto name is meaningless.
+2. Show the SQL for risky steps: `python manage.py sqlmigrate <app> <number>`.
+3. Run `python manage.py makemigrations --check --dry-run` to prove nothing is left ungenerated. Add it to CI if missing.
+4. Apply locally with `python manage.py migrate`, then roll back with `python manage.py migrate <app> <previous_migration_name>` and re-apply to prove reversibility.
+
+Safe-change rules for tables with live traffic:
+- Adding a non-null column: add it nullable (or with a database default), backfill in a separate data migration, then make it non-null in a later migration.
+- Removing or renaming a column: first ship code that no longer reads it, then drop it in the next release. `RenameField` breaks old code still running during a rolling deploy.
+- Data migrations use `RunPython(forwards, backwards)` with `apps.get_model("app", "Model")`, never a direct import of the model class. Supply a `backwards` function or `RunPython.noop` deliberately.
+- On PostgreSQL, add indexes to big tables with `AddIndexConcurrently` in a migration with `atomic = False`.
+- **Stop and ask the user** before writing a migration that drops a column or table, rewrites a large table, or squashes migrations other branches may depend on.
+- Never edit a migration that has already been applied anywhere shared; add a new one.
+
+## 4. Forms and validation
+
+- Validate user input with a `Form`/`ModelForm` (or DRF serializer). Use `form.cleaned_data`, never `request.POST[...]` directly.
+- Field-level checks go in `clean_<field>()`, cross-field checks in `clean()`. Invariants that must hold everywhere belong on the model (`clean()` plus database constraints), because `save()` does not call `full_clean()`.
+- Always list `fields` explicitly on a `ModelForm`; never `fields = "__all__"` or `exclude` for forms users submit, or a new model field becomes writable.
+- Keep CSRF on. `@csrf_exempt` is only for endpoints authenticated another way (signed webhooks), with a comment saying why.
+
+## 5. Auth and permissions
+
+- Every view that is not public needs an explicit check: `@login_required`, `LoginRequiredMixin`, `@permission_required`, `PermissionRequiredMixin`, or DRF `permission_classes`.
+- Authentication is not authorization. Scope object lookups to the user: `get_object_or_404(Invoice, pk=pk, owner=request.user)`, or filter `get_queryset()` by owner/tenant. Never fetch by `pk` alone and trust it.
+- Check DRF's `DEFAULT_PERMISSION_CLASSES`; if it is `AllowAny`, every view must set its own.
+- Use `user.has_perm("app.change_model")` for permissions; don't compare group names in code.
+
+## 6. Settings per environment
+
+- One settings package (`settings/base.py`, `dev.py`, `prod.py`) or one module reading environment variables (`django-environ`, `os.environ`). Follow whichever exists.
+- Secrets (`SECRET_KEY`, database password, API keys) come from the environment, never from committed files. Fail at startup if a required secret is missing in production.
+- `DEBUG = False` in production, with `ALLOWED_HOSTS` set explicitly.
+
+## 7. Celery tasks
+
+- Pass IDs to tasks, not model instances or querysets; reload inside the task.
+- Enqueue after the transaction commits: `transaction.on_commit(lambda: send_receipt.delay(order.id))` (Celery 5.4+ also offers `send_receipt.delay_on_commit(order.id)`). Enqueuing inside `atomic()` lets the worker read data that isn't committed yet, or that is rolled back.
+- Make tasks idempotent; brokers can deliver twice. Use `autoretry_for`, `retry_backoff` and `max_retries` for transient errors only.
+- Set time limits (`soft_time_limit`, `time_limit`) on anything that calls the network.
+- In tests, call the task function directly, or enable eager mode only in test settings. With the usual `config_from_object("django.conf:settings", namespace="CELERY")` the key is `CELERY_TASK_ALWAYS_EAGER`; check the project's namespace before naming it.
+
+## 8. Production security settings
+
+Run `python manage.py check --deploy --settings=<prod settings>` and resolve each warning or document why it doesn't apply. The usual set:
+
+```python
+DEBUG = False
+SECURE_SSL_REDIRECT = True          # unless the proxy already redirects
+SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")  # only behind a proxy that sets it
+SESSION_COOKIE_SECURE = True
+CSRF_COOKIE_SECURE = True
+SECURE_HSTS_SECONDS = 31536000      # start small (e.g. 3600) and raise once HTTPS is confirmed
+SECURE_CONTENT_TYPE_NOSNIFF = True
+X_FRAME_OPTIONS = "DENY"
+CSRF_TRUSTED_ORIGINS = ["https://app.example.com"]
+```
+
+- Never render user content with `mark_safe`, `|safe` or `format_html` misuse; let templates autoescape.
+- Uploaded files: validate type and size, and never serve `MEDIA_ROOT` from the same origin with executable content types.
+
+## Rules
+
+- Never disable a security middleware, CSRF, or a permission check to make a test pass.
+- Never run `migrate` against a shared or production database yourself; hand the user the command.
+- Never commit secrets or a `DEBUG = True` production settings file.
+
+## Report back
+
+End with: files changed, migrations created (with the `sqlmigrate` summary for risky ones), query counts before and after for any queryset you optimised, the test command and its result, and any `check --deploy` warning left open.

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

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "This Django list view runs 300 queries, help me fix it with select_related or prefetch_related",
+    "Add a non-null column to the Order model in Django without breaking the live deploy",
+    "Set up a Celery task in our Django app that emails the receipt after checkout",
+    "Split our Django settings.py into dev and prod and fix what manage.py check --deploy complains about",
+    "Create a ModelForm with cross-field validation for the booking app"
+  ],
+  "should_not_trigger": [
+    "Review my Django pull request for N+1 queries and missing permission checks",
+    "Build a FastAPI router with Pydantic request models",
+    "Create a Flask application factory with blueprints",
+    "Write pytest fixtures for a plain Python utility module",
+    "Tune this PostgreSQL index for a slow query outside of any ORM"
+  ]
+}

package/skills/docker-patterns/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: docker-patterns
+description: Writes and fixes Dockerfiles and Docker Compose files that build small, cacheable, non-root images, using multi-stage builds, a tight .dockerignore, BuildKit cache and secret mounts, healthchecks, and a Compose setup for local development with dependent services. Use when containerising an app, shrinking a bloated or slow image build, removing secrets baked into image layers, or wiring a local stack of app, database and queue with Compose.
+license: MIT
+compatibility: Any Agent Skills host. Building and running images needs Docker with BuildKit (default in current Docker Engine and Docker Desktop) and the docker compose plugin.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: devops
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "docker"
+  kete-loom/owner: "Kete-org"
+---
+
+# Docker patterns
+
+Produce images that are small, rebuild fast, run as a non-root user and carry no secrets. Production deployment on Kubernetes belongs to `kubernetes-patterns`; this skill stops at the image and local Compose.
+
+## 0. Read before you write
+
+1. Find the runtime and its lockfile (`package-lock.json`, `pnpm-lock.yaml`, `poetry.lock`, `uv.lock`, `go.sum`, `Cargo.lock`, `pom.xml`, `*.csproj`). The lockfile drives the dependency layer.
+2. Find the build command, the start command, the port and any files the app reads at runtime (templates, migrations, static assets).
+3. Check for an existing `Dockerfile`, `compose.yaml` / `docker-compose.yml`, `.dockerignore` and CI build steps. Edit what exists; keep the image name and tags CI uses.
+4. Stop and ask the user if the target platform is unclear (for example `linux/amd64` servers built on an `arm64` laptop) or if the app needs native libraries you cannot identify.
+
+## 1. Dockerfile rules
+
+1. **Pin the base image** to a specific version tag (`node:22-bookworm-slim`, `python:3.12-slim`), never `latest`. Pin by digest (`@sha256:...`) when the project asks for reproducible builds.
+2. **Multi-stage**: a `build` stage with compilers and dev dependencies, and a final stage that copies only the built output and runtime dependencies. For static binaries (Go, Rust) the final stage can be `gcr.io/distroless/static` or `scratch`.
+3. **Order for caching**: copy the manifest and lockfile, install dependencies, then copy the source. Source changes must not invalidate the dependency layer.
+4. **Install reproducibly** from the lockfile: `npm ci`, `pnpm install --frozen-lockfile`, `pip install --no-cache-dir -r requirements.txt`, `uv sync --frozen`, `go mod download`.
+5. **Clean in the same layer**: `apt-get update && apt-get install -y --no-install-recommends ... && rm -rf /var/lib/apt/lists/*`. A later `RUN rm` does not shrink the image.
+6. **Non-root**: create or use an unprivileged user and set `USER` before `CMD`. Many official images ship one (`node` in Node images, `nonroot` in distroless). Copy app files with `COPY --chown=` so the user can read them, and don't make the app directory writable unless it must be.
+7. **Exec form for the entrypoint**: `CMD ["node", "server.js"]`, not `CMD node server.js`, so the process is PID 1 and receives `SIGTERM`. If the app spawns children or ignores signals, add `--init` at run time or a small init such as `tini`.
+8. **`EXPOSE` the port** the app listens on, and make the app bind `0.0.0.0`, not `127.0.0.1`.
+9. **`HEALTHCHECK`** only with a tool that exists in the final image (`curl`, `wget` or the app's own `healthcheck` subcommand). Distroless images have no shell or curl; skip `HEALTHCHECK` there and rely on the orchestrator's probes.
+10. **`ARG` vs `ENV`**: `ARG` for build-time values, `ENV` for runtime defaults. Neither is a safe place for secrets: both can be read back from image metadata or history.
+
+A template per runtime is in `references/dockerfiles.md`.
+
+## 2. Secrets
+
+- Never `COPY` a `.env`, key file or credentials file into any stage, and never pass a token with `--build-arg`.
+- Build-time secrets (private registry token, package-index credential): `RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci` with `docker build --secret id=npmrc,src=$HOME/.npmrc .`. The secret is not written to a layer.
+- Private Git dependencies: `RUN --mount=type=ssh` with `docker build --ssh default .`.
+- Runtime secrets come from the environment or a mounted file at `docker run` / Compose / orchestrator level, never from the image.
+- If a secret was already baked into a pushed image, removing it from the Dockerfile is not enough: tell the user to rotate it.
+
+## 3. .dockerignore
+
+Always present. Start from:
+
+```
+.git
+**/node_modules
+**/__pycache__
+**/.venv
+dist
+build
+target
+coverage
+.env
+.env.*
+*.pem
+*.key
+Dockerfile*
+compose*.yaml
+docker-compose*.yml
+```
+
+Adjust so the build output you need is not excluded (for example, keep `dist` if you build outside Docker and copy it in).
+
+## 4. Faster builds
+
+- Cache package downloads across builds: `RUN --mount=type=cache,target=/root/.npm npm ci`, `--mount=type=cache,target=/root/.cache/pip`, `--mount=type=cache,target=/go/pkg/mod`.
+- Keep the build context small (`.dockerignore`) and put rarely changing steps first.
+- In CI, use the builder's registry or CI cache backend (`--cache-from` / `--cache-to`), not a fresh build each time.
+
+## 5. Compose for local development
+
+Use `compose.yaml` (the current default file name) and no top-level `version:` key; it is obsolete.
+
+```yaml
+services:
+  app:
+    build: .
+    ports: ["3000:3000"]
+    env_file: .env            # local only, git-ignored
+    depends_on:
+      db:
+        condition: service_healthy
+  db:
+    image: postgres:16
+    environment:
+      POSTGRES_PASSWORD: dev-only
+    volumes: [db-data:/var/lib/postgresql/data]
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres"]
+      interval: 5s
+      retries: 10
+volumes:
+  db-data:
+```
+
+- `depends_on` with `condition: service_healthy` waits for the healthcheck, not just for the container to start.
+- Services reach each other by service name (`db:5432`), not `localhost`.
+- Bind-mount source for hot reload, or use `develop.watch` with `docker compose watch`. Don't bind-mount over a directory the image built (such as `node_modules`) without an anonymous volume to protect it.
+- Bind database ports to localhost only when exposed: `"127.0.0.1:5432:5432"`.
+- Use profiles (`profiles: [tools]`) for optional services instead of extra Compose files.
+
+## 6. Verify
+
+Run, and report the results:
+
+1. `docker build -t <name>:dev .` succeeds.
+2. `docker image ls <name>:dev` for the size; compare with the old image if there was one.
+3. `docker run --rm <name>:dev id` (or check `docker inspect --format '{{.Config.User}}'`) shows a non-root user.
+4. `docker history --no-trunc <name>:dev` shows no secrets in any layer command.
+5. `docker run --rm -p <port>:<port> <name>:dev` and hit the health endpoint; then `docker stop` returns quickly (signals handled).
+6. For Compose: `docker compose config` validates, `docker compose up -d` and `docker compose ps` shows services healthy.
+
+If an image scanner is available (`docker scout cves`, `trivy image`), run it and list high and critical findings.
+
+## Never
+
+- Never use `latest` or an unpinned base in a production Dockerfile.
+- Never run the final stage as root without the user's explicit reason.
+- Never add `--privileged`, the Docker socket mount (`/var/run/docker.sock`) or `network_mode: host` unless the user asks for it and understands the risk.
+- Never `chmod -R 777`.
+
+## Report back
+
+End with: files changed, base image and final size (before and after if known), user the container runs as, the verification commands you ran with pass or fail, and anything you could not check.