skilldrop-cli 0.16.2 → 0.16.4

package/README.md

@@ -1,14 +1,17 @@
 # skilldrop
 
 [![npm](https://img.shields.io/npm/v/skilldrop-cli)](https://www.npmjs.com/package/skilldrop-cli)
+[![PyPI](https://img.shields.io/pypi/v/skilldrop-cli)](https://pypi.org/project/skilldrop-cli/)
 [![license](https://img.shields.io/badge/license-MIT%20OR%20Apache--2.0-blue.svg)](LICENSE)
 
-**Portable AI-agent skills for the deliverables knowledge workers actually ship:** ADRs, design docs, PRDs, runbooks, threat models, decks, postmortems and adversarial reviews. Each one is a folder you copy into Claude Code, Cursor, Kiro, Codex, Antigravity or Copilot.
+**Portable AI-agent skills, measured against the agent without them.** They cover the deliverables knowledge workers actually ship: ADRs, design docs, PRDs, runbooks, threat models, decks, postmortems and adversarial reviews. Each one is a folder you copy into Claude Code, Cursor, Kiro, Codex, Antigravity or Copilot.
 
 ```text
 messy input → a skill with a quality bar → a gate that can say no → your decision
 ```
 
+Every skill is run as a real agent session twice, once with the skill and once without, and the results are published either way. [See the numbers and how they were measured](https://sananthanarayan.github.io/skilldrop/evals/).
+
 [Browse the packs](https://sananthanarayan.github.io/skilldrop/packs/) · [Search all skills](https://sananthanarayan.github.io/skilldrop/catalogue/) · [Docs](https://sananthanarayan.github.io/skilldrop/docs/) · [Install options](guides/how-to/install.md) · [Contribute](CONTRIBUTING.md)
 
 ## Choose your role
@@ -39,6 +42,13 @@ Install one pack. Every role pack also brings `core` (intake, critique, review c
 npx skilldrop-cli install --pack dev-team
 ```
 
+Prefer Python tooling? The same CLI is on PyPI. It still runs on Node, so Node 16.7 or newer has to be on your `PATH`:
+
+```bash
+pipx install skilldrop-cli        # or: pip install skilldrop-cli
+skilldrop install --pack dev-team
+```
+
 The install prints a starter prompt for the pack. For `dev-team`, ask your agent:
 
 ```text
@@ -53,6 +63,7 @@ In Claude Code you can use the plugin marketplace instead: run `/plugin marketpl
 
 - **A skill produces one file you own.** Each ships a quality bar, named anti-patterns and acceptance evals, so the output is an artifact, not a conversation. See [every skill, by category](guides/reference/skill-catalogue.md).
 - **Loops order skills, and a gate decides when work moves on.** Five loops cover the lifecycle (`discover`, `design`, `build`, `release`, `operate`), plus the `ship-a-draft` wrapper for any document. Each gate is a script, a review panel or a person, chosen by how expensive the mistake is to undo. See [the loops, stage by stage](guides/reference/loops.md) and [why loops](guides/explanation/loops.md).
+- **Measured, not asserted.** `run_bench.py` runs each acceptance eval with the skill and without it, in a sandbox, and reports the lift, a blind preference from two judges, and the cost per run. The results are published whether or not they flatter the skills. See [how skills are checked](https://sananthanarayan.github.io/skilldrop/evals/) and [RFC-0040](docs/rfcs/0040-skill-benchmark.md).
 - **Copy, never transform.** A skill is a plain `SKILL.md` folder in the [Agent Skills](https://agentskills.io) format, at `packs/<pack>/skills/<name>/`. What runs in your agent is byte-identical to what is reviewed here. There is no runtime, and the tooling has zero dependencies.
 - **Updates keep your edits.** `npx skilldrop-cli update` replaces files you haven't touched. For any file you changed, it leaves the new version beside it as `<file>.upstream`. See [upgrade installed skills](guides/how-to/upgrade-skills.md).
 

package/catalogue.json

@@ -55,6 +55,8 @@
         "sonar-review",
         "test-plan-generator",
         "bug-triage",
+        "pr-description-writer",
+        "tech-debt-register",
         "agents-md-generator",
         "llm-eval-harness",
         "eval-harness-generator",
@@ -172,7 +174,8 @@
       "skills": [
         "dpia",
         "risk-register",
-        "soc2-evidence-map"
+        "soc2-evidence-map",
+        "security-questionnaire-response"
       ]
     },
     "build-agent-skills": {

package/model-routing.json

@@ -170,6 +170,18 @@
       "tier": "standard",
       "rationale": "Structured planning against a fixed shape (decision, sub-questions, methods, criteria, stopping rule); needs judgment to cut scope but no adversarial reasoning."
     },
+    "pr-description-writer": {
+      "tier": "standard",
+      "rationale": "Reads a diff and rewrites it for a reviewer. Bounded by the diff; the judgment is in picking what a reviewer needs first."
+    },
+    "tech-debt-register": {
+      "tier": "standard",
+      "rationale": "Structures and ranks items against stated evidence. Judgment is bounded: a cost with no evidence is recorded as unknown, not estimated."
+    },
+    "security-questionnaire-response": {
+      "tier": "standard",
+      "rationale": "Matches questions to evidence and writes short answers. The hard rule is mechanical: no evidence, no answer."
+    },
     "risk-register": {
       "tier": "standard",
       "rationale": "Structured writing against a fixed format and scale, with a script doing the checks and counts. Scoring needs some judgment but is bounded by the written scale."

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.16.2",
-  "description": "Portable AI-agent skills for the deliverables knowledge workers ship \u2014 diagrams, ADRs, PRDs, runbooks, decks, reviews \u2014 installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
+  "version": "0.16.4",
+  "description": "Portable AI-agent skills, measured against the agent without them. ADRs, PRDs, runbooks, decks and reviews, installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",
     "url": "https://github.com/sananthanarayan"

package/packs/dev-team/skills/pr-description-writer/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: pr-description-writer
+description: Write the pull request title and description for one change, from the actual diff and commits: what changed and why, how it was tested with only the checks that were really run, what a reviewer should look at first, and the risk and rollback. It also reports what the diff contains that the commits don't mention, such as a dependency bump, a deleted test or a schema change. Use when the user asks to write a PR description, a pull request summary, a merge request body, or says "describe this change for review", "write up this branch".
+---
+
+# pr-description-writer
+
+You write the description a reviewer reads before the diff: a title, why the change exists,
+what it does, how it was checked, where to look first, and what could go wrong. Everything in
+it comes from the diff, the commits and what the user told you. One change, one description.
+
+## How to respond
+
+1. **Read the change itself.** In a git repository, find the base branch (the one the user
+   names, else `main` or `master`) and read `git diff <base>...HEAD` and
+   `git log <base>..HEAD`. If the user hands you a diff or patch file, read that. Read the
+   whole diff, not the commit subjects: the subjects are the author's summary and the diff is
+   the fact.
+
+2. **Work out the one reason for the change.** A linked issue, the user's words, or the
+   commit bodies. If none of them says why, write what the change does and put
+   `Why: not stated — add the reason or the issue link` at the top of the body. Don't
+   make up a motive, an issue number or a customer.
+
+3. **Write the title.** Imperative mood, 72 characters or fewer, naming the behaviour that
+   changes. ✅ "Retry webhook delivery on 5xx with backoff". ❌ "Fix bug". ❌ "Updates to
+   webhook.py". Keep a `feat:` / `fix:` prefix only if the repository's history uses one.
+
+4. **Write the body in this order**, leaving out a section that has nothing true to say:
+   - **Why**: one or two sentences. The problem, not the solution.
+   - **What changed**: three to six bullets on behaviour, grouped by what a user or caller
+     would notice. No file-by-file tour.
+   - **How it was tested**: only checks that were run, with the command or the evidence
+     ("`pytest tests/webhooks -q`: 14 passed", "new test `test_retry_on_503`"). If you ran
+     nothing and were told nothing, write `Not run` and list the checks worth running.
+   - **Where to look first**: the one or two places a reviewer should spend their time, and
+     why. Name files and functions.
+   - **Risk and rollback**: what breaks if this is wrong, who notices, and how to undo it
+     (revert, feature flag, migration down). Say plainly when a rollback is not clean.
+   - **Not in this PR**: follow-ups the diff deliberately leaves out, if the commits or the
+     user mention any.
+
+5. **Report what the diff has that the commits don't mention.** Check for: a dependency or
+   lockfile change, a deleted or skipped test, a schema or data migration, a changed public
+   API or config default, a new secret or environment variable, files unrelated to the
+   stated purpose, and leftover debug output. Put each one under **Reviewer notes** in the
+   body, and repeat the list in your reply. A breaking change goes in the title or the first
+   line of the body.
+
+6. **Say when it should be more than one PR.** Two unrelated purposes in one diff, or a
+   refactor mixed with a behaviour change, gets one line: what to split and where. Still
+   write the description for the change as it stands.
+
+7. **Hand it over.** Print the title and the body as Markdown, ready to paste. Don't open,
+   edit or push the pull request unless the user asked for that.
+
+**With no change to read** (no repository, no diff, no description of the change), say so in
+one line and ask for the diff or the branch. With a described change and no diff, write the
+description from the description, and state at the top that it was written without the diff.
+
+## Quality bar
+
+- **Everything traces to the diff, the commits or the user.** No invented issue numbers,
+  metrics, reviewers or test results.
+- **The test section is honest.** A check that wasn't run is listed as not run.
+- **A reviewer learns where to look.** The body names the riskiest part of the diff.
+- **Surprises are surfaced.** A dependency bump, deleted test, migration or API change that
+  the commits skip appears under Reviewer notes.
+- **Claims about the code are checked.** Before saying a test does or doesn't cover a
+  change, or that two changes are independent, work it through against the diff (run the
+  arithmetic, trace the call). If you can't confirm it, leave the claim out.
+- **Short.** The body fits on one screen. A long PR gets a tighter summary, not a longer one.
+
+## When to use this skill
+
+- ✅ A branch is ready and needs a pull or merge request description
+- ✅ A diff or patch file needs writing up for review
+- ✅ An existing thin description ("fixes stuff") needs replacing before review
+
+## When NOT to use this skill
+
+- ❌ Notes for a whole release or a changelog entry across many changes. Use `release-notes`.
+- ❌ Deciding whether the change is safe to merge. Use `pre-merge-review`.
+- ❌ Designing the tests the change needs. Use `test-plan-generator`.
+
+## Anti-patterns to avoid
+
+- ❌ **Restating commit subjects as bullets.** The reviewer can read `git log`.
+- ❌ **"Tested locally."** Name the command and the result, or write "Not run".
+- ❌ **A file-by-file tour.** Group by behaviour; the diff already lists the files.
+- ❌ **Inventing the why.** A missing reason is stated as missing.
+- ❌ **Hiding a breaking change in the middle.** It leads.
+- ❌ **Speculative reviewer notes.** A note that turns out wrong costs the reviewer more
+  than no note. Report what the diff shows, not what it might imply.
+- ❌ **Showing the machinery.** The description is for the reviewer: no mention of this
+  skill, its files, or how the description was produced.

package/packs/dev-team/skills/pr-description-writer/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Write the PR description for this branch",
+    "should_trigger": true
+  },
+  {
+    "query": "I need a pull request summary for these commits before I ask for review",
+    "should_trigger": true
+  },
+  {
+    "query": "Here's my diff, write the merge request body",
+    "should_trigger": true
+  },
+  {
+    "query": "My PR description just says 'fixes stuff'. Rewrite it properly from the diff.",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the release notes for everything merged since v2.3.0",
+    "should_trigger": false
+  },
+  {
+    "query": "Is this branch safe to merge? Run the full review.",
+    "should_trigger": false
+  },
+  {
+    "query": "What tests should we write for the new refund flow?",
+    "should_trigger": false
+  }
+]

package/packs/dev-team/skills/pr-description-writer/evals/evals.json

@@ -0,0 +1,43 @@
+{
+  "skill_name": "pr-description-writer",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the PR description for this change. The diff is in change.diff and the commit log is in commits.txt. It's for issue #482 (webhook deliveries silently dropped when the receiver returns 503).",
+      "assertions": [
+        "The title is imperative, 72 characters or fewer, and names the retry behaviour rather than a file",
+        "The body explains why (deliveries dropped on a 5xx) before what changed",
+        "It reports that the diff bumps the requests dependency, which no commit mentions",
+        "It reports that the diff deletes or skips an existing test (test_delivery_timeout), which no commit mentions",
+        "The test section names only tests visible in the diff or says checks were not run; it does not claim a passing test run",
+        "It names where a reviewer should look first (the retry loop or backoff in deliver())",
+        "It does not invent an issue number other than #482, a metric, or a reviewer"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Describe this change for review: fix.diff. I ran `pytest tests/billing -q` and got 31 passed.",
+      "assertions": [
+        "The title names the rounding fix for invoice totals, in the imperative, 72 characters or fewer",
+        "The test section reports `pytest tests/billing -q`: 31 passed as the user stated, and mentions the new test in the diff",
+        "The body says no reason or issue was given for the change, or states the reason only as far as the diff shows it",
+        "It notes the changed default (ROUNDING moved from ROUND_HALF_EVEN to ROUND_HALF_UP) as something existing invoices or callers may notice",
+        "The body fits on one screen: no file-by-file walk-through",
+        "It does not invent an issue link, a customer report, or affected-invoice counts"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Write up this branch for the PR. Diff is big.diff. Tests pass.",
+      "assertions": [
+        "The breaking change (the `limit` query parameter renamed to `page_size` on GET /orders) is in the title or the first lines of the body",
+        "It reports the database migration (new orders.archived_at column and index) and says how to roll it back or that the rollback drops the column",
+        "It says the diff mixes an unrelated logging refactor with the API change and suggests splitting it",
+        "It reports the new environment variable ORDERS_ARCHIVE_DAYS",
+        "The test section does not list specific passing tests or commands that the user did not give; it records only that the user says tests pass, or asks which were run",
+        "It names where a reviewer should look first",
+        "It does not invent an issue number, a deploy date, or performance figures"
+      ]
+    }
+  ]
+}

package/packs/dev-team/skills/pr-description-writer/evals/files/1/change.diff

@@ -0,0 +1,61 @@
+diff --git a/requirements.txt b/requirements.txt
+--- a/requirements.txt
++++ b/requirements.txt
+@@ -1,3 +1,3 @@
+ flask==3.0.3
+-requests==2.31.0
++requests==2.32.3
+ redis==5.0.4
+diff --git a/webhooks/deliver.py b/webhooks/deliver.py
+--- a/webhooks/deliver.py
++++ b/webhooks/deliver.py
+@@ -1,14 +1,27 @@
+ import logging
++import time
+
+ import requests
+
+ log = logging.getLogger(__name__)
++MAX_ATTEMPTS = 4
++BACKOFF_SECONDS = (1, 4, 16)
+
+
+ def deliver(url, payload):
+-    resp = requests.post(url, json=payload, timeout=5)
+-    if resp.status_code >= 400:
+-        log.warning("delivery failed: %s", resp.status_code)
+-        return False
+-    return True
++    for attempt in range(1, MAX_ATTEMPTS + 1):
++        resp = requests.post(url, json=payload, timeout=5)
++        if resp.status_code < 400:
++            return True
++        if resp.status_code < 500:
++            log.warning("delivery rejected: %s", resp.status_code)
++            return False
++        log.warning("delivery failed (attempt %d): %s", attempt, resp.status_code)
++        if attempt < MAX_ATTEMPTS:
++            time.sleep(BACKOFF_SECONDS[attempt - 1])
++    return False
+diff --git a/tests/test_deliver.py b/tests/test_deliver.py
+--- a/tests/test_deliver.py
++++ b/tests/test_deliver.py
+@@ -10,12 +10,22 @@ def test_delivery_ok(mock_post):
+     assert deliver("https://example.test/hook", {"id": 1}) is True
+
+
+-def test_delivery_timeout(mock_post):
+-    mock_post.side_effect = requests.Timeout
+-    with pytest.raises(requests.Timeout):
+-        deliver("https://example.test/hook", {"id": 1})
++def test_retry_on_503(mock_post, monkeypatch):
++    monkeypatch.setattr("webhooks.deliver.time.sleep", lambda s: None)
++    mock_post.side_effect = [Resp(503), Resp(503), Resp(200)]
++    assert deliver("https://example.test/hook", {"id": 1}) is True
++    assert mock_post.call_count == 3
++
++
++def test_no_retry_on_404(mock_post):
++    mock_post.return_value = Resp(404)
++    assert deliver("https://example.test/hook", {"id": 1}) is False
++    assert mock_post.call_count == 1

package/packs/dev-team/skills/pr-description-writer/evals/files/1/commits.txt

@@ -0,0 +1,5 @@
+a41c9e2 Retry webhook delivery on 5xx
+
+    Refs #482. Deliveries were dropped when the receiver returned 503.
+
+7be0d13 Add backoff between retries

package/packs/dev-team/skills/pr-description-writer/evals/files/2/fix.diff

@@ -0,0 +1,30 @@
+diff --git a/billing/totals.py b/billing/totals.py
+--- a/billing/totals.py
++++ b/billing/totals.py
+@@ -1,13 +1,13 @@
+-from decimal import Decimal, ROUND_HALF_EVEN
++from decimal import Decimal, ROUND_HALF_UP
+
+-ROUNDING = ROUND_HALF_EVEN
++ROUNDING = ROUND_HALF_UP
+ CENT = Decimal("0.01")
+
+
+ def invoice_total(lines, tax_rate):
+-    subtotal = sum(Decimal(str(l.qty)) * l.unit_price for l in lines)
+-    tax = (subtotal * tax_rate).quantize(CENT, rounding=ROUNDING)
+-    return (subtotal + tax).quantize(CENT, rounding=ROUNDING)
++    subtotal = sum((Decimal(str(l.qty)) * l.unit_price).quantize(CENT, rounding=ROUNDING) for l in lines)
++    tax = (subtotal * tax_rate).quantize(CENT, rounding=ROUNDING)
++    return subtotal + tax
+diff --git a/tests/billing/test_totals.py b/tests/billing/test_totals.py
+--- a/tests/billing/test_totals.py
++++ b/tests/billing/test_totals.py
+@@ -22,3 +22,9 @@ def test_total_with_tax():
+     assert invoice_total(lines, Decimal("0.20")) == Decimal("24.00")
++
++
++def test_line_totals_round_before_summing():
++    lines = [Line(qty=3, unit_price=Decimal("0.335")), Line(qty=3, unit_price=Decimal("0.335"))]
++    # each line is 1.005 -> 1.01, so the subtotal is 2.02, not 2.01
++    assert invoice_total(lines, Decimal("0")) == Decimal("2.02")

package/packs/dev-team/skills/pr-description-writer/evals/files/3/big.diff

@@ -0,0 +1,90 @@
+diff --git a/api/orders.py b/api/orders.py
+--- a/api/orders.py
++++ b/api/orders.py
+@@ -8,12 +8,16 @@ router = APIRouter()
+
+ @router.get("/orders")
+-def list_orders(limit: int = 50, offset: int = 0, db=Depends(get_db)):
+-    return db.query(Order).order_by(Order.id).offset(offset).limit(limit).all()
++def list_orders(page_size: int = 50, offset: int = 0, include_archived: bool = False, db=Depends(get_db)):
++    q = db.query(Order)
++    if not include_archived:
++        q = q.filter(Order.archived_at.is_(None))
++    return q.order_by(Order.id).offset(offset).limit(page_size).all()
+diff --git a/jobs/archive.py b/jobs/archive.py
+new file mode 100644
+--- /dev/null
++++ b/jobs/archive.py
+@@ -0,0 +1,14 @@
++import os
++from datetime import datetime, timedelta, timezone
++
++from models import Order
++
++ARCHIVE_DAYS = int(os.environ["ORDERS_ARCHIVE_DAYS"])
++
++
++def archive_old_orders(db):
++    cutoff = datetime.now(timezone.utc) - timedelta(days=ARCHIVE_DAYS)
++    n = db.query(Order).filter(Order.closed_at < cutoff, Order.archived_at.is_(None)).update(
++        {"archived_at": datetime.now(timezone.utc)})
++    db.commit()
++    return n
+diff --git a/migrations/versions/0042_orders_archived_at.py b/migrations/versions/0042_orders_archived_at.py
+new file mode 100644
+--- /dev/null
++++ b/migrations/versions/0042_orders_archived_at.py
+@@ -0,0 +1,16 @@
++import sqlalchemy as sa
++from alembic import op
++
++revision = "0042"
++down_revision = "0041"
++
++
++def upgrade():
++    op.add_column("orders", sa.Column("archived_at", sa.DateTime(timezone=True), nullable=True))
++    op.create_index("ix_orders_archived_at", "orders", ["archived_at"])
++
++
++def downgrade():
++    op.drop_index("ix_orders_archived_at", "orders")
++    op.drop_column("orders", "archived_at")
+diff --git a/models.py b/models.py
+--- a/models.py
++++ b/models.py
+@@ -14,3 +14,4 @@ class Order(Base):
+     closed_at = Column(DateTime(timezone=True))
++    archived_at = Column(DateTime(timezone=True), nullable=True, index=True)
+diff --git a/core/logging.py b/core/logging.py
+--- a/core/logging.py
++++ b/core/logging.py
+@@ -1,9 +1,15 @@
+-import logging
++import json
++import logging
+
+
+-def setup():
+-    logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s")
++class JsonFormatter(logging.Formatter):
++    def format(self, record):
++        return json.dumps({"ts": self.formatTime(record), "level": record.levelname, "msg": record.getMessage()})
++
++
++def setup():
++    handler = logging.StreamHandler()
++    handler.setFormatter(JsonFormatter())
++    logging.basicConfig(level=logging.INFO, handlers=[handler])
+diff --git a/tests/test_orders.py b/tests/test_orders.py
+--- a/tests/test_orders.py
++++ b/tests/test_orders.py
+@@ -30,3 +30,10 @@ def test_list_orders_default(client):
+     assert len(client.get("/orders").json()) == 50
++
++
++def test_archived_orders_hidden_by_default(client, archived_order):
++    ids = [o["id"] for o in client.get("/orders").json()]
++    assert archived_order.id not in ids
++    ids = [o["id"] for o in client.get("/orders?include_archived=true").json()]
++    assert archived_order.id in ids

package/packs/dev-team/skills/pr-description-writer/manifest.json

@@ -0,0 +1,30 @@
+{
+  "name": "pr-description-writer",
+  "version": "0.1.0",
+  "description": "Write the pull request title and description for one change, from the actual diff and commits: what changed and why, how it was tested with only the checks that were really run, what a reviewer should look at first, and the risk and rollback. It also reports what the diff contains that the commits don't mention, such as a dependency bump, a deleted test or a schema change. Use when the user asks to write a PR description, a pull request summary, a merge request body, or says \"describe this change for review\", \"write up this branch\".",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "pre-merge-review",
+    "release-notes",
+    "test-plan-generator"
+  ],
+  "tags": [
+    "pull-request",
+    "code-review",
+    "git",
+    "description",
+    "merge-request"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Reads a diff and rewrites it for a reviewer. Bounded by the diff; the judgment is in picking what a reviewer needs first."
+  }
+}

package/packs/dev-team/skills/release-notes/SKILL.md

@@ -46,7 +46,7 @@ Converts commit history into two artifacts with different readers: **customer-fa
 
 ## When NOT to use this skill
 
-- ❌ A single PR description — that's one change, just write it
+- ❌ A single PR description — that's one change; use `pr-description-writer`
 - ❌ Reviewing the changes for quality or risk — that's `devils-advocate` / `sonar-review`
 - ❌ Stakeholder narrative about *why* the release matters strategically — feed the notes to `exec-summary`
 - ❌ Generating commit messages going forward — this skill reads history, it doesn't write it

package/packs/dev-team/skills/release-notes/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "release-notes",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Turn git history between two refs into release notes — a customer-facing version written in reader benefits and an internal Keep-a-Changelog version with commit traceability, breaking changes always first. Use when the user wants release notes, a changelog, \"what's in this release\", a deploy announcement, or to summarize changes since the last tag.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
-  "related": ["devils-advocate", "exec-summary", "sonar-review"],
+  "related": ["devils-advocate", "exec-summary", "pr-description-writer", "sonar-review"],
   "tags": ["release-notes", "changelog", "git", "release", "deploy", "communication"],
   "model": { "tier": "standard", "rationale": "Classifies commits and rewrites them for a reader. The audience translation needs judgment; escalate via large-input on very long ranges." }
 }

package/packs/dev-team/skills/tech-debt-register/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: tech-debt-register
+description: Turn a pile of technical-debt complaints, TODOs and incident notes into a ranked register: each item with where it lives, the cost it imposes today backed by evidence, the size of the fix, a decision (pay now, schedule, accept or watch) with the trigger that reopens it, and an owner if one was given. It ends with the few items worth paying down this quarter and why. Use when the user asks for a tech debt register, a debt inventory or backlog, "what debt should we pay down", "prioritise our tech debt", or wants to make the case for refactoring time.
+---
+
+# tech-debt-register
+
+You turn complaints about the codebase into a register a team can decide from. Debt is
+something that costs the team now, every week, until it is fixed. The register says what
+each item costs, what fixing it takes, and what to do about it, and it is short enough to
+be read in a planning meeting.
+
+## How to respond
+
+1. **Gather the items from what you were given.** Notes, a TODO or FIXME list, incident
+   write-ups, a ticket export, the user's own list. In a repository you may also search for
+   `TODO`, `FIXME`, `HACK` and skipped tests, and say that you did. Merge items that
+   describe the same underlying problem and keep the count of what was merged.
+
+2. **Write each item as a thing with a place.** ✅ "Order export builds CSV by string
+   concatenation in `export/orders.py`; breaks on commas in customer names." ❌ "Code
+   quality is poor." ❌ "Needs refactoring." An item you cannot locate goes under
+   *Unlocated*, with the question that would locate it.
+
+3. **State the cost it imposes today, with the evidence.** This is the interest. Use what
+   the input shows: incidents caused, hours lost, a slow build time, a recurring bug, a
+   workaround every new joiner has to learn. Quote or cite it. When the input shows no
+   cost, write `no evidence of cost` and do not guess one. An item with no observable cost
+   is a preference; keep it in the register, at the bottom.
+
+   The user's own statement counts as evidence of a cost, marked `reported, not measured`:
+   "deploys take ages" and "tests are flaky" are costs someone is paying. Record them as
+   reported, say what measurement would confirm them, and still rank them.
+
+4. **Size the fix.** S (under two days), M (up to two weeks), L (more). Use the team's own
+   estimate when they gave one. Add what the fix depends on and what it puts at risk.
+
+5. **Decide, one of four, with a reason in a clause:**
+   - **Pay now**: high, evidenced cost and a fix the team can finish this quarter.
+   - **Schedule**: real cost, but the fix is large or blocked; name what it waits on.
+   - **Accept**: the cost is small or the code is going away; say for how long.
+   - **Watch**: no cost reported or shown; name the signal that would promote it.
+
+   Don't hide behind Watch. A list where every item is Watch is not a register. When costs
+   are reported but unmeasured, still pick an order and one or two candidates to pay down,
+   label the ranking `provisional`, and say which single measurement would change it.
+
+   Every item gets a **trigger**: the event that reopens the decision ("a second export
+   incident", "the service passes 50 req/s"). Not a date alone.
+
+6. **Rank by cost against size.** Evidenced, recurring cost with a small fix first. Do not
+   produce a numeric score that the input cannot support; order the list and say in one
+   line why the top items are on top.
+
+7. **Write the register.** A table with these columns: `ID`, `Item`, `Where`,
+   `Cost today (evidence)`, `Fix size`, `Decision`, `Trigger`, `Owner`. Owner is filled only
+   when the input names one; otherwise `unassigned`. When you can write files, save it as
+   `tech-debt-register.md` so the team can keep it, and show the lead-in and the table in
+   the reply as well. Add a CSV with the same columns when the user asks for one.
+
+8. **Lead with the decision.** Above the table, in this order: the three or fewer items to
+   pay down this quarter and the cost each removes; what was merged, and what was left
+   unlocated or without evidence; the one question whose answer would most change the
+   ranking.
+
+**With nothing to work from** (no items, no repository, no notes), ask for the list in one
+line. With a thin list, build the register from it, mark what is unknown as unknown, and
+say what evidence would firm it up. Do not pad it with debt the input never mentioned.
+
+## Quality bar
+
+- **Every cost has evidence or says it has none.** No invented hours, incident counts,
+  percentages or money.
+- **Every item has a place** or is listed as unlocated.
+- **Every item has a decision and a trigger.**
+- **The top of the list is defensible**: evidenced cost, fix the team can finish.
+- **It fits a planning meeting.** One table, one short lead-in.
+
+## When to use this skill
+
+- ✅ Making the case for refactoring time with something better than "the code is messy"
+- ✅ Quarterly planning: which debt to pay down and which to live with
+- ✅ Turning a TODO grep, incident notes or a rant into a ranked, decided list
+
+## When NOT to use this skill
+
+- ❌ Planning how to carry out one large change. Use `migration-plan`.
+- ❌ Sorting incoming bug reports. Use `bug-triage`.
+- ❌ Cleaning up a tracker backlog of mixed work. Use `backlog-triage`.
+- ❌ Business or delivery risks that are not about the code. Use `risk-register`.
+
+## Anti-patterns to avoid
+
+- ❌ **Invented numbers.** "Costs about 6 hours a week" with nothing behind it is a guess
+  that will be quoted in a planning deck.
+- ❌ **Everything is high priority.** If most items are "pay now", none are.
+- ❌ **Everything is Watch.** Declining to rank because nothing was measured hands the
+  decision back unmade.
+- ❌ **Listing preferences as debt.** "Should be in TypeScript" with no cost is a wish.
+- ❌ **A weighted score to two decimals.** False precision over thin evidence.
+- ❌ **Padding.** Adding generic debt ("improve test coverage") that nobody raised.
+- ❌ **Showing the machinery.** The register is for the team: no mention of this skill or
+  how it was produced.

package/packs/dev-team/skills/tech-debt-register/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Build a tech debt register from these notes",
+    "should_trigger": true
+  },
+  {
+    "query": "Which of our technical debt should we pay down this quarter?",
+    "should_trigger": true
+  },
+  {
+    "query": "I need to make the case to my director for refactoring time. Here's what's wrong with the codebase.",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this TODO/FIXME grep into a prioritised debt backlog",
+    "should_trigger": true
+  },
+  {
+    "query": "Plan the migration from our monolith's Postgres 12 to 16 with a rollback",
+    "should_trigger": false
+  },
+  {
+    "query": "Triage these 40 incoming bug reports by severity",
+    "should_trigger": false
+  },
+  {
+    "query": "Clean up our Jira backlog: find duplicates and stale tickets",
+    "should_trigger": false
+  },
+  {
+    "query": "Build a risk register for the office relocation project",
+    "should_trigger": false
+  }
+]

package/packs/dev-team/skills/tech-debt-register/evals/evals.json

@@ -0,0 +1,45 @@
+{
+  "skill_name": "tech-debt-register",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We have planning next week and I want to argue for debt time. My notes are in debt-notes.md. Turn them into a register and tell me what to pay down this quarter.",
+      "assertions": [
+        "The two notes about the order export (CSV string concatenation and the comma bug) are merged into one item, and the merge is stated",
+        "The export item cites its evidence from the notes (three incidents in Q3, INC-311, INC-318 and INC-327) and is among the items to pay down this quarter",
+        "The 22-minute CI build is recorded with its evidence (the measured time and the 14 engineers waiting on it)",
+        "The 'rewrite the frontend in TypeScript' note is recorded as having no evidence of cost and is not ranked as pay-now",
+        "Every item has a decision (pay now, schedule, accept or watch) and a trigger",
+        "Owners are filled only where the notes name one (Priya for the export); others are unassigned",
+        "It does not invent hours lost, incident counts, money or percentages that are not in the notes",
+        "The lead-in names three or fewer items for this quarter, above the table"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Here's a TODO/FIXME grep of the payments service (todos.txt) and last quarter's incident list (incidents.md). Build a tech debt register.",
+      "assertions": [
+        "The retry-without-idempotency-key TODO in payments/charge.py is linked to the duplicate-charge incidents in incidents.md and ranked at or near the top",
+        "TODOs with no matching incident or stated cost are marked as having no evidence of cost, with decision watch or accept",
+        "Each item names a file or module from todos.txt",
+        "Duplicate or near-duplicate TODOs (the two about hard-coded currency) are merged",
+        "Fix sizes are given as S, M or L, without invented day counts beyond the scale",
+        "It does not invent incidents, dates or customer impact beyond what incidents.md states",
+        "Every item has a trigger that is an event, not only a date"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We have a lot of tech debt: the monolith's deploy takes ages, nobody understands the billing module, tests are flaky, and we're still on Python 3.8. Make me a register.",
+      "assertions": [
+        "It produces a register with the four items rather than refusing or asking a list of questions first",
+        "Each item's cost is marked as not evidenced or unknown, because the prompt gives no numbers",
+        "It does not invent deploy times, flake rates, hours lost or incident counts",
+        "The Python 3.8 item notes that 3.8 is past end of life as a known fact, or asks to confirm, without inventing a specific vulnerability or deadline",
+        "It states what evidence would firm up the ranking (for example deploy duration, flaky-test rate, incidents traced to billing)",
+        "It adds no debt items beyond the four the user listed",
+        "Owners are unassigned"
+      ]
+    }
+  ]
+}

package/packs/dev-team/skills/tech-debt-register/evals/files/1/debt-notes.md

@@ -0,0 +1,9 @@
+# Things that hurt (collected in retro, Sept)
+
+- Order export builds the CSV with string concatenation (export/orders.py). Priya owns export.
+- CI build takes 22 minutes on main (measured last week, `ci-timings.csv`). 14 engineers push to it. People batch PRs to avoid waiting.
+- Export breaks when a customer name has a comma. Three incidents in Q3: INC-311, INC-318, INC-327. Each one was a manual re-export for finance.
+- We should rewrite the frontend in TypeScript, it would be nicer.
+- The `legacy_auth` module is still imported by the admin panel. It's scheduled for removal when admin moves to SSO in Q1.
+- Feature flags are never cleaned up: 143 flags in `flags.yaml`, 61 of them at 100% for more than 6 months. New joiners ask which ones matter.
+- Staging database is refreshed by hand by whoever remembers. Last refresh was 11 weeks ago; two bugs last month only reproduced in prod.

package/packs/dev-team/skills/tech-debt-register/evals/files/2/incidents.md

@@ -0,0 +1,7 @@
+# Payments incidents, Q3 2026
+
+| ID | Date | What happened |
+|---|---|---|
+| INC-402 | 2026-07-19 | 14 customers charged twice after a provider timeout triggered our retry. Refunded manually. |
+| INC-417 | 2026-08-30 | 9 customers charged twice, same cause as INC-402. |
+| INC-431 | 2026-09-12 | Monthly report job killed by the OOM killer; finance report delivered a day late. |

package/packs/dev-team/skills/tech-debt-register/evals/files/2/todos.txt

@@ -0,0 +1,7 @@
+payments/charge.py:88:  # TODO: retries don't send an idempotency key, provider may double-charge
+payments/charge.py:140: # FIXME: currency hard-coded to USD
+payments/refund.py:31:  # TODO: currency is hard-coded, should come from the original charge
+payments/webhooks.py:12: # HACK: sleep(2) to wait for the provider to settle
+payments/ledger.py:207: # TODO: rename this function, the name is misleading
+payments/reports.py:55: # FIXME: loads the whole month into memory
+tests/test_charge.py:14: @pytest.mark.skip(reason="flaky, fix later")

package/packs/dev-team/skills/tech-debt-register/manifest.json

@@ -0,0 +1,31 @@
+{
+  "name": "tech-debt-register",
+  "version": "0.1.0",
+  "description": "Turn a pile of technical-debt complaints, TODOs and incident notes into a ranked register: each item with where it lives, the cost it imposes today backed by evidence, the size of the fix, a decision (pay now, schedule, accept or watch) with the trigger that reopens it, and an owner if one was given. It ends with the few items worth paying down this quarter and why. Use when the user asks for a tech debt register, a debt inventory or backlog, \"what debt should we pay down\", \"prioritise our tech debt\", or wants to make the case for refactoring time.",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "backlog-triage",
+    "bug-triage",
+    "migration-plan",
+    "risk-register"
+  ],
+  "tags": [
+    "tech-debt",
+    "refactoring",
+    "planning",
+    "prioritisation",
+    "engineering"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Structures and ranks items against stated evidence. Judgment is bounded: a cost with no evidence is recorded as unknown, not estimated."
+  }
+}

package/packs/grc/skills/security-questionnaire-response/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: security-questionnaire-response
+description: Answer a customer's security questionnaire from your own evidence: each question gets a direct answer (Yes, No, Partial or Not applicable), a short narrative, and the document and section it rests on. Questions the evidence doesn't cover are marked as needing input instead of being answered, and conflicts between sources, stale evidence and answers that would commit you to future work are flagged for the security owner. Use when the user has a vendor security questionnaire, a SIG or CAIQ, a due-diligence spreadsheet or the security section of an RFP to fill in, or says "answer this security questionnaire", "fill in this vendor assessment".
+---
+
+# security-questionnaire-response
+
+You draft the answers to a customer's security questionnaire from the evidence the company
+already has: policies, an audit report, earlier answers, architecture notes. Every answer
+rests on a document you can point to. Where the evidence runs out you say so, because a
+wrong "Yes" in a questionnaire becomes a contractual claim. The draft is for the security
+owner to review and send; it is not a statement you make on the company's behalf.
+
+## How to respond
+
+1. **Read the questionnaire and the evidence before answering anything.** Take the
+   questions from the file or paste the user gives you, and the evidence from the files they
+   point to. Keep the customer's own question IDs and order.
+
+2. **Answer each question in four parts:**
+   - **Answer**: `Yes`, `No`, `Partial` or `Not applicable`, or `Needs input` when the
+     evidence does not settle it. A question that asks for a value ("what is your retention
+     period?", "how often?") gets the value from the evidence as its answer, not Yes or No.
+   - **Response**: one to three sentences a customer can read, saying what is true today.
+     Plain claims, no marketing. For `Partial`, say what is covered and what is not.
+   - **Evidence**: the document and the section, page or row it comes from.
+   - **Review flag**: blank, or one of the flags in step 4.
+
+3. **Never answer past the evidence.**
+   - Nothing in the evidence covers it → `Needs input`, and name who would know or what
+     document would answer it. Do not infer a "Yes" from a related control.
+   - A certification, audit or test is claimed only if the evidence shows it, with its date
+     and scope. "Working towards ISO 27001" is a `No` with that sentence as the response.
+   - Numbers (retention periods, RTO, patch windows) are copied from the evidence, never
+     rounded or supplied from common practice.
+
+4. **Flag what the security owner must look at:**
+   - `conflict`: two sources disagree. Quote both, with where each comes from. Do not pick.
+   - `stale`: the evidence is older than 12 months, or older than the period the question
+     asks about. Give its date.
+   - `commitment`: the honest answer promises future work ("planned for Q2"). Customers
+     treat these as commitments.
+   - `no`: the answer is `No` or `Partial` on something customers commonly require.
+   - `reused`: taken from a previous questionnaire without a primary source behind it.
+
+5. **Keep answers consistent.** The same underlying question asked twice gets the same
+   answer. If an earlier questionnaire answered it differently, that is a `conflict`.
+
+6. **Write the output in the customer's format, at the length they asked for.** The
+   customer's document is what gets sent back, so fill in their layout: answers under their
+   questions in a document, extra columns (`Answer`, `Response`, `Evidence`, `Review flag`)
+   in a spreadsheet. If they asked for "Yes or No with a short explanation", give exactly
+   that in the document and keep the evidence and flags in your reply and in a separate
+   review notes file. When the user says to fill in a file, fill in that file. Otherwise
+   write a copy next to it (`<name>-answers.csv` or `.md`) and leave the original alone.
+
+   A CSV must stay a valid CSV: quote every field that contains a comma, a quote or a line
+   break, and re-read the file you wrote to check that each row has the same number of
+   columns as the header.
+
+7. **Lead with what needs a person.** Above the answers: how many questions were answered
+   from evidence, how many need input, and how many are flagged; then the flagged and
+   needs-input questions as a short list, each with what would resolve it. Close with one
+   line saying the draft needs the security owner's review before it is sent.
+
+**With a questionnaire and no evidence**, do not answer from general knowledge of what
+companies usually do. Return every question as `Needs input`, grouped by the kind of
+document that would answer it (access control policy, audit report, incident response
+plan), so the user knows what to fetch. With no questionnaire, ask for it in one line.
+
+## Quality bar
+
+- **Every Yes, No and Partial cites a document and a place in it.**
+- **Nothing is claimed that the evidence does not show**: no certification, test, number or
+  control is invented or upgraded.
+- **Gaps are visible.** Needs-input and flagged questions are counted and listed first.
+- **Conflicts are shown, not resolved.**
+- **The customer's IDs, order and wording of questions are preserved.**
+
+## When to use this skill
+
+- ✅ A customer or prospect sends a security questionnaire, SIG, CAIQ or due-diligence sheet
+- ✅ The security section of an RFP needs answers from existing policies and reports
+- ✅ Re-answering last year's questionnaire and checking the old answers still hold
+
+## When NOT to use this skill
+
+- ❌ Mapping your controls to SOC 2 criteria and the evidence an auditor wants. Use
+  `soc2-evidence-map`.
+- ❌ Assessing a processing activity's risk to individuals under GDPR. Use `dpia`.
+- ❌ Finding the threats in a system design. Use `threat-model`.
+- ❌ Listing and scoring business risks. Use `risk-register`.
+
+## Anti-patterns to avoid
+
+- ❌ **"Yes" because most companies do it.** No evidence, no Yes.
+- ❌ **Upgrading the claim.** "Encrypted in transit" in the policy does not become
+  "encrypted in transit and at rest".
+- ❌ **Smoothing over a conflict** by choosing the better-looking source.
+- ❌ **Copying last year's answer** without checking it against a current document.
+- ❌ **Long narratives.** A reviewer scanning 200 answers needs three sentences, not a page.
+- ❌ **Handing back your own format.** The customer sent a form; return their form filled
+  in, not a separate report they have to transcribe from.
+- ❌ **A broken spreadsheet.** An unquoted comma shifts every column after it.
+- ❌ **Showing the machinery.** The answers are for the customer and the security owner: no
+  mention of this skill or how the draft was produced.

package/packs/grc/skills/security-questionnaire-response/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Answer this vendor security questionnaire from our policies",
+    "should_trigger": true
+  },
+  {
+    "query": "A customer sent us a SIG Lite to fill in. The evidence is in this folder.",
+    "should_trigger": true
+  },
+  {
+    "query": "Fill in the security section of this RFP using our SOC 2 summary",
+    "should_trigger": true
+  },
+  {
+    "query": "Check whether last year's due-diligence answers still match our current policies",
+    "should_trigger": true
+  },
+  {
+    "query": "Map our controls to the SOC 2 criteria and list the evidence the auditor will ask for",
+    "should_trigger": false
+  },
+  {
+    "query": "We're adding biometric clock-in. Do we need a DPIA and can you draft it?",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model this new file-upload service",
+    "should_trigger": false
+  },
+  {
+    "query": "Score these risks for the board heat map",
+    "should_trigger": false
+  }
+]

package/packs/grc/skills/security-questionnaire-response/evals/evals.json

@@ -0,0 +1,43 @@
+{
+  "skill_name": "security-questionnaire-response",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Acme sent us their vendor security questionnaire (questionnaire.csv). Our evidence is in the evidence/ folder: the security policy, the SOC 2 summary and last year's answers to another customer. Draft the answers.",
+      "assertions": [
+        "Q4 (ISO 27001 certified?) is answered No, with the response noting it is not held; it is not answered Yes or Partial on the strength of SOC 2",
+        "Q7 (penetration test in the last 12 months) is flagged stale or answered No/Needs input, citing the test dated 2025-06, which is older than 12 months",
+        "Q9 (MFA for all staff) is answered Partial: enforced for engineering and admin access, not yet for all staff, citing the security policy",
+        "Q11 (data retention period) flags a conflict between the security policy (90 days) and last year's answers (30 days), quoting both and not choosing one",
+        "Q12 (cyber insurance) is marked Needs input because no evidence covers it",
+        "Every Yes, No or Partial answer cites a document and a section or row",
+        "The reply leads with counts of answered, needs-input and flagged questions and lists the flagged ones",
+        "The answers keep Acme's question IDs and order, and are written to a new file without overwriting questionnaire.csv"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "A prospect asked these five questions. Can you answer them for us?\n1. Do you encrypt customer data at rest?\n2. Do you have a SOC 2 Type II report?\n3. How often do you run penetration tests?\n4. Where is customer data hosted?\n5. Do you have a documented incident response plan?",
+      "assertions": [
+        "All five questions are returned as Needs input (or the equivalent), because no evidence was supplied",
+        "It does not answer Yes, give a hosting region, a test frequency or a certification from general knowledge",
+        "It says what document would answer each question (for example the encryption standard, the SOC 2 report, the pen-test report, the architecture or hosting record, the incident response plan)",
+        "It keeps the prospect's numbering and wording",
+        "The reply is short and asks for the evidence in plain words"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Fill in the security section of this RFP (rfp-security.md) using evidence/security-policy.md. They want Yes/No with a short explanation.",
+      "assertions": [
+        "The question on encryption in transit is answered Yes citing the policy's TLS 1.2+ requirement, and the answer does not also claim encryption at rest unless the policy states it",
+        "The question on backups being tested is answered from the policy's quarterly restore test, with the frequency copied exactly",
+        "The question on a 24/7 security operations centre is answered No or Needs input, since the policy describes business-hours on-call only",
+        "The question whose honest answer is 'planned' (SSO for the customer portal, planned for Q1 2027) is flagged as a commitment",
+        "Each answer is one to three sentences",
+        "It does not invent certifications, tools, vendors or dates that are not in the policy",
+        "The reply states the draft needs the security owner's review before it is sent"
+      ]
+    }
+  ]
+}

package/packs/grc/skills/security-questionnaire-response/evals/files/1/evidence/previous-answers.csv

@@ -0,0 +1,5 @@
+Customer,Date,Question,Answer
+Adatum,2025-09-02,Do you have an information security policy?,Yes. Version 4.1 approved by the CTO.
+Adatum,2025-09-02,What is your data retention period after termination?,Customer data is deleted 30 days after contract termination.
+Adatum,2025-09-02,Do you perform penetration tests?,Yes. Annual independent penetration test; last completed June 2025.
+Adatum,2025-09-02,Is MFA enforced?,Yes for engineering and production administrators.

package/packs/grc/skills/security-questionnaire-response/evals/files/1/evidence/security-policy.md

@@ -0,0 +1,31 @@
+# Northwind Health information security policy
+
+Version 4.2, approved by the CTO on 2026-03-14. Reviewed annually.
+
+## 1. Scope
+Applies to all staff, contractors and systems that store or process customer data.
+
+## 2. Encryption
+2.1 All customer data in transit is encrypted with TLS 1.2 or higher.
+2.2 Customer data at rest in the production database and object storage is encrypted with AES-256.
+
+## 3. Access control
+3.1 Multi-factor authentication is enforced for engineering staff and for all administrative access to production.
+3.2 Roll-out of multi-factor authentication to all remaining staff is in progress.
+3.3 Access is reviewed quarterly by system owners.
+
+## 4. Training
+4.1 All staff complete security awareness training on joining and annually after that.
+
+## 5. Incident response
+5.1 The incident response plan (IR-001) is maintained by the security lead and tested annually.
+5.2 Security on-call covers business hours, 08:00 to 18:00 UK time, Monday to Friday.
+
+## 6. Backups
+6.1 Production databases are backed up daily. Restores are tested quarterly.
+
+## 7. Retention
+7.1 Customer data is deleted 90 days after contract termination.
+
+## 8. Customer portal
+8.1 Single sign-on for the customer portal is planned for Q1 2027.

package/packs/grc/skills/security-questionnaire-response/evals/files/1/evidence/soc2-summary.md

@@ -0,0 +1,9 @@
+# SOC 2 summary
+
+- Report type: SOC 2 Type II
+- Period covered: 2025-07-01 to 2026-06-30
+- Auditor: Fabrikam Assurance LLP
+- Criteria: Security, Availability
+- Opinion: unqualified
+- Penetration test referenced in the report: independent test by Contoso Security, completed 2025-06-18.
+- ISO 27001: not held. Not in scope of this report.

package/packs/grc/skills/security-questionnaire-response/evals/files/1/questionnaire.csv

@@ -0,0 +1,13 @@
+ID,Question
+Q1,Do you have a documented information security policy approved by management?
+Q2,Is customer data encrypted in transit?
+Q3,Is customer data encrypted at rest?
+Q4,Are you ISO 27001 certified?
+Q5,Do you hold a current SOC 2 Type II report?
+Q6,Are employees required to complete security awareness training annually?
+Q7,Have you had an independent penetration test in the last 12 months?
+Q8,Do you have a documented incident response plan?
+Q9,Is multi-factor authentication enforced for all staff?
+Q10,Are backups performed and tested?
+Q11,What is your retention period for customer data after contract termination?
+Q12,Do you carry cyber liability insurance?

package/packs/grc/skills/security-questionnaire-response/evals/files/3/evidence/security-policy.md

@@ -0,0 +1,31 @@
+# Northwind Health information security policy
+
+Version 4.2, approved by the CTO on 2026-03-14. Reviewed annually.
+
+## 1. Scope
+Applies to all staff, contractors and systems that store or process customer data.
+
+## 2. Encryption
+2.1 All customer data in transit is encrypted with TLS 1.2 or higher.
+2.2 Customer data at rest in the production database and object storage is encrypted with AES-256.
+
+## 3. Access control
+3.1 Multi-factor authentication is enforced for engineering staff and for all administrative access to production.
+3.2 Roll-out of multi-factor authentication to all remaining staff is in progress.
+3.3 Access is reviewed quarterly by system owners.
+
+## 4. Training
+4.1 All staff complete security awareness training on joining and annually after that.
+
+## 5. Incident response
+5.1 The incident response plan (IR-001) is maintained by the security lead and tested annually.
+5.2 Security on-call covers business hours, 08:00 to 18:00 UK time, Monday to Friday.
+
+## 6. Backups
+6.1 Production databases are backed up daily. Restores are tested quarterly.
+
+## 7. Retention
+7.1 Customer data is deleted 90 days after contract termination.
+
+## 8. Customer portal
+8.1 Single sign-on for the customer portal is planned for Q1 2027.

package/packs/grc/skills/security-questionnaire-response/evals/files/3/rfp-security.md

@@ -0,0 +1,10 @@
+# RFP 2026-118, section 7: security
+
+Answer Yes or No with a short explanation.
+
+7.1 Is data encrypted in transit?
+7.2 Are backups tested, and how often?
+7.3 Do you operate a 24/7 security operations centre?
+7.4 Do you support single sign-on for the customer portal?
+7.5 Is access to production reviewed periodically?
+7.6 Is security awareness training mandatory?

package/packs/grc/skills/security-questionnaire-response/manifest.json

@@ -0,0 +1,32 @@
+{
+  "name": "security-questionnaire-response",
+  "version": "0.1.0",
+  "description": "Answer a customer's security questionnaire from your own evidence: each question gets a direct answer (Yes, No, Partial or Not applicable), a short narrative, and the document and section it rests on. Questions the evidence doesn't cover are marked as needing input instead of being answered, and conflicts between sources, stale evidence and answers that would commit you to future work are flagged for the security owner. Use when the user has a vendor security questionnaire, a SIG or CAIQ, a due-diligence spreadsheet or the security section of an RFP to fill in, or says \"answer this security questionnaire\", \"fill in this vendor assessment\".",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "dpia",
+    "risk-register",
+    "soc2-evidence-map",
+    "threat-model"
+  ],
+  "tags": [
+    "security-questionnaire",
+    "vendor-assessment",
+    "due-diligence",
+    "grc",
+    "rfp",
+    "compliance"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Matches questions to evidence and writes short answers. The hard rule is mechanical: no evidence, no answer."
+  }
+}