@ketecode/loom 0.0.0-stage → 0.2.0

package/skills/design-brainstorming/evals/behavior.json

@@ -0,0 +1,55 @@
+{
+  "scenarios": [
+    {
+      "name": "jump straight to code",
+      "prompt": "I want users to be able to export their data. Let's go, just start coding it, I'll figure out details as we go.",
+      "pressure": [
+        "time"
+      ],
+      "expect": [
+        "Does not write implementation code in the reply",
+        "Asks exactly one question in the message, ideally multiple choice (for example format or scope)",
+        "Mentions the user can say 'skip the questions and just start'",
+        "If skipping, states the one or two big choices being made instead of silently deciding"
+      ],
+      "forbid": [
+        "Writes or scaffolds export code",
+        "Asks a list of several questions in one message"
+      ]
+    },
+    {
+      "name": "offer approaches with trade-offs",
+      "prompt": "We've agreed: admins need an audit log of who changed billing settings, kept 1 year, viewable in the admin panel. What are our options?",
+      "files": {
+        "src/models/billing.js": "const db = require('../db');\nasync function updateSettings(orgId, patch, userId) {\n  return db('billing_settings').where({ org_id: orgId }).update(patch);\n}\nmodule.exports = { updateSettings };\n"
+      },
+      "expect": [
+        "Presents two or three genuinely different approaches, each with what is good and what it costs",
+        "Gives one recommendation with a reason tied to the stated constraints",
+        "Grounds the approaches in the existing code (for example updateSettings in src/models/billing.js)",
+        "Waits for the user to pick before detailing the design"
+      ],
+      "forbid": [
+        "Presents a single approach as the only option",
+        "Starts writing a migration or code"
+      ]
+    },
+    {
+      "name": "too big, split it",
+      "prompt": "Design me a marketplace with seller onboarding, buyer chat, Stripe payments and a review system. My manager wants the full design doc today.",
+      "pressure": [
+        "authority",
+        "time"
+      ],
+      "expect": [
+        "Proposes splitting it into separate designs per subsystem",
+        "Asks which subsystem to design first",
+        "Flags payments as needing a matching security or payments review"
+      ],
+      "forbid": [
+        "Produces one combined design doc covering every subsystem at once",
+        "Writes implementation code"
+      ]
+    }
+  ]
+}

package/skills/design-brainstorming/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "I want to add some kind of team sharing to our notes app but I haven't worked out how it should behave. Can we think it through together first?",
+    "Let's brainstorm the design for a recurring-invoices feature before anyone writes code",
+    "I have a rough idea for an offline mode in our field-inspection app, help me shape it into a design we agree on",
+    "Before we build the new notification preferences, ask me what you need to know and propose a couple of approaches",
+    "Help me figure out what our internal deploy dashboard should actually do, then write the design down in the repo"
+  ],
+  "should_not_trigger": [
+    "Write a PRD for the recurring invoices feature with goals, metrics and rollout for the leadership review",
+    "Here's the approved design doc for offline mode, break it into bite-sized implementation tasks",
+    "Should our notifications live in a separate service or stay in the monolith? Weigh the options",
+    "Record our decision to use Postgres row-level security as an architecture decision record",
+    "Implement the team sharing endpoints from the plan in docs/plans, test first"
+  ]
+}

package/skills/design-brainstorming/references/visual-mockups.md

@@ -0,0 +1,34 @@
+# Visual mockups during design
+
+Use these when the user has to choose between layouts, flows or visual treatments, and words would leave them guessing. A mockup is there to help them decide, not to be the product: throw it away once the design doc records the choice.
+
+## When to offer one
+
+- The question is about a screen, a flow across screens, a chart or dashboard, or the density and hierarchy of a page.
+- Two approaches differ mainly in how they look or feel.
+- The user says "show me", or keeps asking what something would look like.
+
+Don't offer one for back-end, data or API decisions; a short table or sequence of steps is clearer there. Ask before making mockups: "Want me to sketch A and B as HTML pages you can open side by side?"
+
+## How to make them
+
+1. Put them outside the source tree, in a folder that's git-ignored, such as `.design/mockups/<topic>/`. Check with `git check-ignore -q .design/` first. If it isn't ignored, ask before adding it to `.gitignore`, or use the system temp folder.
+2. Write **one self-contained HTML file per option**: inline CSS, no build step, no framework, no external scripts, fonts or images. Name the files `a-<short-name>.html`, `b-<short-name>.html`.
+3. Use realistic but obviously fake content: plausible names and numbers that are not real people or data. Show the awkward cases too: a long name, an empty list, an error state.
+4. Match only what the decision needs. Use grey boxes for anything that isn't being decided, and the project's real colours and type only if the choice depends on them.
+5. Add a short header on each page: the option letter, a one-line summary, and what to look at ("compare how the filters sit relative to the table").
+6. When there are more than two options, or one flow across several screens, add an `index.html` that links them, or shows them side by side in iframes.
+7. Tell the user the paths and how to open them (`open` on macOS, `xdg-open` on Linux, `start` on Windows, or "open this file in your browser"). Opening a browser yourself is fine when the user asked for it.
+
+## Taking feedback
+
+- Ask one question per round: "Which layout, A or B?" then "What would you change about B?"
+- Edit the mockup the user picked, and keep the earlier versions (`b-v2.html`) so you can go back.
+- Once a section of the design is agreed, record the decision in words, with a screenshot if the user wants one. Never put the mockup HTML into the design doc or the source tree.
+- When the design doc is written, offer to delete the mockup folder.
+
+## Never
+
+- Wire mockups to real APIs, real customer data or production credentials.
+- Turn a mockup into production code by copying it into the app. Build the real thing from the design doc, test-first.
+- Run a local server for mockups unless the user asks. Static files are enough, and leave nothing running.

package/skills/desktop-app-testing/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: desktop-app-testing
+description: Automates end-to-end UI tests for native desktop applications (WPF, WinForms, Win32, Qt and Electron) by driving them through UI Automation with pywinauto, through the Appium Windows driver backed by WinAppDriver, or through Playwright's Electron support, with stable automation IDs instead of screen coordinates, isolated app data per test, screenshots on failure, and CI runners that have a real interactive desktop session or a virtual display. Use when writing UI tests for a Windows or cross-platform desktop app, a desktop test passes locally but cannot find windows in CI, choosing between pywinauto, Appium and Playwright for a desktop app, or replacing coordinate-click scripts that break on every resolution change.
+license: MIT
+compatibility: Any Agent Skills host. Windows targets need a Windows machine or runner with an unlocked interactive session; Electron tests run on Windows, macOS or Linux (Linux needs a display, for example Xvfb).
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: testing
+  kete-loom/risk: runs-commands
+  kete-loom/owner: "Kete-org"
+---
+
+# Desktop app testing
+
+Write desktop UI tests that find controls by identity, start from a known state, and give a screenshot and log when they fail, in CI as well as on a developer machine.
+
+Browser apps belong to `e2e-testing-playwright`. Unit and component tests belong to the language's testing skill (`csharp-testing`, `python-testing`, `cpp-testing`). This skill is for driving the packaged, running desktop app.
+
+## 0. Before you start
+
+1. Identify the UI framework and target OS: WPF, WinForms, Win32/MFC, WinUI/UWP, Qt (Widgets or QML), Electron, or other.
+2. Find how the app is built and launched (path to the built `.exe`, command-line flags, config or data directories).
+3. Check for existing UI tests and their tool. Extend that tool unless it is unworkable; tell the user before switching.
+4. Inspect the UI tree with Accessibility Insights for Windows or `Inspect.exe` (Windows SDK) to see which controls expose `AutomationId`, `Name` and `ControlType`. For Electron, use DevTools.
+
+## 1. Pick the driver
+
+| App | Tool | Why |
+|---|---|---|
+| Electron | Playwright `_electron.launch` | Same API as web tests, access to the main process |
+| WPF, WinForms, WinUI, Win32, Qt on Windows, test code in Python | pywinauto with `backend="uia"` | No server process, direct UI Automation |
+| Same apps, team wants WebDriver or non-Python language | Appium with the Windows driver (`appium driver install windows`) | WebDriver protocol, any client language; needs WinAppDriver and Windows Developer Mode |
+| Old Win32/MFC controls with poor UIA support | pywinauto `backend="win32"` | Reads native Win32 controls |
+| Qt on Linux or macOS | the platform accessibility layer, or Squish (commercial) if the team owns it; **stop and ask** | Few free options; confirm the choice |
+| macOS native (AppKit/SwiftUI) | XCUITest, or Appium Mac2 driver | Out of scope here beyond this pointer |
+
+WinAppDriver has seen no active development for years; it still works for many apps but check its status and the Appium Windows driver's current requirements before committing a new suite to it. Prefer pywinauto for new Python suites.
+
+## 2. Make the app testable
+
+1. Give every control a test needs a stable automation identifier:
+   - WPF: `AutomationProperties.AutomationId="SaveButton"` (or `x:Name`, which UIA exposes).
+   - WinForms: the control's `Name` property becomes the `AutomationId`.
+   - Qt: `setObjectName("saveButton")` and accessible names; check what UIA shows.
+   - Electron: `data-testid` or accessible roles and names in the renderer.
+2. Add a launch flag or environment variable for tests: a separate data directory, disabled auto-update, telemetry off, animations off, a fixed locale. Never point tests at the user's real profile.
+3. Where a test needs data, seed it through files or an API before launch, not by clicking through setup screens.
+
+Changing app code to add IDs is in scope; ask before changing behaviour.
+
+## 3. Write the tests
+
+### Locators
+
+- Order of preference: automation ID, then control type plus accessible name, then a path inside a uniquely identified parent. Never screen coordinates, image matching or tab-order key presses as the main strategy.
+- Scope searches to the app's top window, not the desktop root; desktop-wide searches are slow and pick up other apps.
+
+### Waiting
+
+- Wait for a condition (window exists, control enabled, text equals) with a timeout. pywinauto: `.wait("visible enabled", timeout=10)`; Appium: explicit WebDriver waits; Playwright: web-first `expect` assertions.
+- Never use fixed sleeps except as a last resort with a comment explaining what is missing.
+
+### Structure
+
+- One fresh app instance per test or per test class, launched with a clean temp data directory; close it in teardown even when the test fails, and kill leftover processes by PID.
+- Page-object style: one class per window or dialog wrapping its locators and actions.
+- Assert on visible outcomes (a list row appears, a file is written, a status label changes), not on internal state.
+- On failure, save a screenshot of the app window and the app's log file as test artifacts.
+
+Code templates for each tool are in `references/drivers.md`.
+
+## 4. CI
+
+1. Windows UI automation needs an **interactive, unlocked desktop session**. A runner installed as a Windows service, a locked screen or a disconnected RDP session makes window searches fail or hang.
+   - GitHub-hosted Windows runners: try them first; check that windows are found and screenshots are not black.
+   - Self-hosted: run the runner as a normal user with auto-logon and the screensaver and lock disabled, not as a service. Keep the screen resolution fixed.
+2. Linux (Electron, Qt): run under a virtual display, `xvfb-run -a <test command>`.
+3. Install the app from the same build artifact the release uses, not a debug build, at least for the smoke subset.
+4. Run UI tests serially on one desktop; parallel instances fight over focus. Shard across machines instead.
+5. Upload screenshots, app logs and test reports on failure.
+
+## 5. Flakiness
+
+When a test is flaky, find the cause before adding retries: a missing wait, focus stolen by another window (update prompts, notifications), shared state between tests, or animations. One CI retry is acceptable while the cause is investigated; report each flaky test to the user.
+
+## Never
+
+- Never automate the user's real profile, real accounts or production back ends.
+- Never rely on screen coordinates, pixel matching or fixed sleeps as the main technique.
+- Never disable OS security features (UAC, Defender) on shared machines to make tests pass; use a dedicated test VM.
+- Never leave app processes running after the suite.
+
+## Report back
+
+```
+## Desktop UI tests: <app>
+Framework / OS: <WPF on Windows 11, ...>
+Tool: <pywinauto uia | Appium Windows | Playwright Electron> and why
+Tests added: <names, what each covers>
+App changes: <automation IDs or test flags added>
+CI: <runner type, session setup, artifacts>
+Result: <command, pass/fail counts, runs repeated for flakiness>
+Gaps: <controls without IDs, untestable areas>
+```

package/skills/desktop-app-testing/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write UI tests for our WPF invoicing app that click through creating a customer",
+    "Our pywinauto tests pass locally but can't find the main window on the CI Windows runner",
+    "Should we use pywinauto or Appium with WinAppDriver to test our WinForms client?",
+    "Add end-to-end tests for our Electron app that launch it and check the main window",
+    "Replace our AutoIt scripts that click screen coordinates with something that survives a resolution change"
+  ],
+  "should_not_trigger": [
+    "Write Playwright tests for the login page of our React web app",
+    "Add xUnit unit tests for the tax calculation class in our C# library",
+    "Package our Python Qt app into a signed Windows installer",
+    "Check our web app's forms for screen reader and keyboard accessibility",
+    "Test our iOS app's onboarding flow with XCUITest on a simulator"
+  ]
+}

package/skills/desktop-app-testing/references/drivers.md

@@ -0,0 +1,81 @@
+# Desktop driver templates
+
+Read this when writing the first test with a tool. Check the tool's current documentation for version-specific capability names.
+
+## pywinauto (Python, UI Automation backend)
+
+```python
+import subprocess, tempfile, pytest
+from pywinauto import Application
+
+APP = r"C:\build\MyApp\MyApp.exe"
+
+@pytest.fixture
+def app():
+    data_dir = tempfile.mkdtemp()
+    application = Application(backend="uia").start(f'"{APP}" --data-dir "{data_dir}" --no-update')
+    main = application.window(title_re="MyApp.*")
+    main.wait("visible ready", timeout=20)
+    yield application, main
+    application.kill()
+
+def test_save_creates_record(app, request):
+    _, main = app
+    try:
+        main.child_window(auto_id="NameBox", control_type="Edit").set_edit_text("Ama")
+        main.child_window(auto_id="SaveButton", control_type="Button").click_input()
+        row = main.child_window(title="Ama", control_type="DataItem")
+        row.wait("visible", timeout=10)
+    except Exception:
+        main.capture_as_image().save(f"{request.node.name}.png")
+        raise
+```
+
+Use `print_control_identifiers()` on a window once to explore its tree; do not leave it in tests. `click_input()` moves the real mouse (needs focus); `invoke()` uses the UIA Invoke pattern and is often steadier.
+
+## Appium Windows driver (WebDriver)
+
+Install: `npm install -g appium`, `appium driver install windows`, install WinAppDriver, enable Windows Developer Mode, start `appium`.
+
+```python
+from appium import webdriver
+from appium.options.windows import WindowsOptions
+from appium.webdriver.common.appiumby import AppiumBy
+
+opts = WindowsOptions()
+opts.app = r"C:\build\MyApp\MyApp.exe"
+opts.set_capability("appium:appArguments", "--data-dir C:\\temp\\t1")
+driver = webdriver.Remote("http://127.0.0.1:4723", options=opts)
+try:
+    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "NameBox").send_keys("Ama")
+    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "SaveButton").click()
+finally:
+    driver.quit()
+```
+
+`ACCESSIBILITY_ID` maps to UIA `AutomationId`. Use `"appium:app": "Root"` to attach to the desktop for apps you start yourself, then find the window by name.
+
+## Playwright for Electron (TypeScript)
+
+```ts
+import { test, expect, _electron as electron } from '@playwright/test';
+import os from 'node:os'; import path from 'node:path'; import fs from 'node:fs';
+
+test('save creates a record', async () => {
+  const userData = fs.mkdtempSync(path.join(os.tmpdir(), 'app-'));
+  // Pass the temp dir however the app accepts it (a flag or env var that calls app.setPath('userData', ...)).
+  const app = await electron.launch({ args: ['.'], env: { ...process.env, MYAPP_USER_DATA: userData } });
+  try {
+    const win = await app.firstWindow();
+    await win.getByLabel('Name').fill('Ama');
+    await win.getByRole('button', { name: 'Save' }).click();
+    await expect(win.getByRole('row', { name: /Ama/ })).toBeVisible();
+    const version = await app.evaluate(({ app }) => app.getVersion());
+    expect(version).toMatch(/\d+\.\d+\.\d+/);
+  } finally {
+    await app.close();
+  }
+});
+```
+
+For a packaged build pass `executablePath` to the built binary. The config's `use.trace` option does not cover a context you launch yourself; record a trace with `await app.context().tracing.start({ screenshots: true, snapshots: true })` after launch and `tracing.stop({ path })` in the `finally` block when the test failed.

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.

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

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write a Dockerfile for our Express API that doesn't run as root",
+    "Our Docker image is 1.8GB, can you get it down with a multi-stage build?",
+    "Every docker build reinstalls all the npm packages even when I only change one source file",
+    "Set up a compose.yaml so I can run the app with Postgres and Redis locally",
+    "We pass the NPM_TOKEN as a build arg, how do we stop it ending up in the image?"
+  ],
+  "should_not_trigger": [
+    "Add liveness and readiness probes to our Kubernetes Deployment",
+    "Write a Terraform module for an ECR repository and an ECS service",
+    "Review this Dockerfile and the Helm chart for security problems before we ship",
+    "Create a GitHub Actions workflow that runs the tests on every pull request",
+    "Roll back the payments deployment in the cluster to the previous ReplicaSet"
+  ]
+}