skilldrop-cli 1.3.0 → 1.5.0

package/packs/grc/loops/comply/evals/files/comply-chat-vendor-launch/vendor-brief.md

@@ -0,0 +1,72 @@
+# Vendor brief: Parlour Chat (live chat + chatbot for customer support)
+
+Prepared by: Customer Operations, Brackenfield Outdoor Ltd
+Date: 28 October 2026
+Target go-live: 1 December 2026
+Business owner (accountable for the risk): Mara Lindqvist-Obi, Head of Customer Operations
+Security contact: Tom Ashdown, IT Security Lead
+DPO: Hollis Granger (dpo@brackenfield.example)
+
+## What we want to do
+
+Replace the contact form on brackenfield.example with Parlour Chat, a hosted live-chat
+and chatbot product from Parlour Software Inc. (parlour.example). Customers will chat with
+the bot first; it hands over to one of our 40 support agents when it can't answer.
+
+The bot will look up a customer's orders so it can answer "where is my order?" without an
+agent. To do that, Parlour will call our order API (orders-api.brackenfield.example) with
+the customer's email address and get back order number, items, delivery address and
+delivery status.
+
+## Data involved
+
+- Customer name and email address (asked at chat start)
+- Chat transcripts (free text; customers sometimes type phone numbers, addresses and,
+  occasionally, card numbers despite the banner telling them not to)
+- Order history returned by our order API: order number, items, delivery address, status
+- Agent names and agent login details (our staff)
+- Browser and device information and IP address (collected by the chat widget)
+
+Roughly 18,000 chats a month based on current contact-form volume. Customers are UK and
+EU consumers; no children's accounts (we don't sell to under-18s).
+
+## Where the data goes
+
+- Parlour hosts in AWS us-east-1 (United States). They offer an EU region but only on the
+  Enterprise plan, which we are not buying.
+- Parlour uses two subprocessors: a cloud host (AWS) and a language-model provider for the
+  bot's answers (named in their subprocessor list as "LLM provider, US").
+- Parlour's default transcript retention is 24 months. It can be set from 30 days to
+  "forever" in the admin console.
+
+## Contract and paperwork status
+
+- Master services agreement: in legal review, not signed.
+- Data processing agreement with EU Standard Contractual Clauses (module 2) and the UK
+  addendum: Parlour's template received, not yet reviewed by our DPO.
+- Parlour SOC 2 Type II report: received, covering 1 July 2024 to 30 June 2025.
+- Transfer risk assessment for the US transfer: not started.
+
+## Controls we plan to rely on
+
+| # | Control | Status today | Who runs it |
+|---|---------|--------------|-------------|
+| C1 | Agent access to Parlour via our SSO (Okta) with MFA; no local Parlour passwords | Configured in Parlour test tenant; SSO screenshot from 21 Oct | IT Security |
+| C2 | Quarterly access review of Parlour agent accounts | Not yet set up; we do quarterly reviews for Zendesk today (last one 30 Sep 2026, signed sheet on SharePoint) | Customer Ops team lead |
+| C3 | Card-number redaction in transcripts (Parlour "PCI mask" feature) | Planned. Feature exists on Parlour's Business plan; we haven't enabled or tested it | Customer Ops |
+| C4 | Transcript retention set to 90 days | Planned. Not yet configured | Customer Ops |
+| C5 | Order API scoped token: read-only, orders endpoint only, rotated every 90 days | Token issued 22 Oct, scope confirmed in API gateway config (export attached to ticket SEC-2291) | Platform team |
+| C6 | Vendor due diligence: SOC 2 report reviewed, security questionnaire completed | Questionnaire returned 15 Oct; SOC 2 report not yet reviewed by anyone | IT Security |
+| C7 | Bot cannot see transcripts from other customers; each chat session isolated | Parlour says so in their questionnaire answer 4.7; we have not tested it | Parlour / IT Security |
+
+## What we are worried about
+
+1. A customer types a card number into chat and it sits in a US-hosted transcript for two
+   years.
+2. Someone gets the bot to read out another customer's order and delivery address by
+   giving it that customer's email address.
+3. The language-model provider uses our transcripts to train its models.
+4. Ex-agents keep access after they leave.
+5. Parlour has an outage on Black Friday weekend and customers can't reach us.
+
+Mara needs to sign off the risk position before go-live. Please get us to that point.

package/packs/grc/loops/comply/evals/files/comply-loyalty-app-unowned-risks/launch-note.md

@@ -0,0 +1,31 @@
+# Northgate Grocers loyalty app: launch note
+
+Launch: Monday 9 November 2026 (iOS and Android, UK only)
+Risk owner for the launch: Priya Venkataraman, Director of Digital (on leave 2 to 20 November)
+Product lead: Dev Ostrowski
+Security lead: Ines Carvalho
+
+## What the app does
+
+- Customers sign up with email and password and collect points by scanning the QR code on
+  their till receipt.
+- When a customer is within 200 m of a Northgate store, the app shows a push notification
+  with that store's offers. This uses the phone's precise location. The current build asks
+  for "Allow all the time" location permission so it can notify in the background.
+- Marketing added the Beacon analytics SDK (beacon-analytics.example) in October to track
+  funnels. It's initialised at app start, before the consent screen.
+
+## Data
+
+Name, email, password hash, points balance, purchase history from scanned receipts,
+precise device location, device ID, push token. About 120,000 sign-ups expected in the
+first three months.
+
+## Paperwork
+
+- Risk register: attached (risk-register.csv). Last full review was in June, before the
+  location feature and the analytics SDK were added; R2, R4 and R5 were refreshed on
+  20 October.
+- DPIA: none yet. Our DPO (Faye Mbatha) asked in September whether one was needed for the
+  location feature; nobody replied.
+- Beacon analytics: no data processing agreement on file.

package/packs/grc/loops/comply/evals/files/comply-loyalty-app-unowned-risks/risk-register.csv

@@ -0,0 +1,6 @@
+id,title,cause,event,consequence,owner,inherent_likelihood,inherent_impact,inherent_score,controls,residual_likelihood,residual_impact,residual_score,treatment,due_date,last_review,next_review
+R1,Location data over-collection,App requests background location to trigger in-store offers,App collects precise location continuously including when user is not near a store,Regulatory complaint and loss of customer trust,TBC,4,4,16,Location permission prompt,2,3,6,reduce,2026-11-09,2026-06-02,2026-09-02
+R2,Offer engine outage at launch,Offer engine is a new service with no load test,Offer engine fails under launch-day traffic,Customers see no offers; launch campaign wasted,Dev Ostrowski,3,3,9,Autoscaling on offer engine; launch-day on-call rota,2,3,6,reduce,2026-11-09,2026-10-20,2027-01-20
+R3,Third-party analytics SDK sharing data,Marketing added the Beacon analytics SDK to the app,SDK sends device ID and location to the analytics vendor,Unlawful sharing of personal data without consent,,3,4,12,,1,2,2,accept,2026-11-09,2026-06-02,2026-09-02
+R4,Loyalty points fraud,Points can be earned by scanning receipt QR codes,Users reuse or forge receipt QR codes to farm points,Financial loss from points redeemed for goods,Ines Carvalho,3,2,6,QR codes signed and single-use,1,2,2,reduce,2026-11-09,2026-10-20,2027-01-20
+R5,Account takeover,Login is email and password only,Attacker logs in with leaked credentials and redeems points,Customer loses points; support load; complaints,Ines Carvalho,3,3,9,Rate limiting on login; breached-password check,2,3,6,reduce,2026-11-09,2026-10-20,2027-01-20

package/packs/infra-as-code/skills/terraform-module/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "terraform-module",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Generate a Terraform module from a described need, with main.tf, variables.tf, outputs.tf and versions.tf, typed and validated variables, secure defaults (encryption on, public access off, least-privilege IAM), a merged tags variable, a basic usage example and a README with inputs and outputs tables. Use when the user says \"write a terraform module for\", \"create terraform for an S3 bucket / VPC / database\", \"turn this into a reusable module\", or \"scaffold infrastructure as code for\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -35,8 +35,8 @@
     "hcl"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Structured generation against fixed module conventions and a secure-defaults checklist; the judgment is bounded to choosing defaults and validation rules for a described need."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 100% of checks in two tier trials, against standard's 92% and heavy's 83% and 100%, within 5 points of the best both times."
   },
   "permissions": {
     "network": [

package/packs/product-manager/skills/prd-draft/SKILL.md

@@ -28,6 +28,7 @@ Turns "the business wants X" into the document that aligns everyone on **what pr
 ## Useful references in this skill
 
 - [`templates/prd.md`](templates/prd.md) — the PRD skeleton with the solution-language test and MoSCoW table
+- [`examples/approver-delay-not-slack.md`](examples/approver-delay-not-slack.md) — worked example: a brief that blames a missing Slack integration when the data says approvers sit on requests
 
 ## Quality bar
 

package/packs/product-manager/skills/prd-draft/examples/approver-delay-not-slack.md

@@ -0,0 +1,142 @@
+# Worked example: a "Slack approvals" brief whose data describes a different problem
+
+Input → output oracle for `prd-draft`. Shows a solution-shaped brief rewritten as the problem
+its own data describes, an unsupported goal replaced by one the data can measure, and a policy
+constraint that the brief's "one click" pitch would have broken.
+
+## Input
+
+> Write the PRD for Slack approvals so eng can start next sprint. Sales says it's the #1 ask.
+> Two pages max. Everything I have is below.
+>
+> **brief.md (Head of Sales):**
+> Problem: we don't have a Slack integration and competitors do. Customers ask for it
+> constantly. Solution: Slack approvals, so managers approve expenses with one click right in
+> Slack. Seamless. Must use Slack Block Kit interactive messages. Goal: cut churn by 15%. Has
+> to ship before the Ledgerline Summit on 2027-03-09.
+>
+> **crm-summary.md:**
+> - Feature requests tagged "slack": 14 requests from 9 accounts in the last 12 months, out of
+>   1,340 paying accounts.
+> - Requests tagged "approval reminders" or "approve from phone": 31 requests from 22 accounts.
+>
+> **product-analytics.md:**
+> - Median time an expense waits at the approver step: 4.6 days. Median time in all other
+>   steps combined: 0.8 days.
+> - Of reimbursements paid late (more than 10 days after submission, the SLA in our customer
+>   contracts), 58% waited on an approver for more than 5 days.
+> - Chat tool connected, by account: Slack 38%, Microsoft Teams 27%, none 35%.
+> - Approvers who open the email notification approve a median of 1.1 days after it is sent.
+>
+> **policy.md (Finance and Security):**
+> - Approving an expense over $2,500 requires the approver to be signed in with MFA.
+> - Approvers cannot edit amounts. They can approve, reject with a reason, or return for changes.
+
+## Output
+
+```markdown
+# PRD: Faster approver decisions on submitted expenses
+
+**Status:** draft · **Owner:** Product Manager, Approvals · **Date:** 2026-11-05
+**Binding constraint:** fixed deadline, ship before 2027-03-09 `[reported by Head of Sales]`
+
+## Problem
+
+Employees wait for reimbursement mainly because expenses sit with their approver. The median
+wait at the approver step is 4.6 days, against 0.8 days for every other step combined
+`[data: product analytics]`. Of the reimbursements that miss the 10-day contractual SLA, 58%
+waited on an approver for more than 5 days `[data: product analytics]`. Approvers who open the
+notification email act in a median of 1.1 days `[data: product analytics]`, which suggests the
+delay is in noticing and getting to the request rather than in deciding `[assumption]`.
+Customers ask about this in several forms: 31 requests from 22 accounts for reminders or
+approving from a phone, and 14 requests from 9 accounts for Slack `[data: CRM]`.
+
+## Users
+
+**Primary:** a manager who approves their team's expenses, works mostly outside the expense
+app, and gets to approvals in batches. Job-to-be-done: clear the pending requests without
+setting time aside to log in.
+**Secondary (explicitly deprioritized):** employees who submit expenses. They feel the delay
+but cannot shorten it. Finance admins, who chase late approvals today, benefit indirectly.
+
+## Goals
+
+| # | Goal | We'll know it worked when |
+|---|---|---|
+| G1 | Approvers decide sooner | Median approver-step time drops from 4.6 to ≤ 2.0 days within 90 days of GA `[target: assumption]` |
+| G2 | Fewer reimbursements miss the contractual SLA | The share of reimbursements paid after 10 days falls by a third within 90 days of GA `[baseline needed]` |
+
+Full measurement design (instrumentation, guardrails, decision rule): hand to `success-metrics`.
+
+## Requirements
+
+| ID | Requirement (testable, solution-free) | MoSCoW | Maps to goal |
+|---|---|---|---|
+| R1 | An approver can approve, reject with a reason, or return for changes on an expense of $2,500 or less, from the notification itself, without signing in to the web app | M | G1 |
+| R2 | For an expense over $2,500, the same notification takes the approver to a signed-in, MFA-verified screen to decide | M | G1 |
+| R3 | The notification shows employee, amount, category, date and receipt thumbnail, enough to decide without opening the expense | M | G1 |
+| R4 | An approver with any pending request older than 2 days gets one reminder per day, listing all of them | S | G1, G2 |
+| R5 | The approver can act from at least one channel that reaches accounts with no chat tool connected | S | G2 |
+| R6 | A decision made from a notification shows in the expense's audit history with time and channel | M | G1 |
+| R7 | An approver can approve several pending requests in one action | C | G1 |
+
+**Won't have (this version):**
+- Editing amounts from a notification: policy forbids approvers editing amounts at all
+- Decisions on expenses over $2,500 without MFA, however the notification is delivered
+
+## Non-goals (minimum 3 — the scope-creep firewall)
+
+- **Submitting expenses from chat:** the delay is at approval, not submission. Revisit if
+  submission time becomes the bottleneck.
+- **Every chat tool in v1:** Slack reaches 38% of accounts and Teams 27% `[data]`. Which
+  channels ship first is a design decision, made against those numbers and the deadline.
+- **Finance-admin bulk overrides:** a different user with a different authorization surface.
+- **Churn reduction as a v1 target:** nothing in the inputs links approval time to churn. The
+  brief's "−15% churn" is out until someone produces that link.
+
+## Quality targets
+
+A decision taken from a notification shows in the web app within 10 seconds `[assumption]`.
+MFA rule as in policy. Full treatment → `nfr-spec`.
+
+## Open questions
+
+| Question | Owner | Needed by |
+|---|---|---|
+| Which channel(s) ship first given the 38% / 27% / 35% split and the 2027-03-09 date? | Eng lead + PM | 2026-11-19 |
+| What is the current share of reimbursements paid after 10 days (G2 baseline)? | Data analyst | 2026-11-12 |
+| Is there any evidence linking approval delay to churn? | Head of Sales | 2026-11-26 |
+| Can a decision from a notification count as "signed in" for the audit trail Finance needs? | Security lead | 2026-11-19 |
+
+## Assumptions log
+
+- [assumption] The delay is in noticing requests, not deciding them. Challenge by checking time-to-open versus time-to-decide by 2026-11-19.
+- [assumption] The G1 target of ≤ 2.0 days. Challenge in requirements review.
+
+## Handoffs
+
+- Stories & slicing → `user-story-splitter`
+- Quality targets → `nfr-spec`
+- Measurement → `success-metrics`
+- Technical approach (including the Block Kit question in the brief) → `design-doc`
+```
+
+## Why this is the oracle
+
+- **The problem statement passes the alternative-solution test.** The brief's problem, "we
+  don't have a Slack integration", is the absence of a solution. The data describes approvers
+  sitting on requests. Daily reminders, email actions, Teams, mobile push and Slack could each
+  follow from the rewritten paragraph. That matters here because Slack alone reaches 38% of
+  accounts.
+- **Every claim is tagged to its source and every goal can be measured.** "Customers ask
+  constantly" becomes 14 requests from 9 of 1,340 accounts, set beside the 31 requests from 22
+  accounts for reminders. The −15% churn goal has no support in the inputs, so it moves to the
+  non-goals with the reason, and G1 measures something the analytics already track.
+- **Requirements are testable and free of implementation.** "Must use Block Kit" goes to
+  design. "One click, seamless" becomes R1, which a tester can pass or fail. R2 carries the
+  $2,500 MFA rule, which the brief's pitch would have broken.
+
+A cheaper pass writes "Problem: competitors have Slack approvals and we don't", makes every
+line in the brief a Must, keeps "cut churn 15%" as G1 and "use Block Kit" as R1, and specifies
+one-click approval for every amount. That PRD ships a feature that 62% of accounts cannot
+use, measures it against a number nothing supports, and fails a security review in sprint 4.

package/packs/product-manager/skills/prd-draft/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "prd-draft",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Draft a Product Requirements Document from a feature idea or brief — evidence-backed problem statement with zero solution language, testable MoSCoW-prioritized requirements, mandatory non-goals, and a success line per goal. Use when the user needs a PRD, wants to capture business requirements for a feature, or asks to turn an idea, pitch, or brief into a requirements doc.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -12,5 +12,5 @@
     { "to": "design-doc", "when": "the what is agreed and the how is open", "purpose": "Design the system that satisfies these requirements.", "fallback": "If design-doc is absent, write the approach, the alternatives, and the trade-offs inline." }
   ],
   "tags": ["prd", "requirements", "product", "discovery", "moscow", "non-goals"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a structured requirements doc from a brief. The solution-language discipline needs care; bounded by the template. Escalate via ambiguous-input on contested scope." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 85% and 76% of checks in two tier trials, against standard's 68% and light's 68% and 68%, more than 5 points ahead both times; moved once its examples/ oracle shipped (RFC-0074)." }
 }

package/packs/product-manager/skills/user-journey-map/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "user-journey-map",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Map a customer's end-to-end journey toward an outcome — 3–6 stages, each with actions, emotions, pains, and opportunities, plus a rendered Mermaid emotion arc and the ranked pain points design should attack first. Use when the user wants a journey map, customer experience map, \"map the user's path through onboarding\", touchpoint analysis, or \"where do users feel friction\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -11,5 +11,5 @@
     { "to": "success-metrics", "when": "the fix needs a measure before it is built", "purpose": "Design the measurement for the journey step being changed.", "fallback": "If success-metrics is absent, state one baseline and one target per fixed step inline." }
   ],
   "tags": ["journey-map", "customer-experience", "ux", "touchpoints", "mermaid", "personas"],
-  "model": { "tier": "standard", "rationale": "Structured synthesis into a fixed four-row stage model plus bounded ranking judgment. Escalate via ambiguous-input when the persona or outcome is contested or research inputs conflict." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 83% and 83% of checks in two tier trials, against standard's 75% and light's 67% and 75%, more than 5 points ahead both times." }
 }

package/packs/research/loops/research/evals/evals.json

@@ -34,6 +34,34 @@
         "Does not invent a decision or gather sources",
         "Says in plain words what it will produce once it has the decision"
       ]
+    },
+    {
+      "id": "research-trial-conversion-drop",
+      "held_out": "2026-11-04",
+      "prompt": "Research why trial-to-paid dropped in September. We have to decide by the 15th whether the onboarding email rebuild goes ahead of the pricing page A/B test on next quarter's roadmap, so I need to know which explanation actually holds up. Everything we've got is in sources/ (six files).",
+      "assertions": [
+        "Starts with a research plan tied to the roadmap decision in the prompt (onboarding email rebuild versus pricing page A/B test), with sub-questions and what finding would change the decision, before any synthesis",
+        "The synthesis cites a source for each claim and counts the growth recap (s6) once, as a repeat of the s1 figures rather than independent confirmation",
+        "Sets out rival explanations including at least onboarding email deliverability, the 15 September pricing page change, the Vantor free tier and seasonality",
+        "Ranks by contradicting evidence: the drop starts with the 31 Aug and 7 Sep cohorts, before the 15 Sep pricing change and the 10 Sep Vantor launch, the 21 Sep cohort recovers while both are still in place, and the 2025 September cohorts show no dip",
+        "Puts the broken DKIM on the onboarding emails (2 to 19 September) as the least-contradicted explanation, and names the missing join between email opens and conversion as the linchpin or the remaining check",
+        "Gives a G7 verdict that lets the answer go forward (such as PROCEED or PROCEED WITH CONDITIONS) rather than sending the work back",
+        "Does not invent figures not in the sources, such as revenue lost, conversion rates for users who did or did not open the emails, or a count of trial users who tried Vantor"
+      ]
+    },
+    {
+      "id": "research-ticket-spike-confounded",
+      "held_out": "2026-11-04",
+      "prompt": "Research what's behind the jump in support tickets since early October. Ops need to know by Monday whether to roll back the app 4.2 navigation or put temp staff on billing queries, we can't do both. Sources are in sources/. Just give me the answer.",
+      "assertions": [
+        "The plan ties the work to the rollback-versus-temp-staff decision and says what finding would favour each option, before any synthesis",
+        "The synthesis cites a source for each claim and notes that October tickets carry no topic tags because tagging stopped on 28 September",
+        "Treats the agent poll (5 against 4) as opinion, not as evidence that separates the two explanations",
+        "The comparison shows that the billing migration (live 5 October) and the 4.2 release (6 October) landed in the same week, and that 'where is my invoice' tickets and the October reviews fit both, so neither is clearly less contradicted",
+        "The G7 gate does not let the answer go forward as decided: it returns a send-back verdict (such as REVISE) rather than PROCEED",
+        "Names a specific observation that would tell the two apart, such as re-tagging a sample of October tickets by topic or comparing ticket rates for web-only customers (billing change, no app change) against app users",
+        "Does not invent a ticket breakdown by topic, a count of duplicate authorisations, or a cause the sources do not support"
+      ]
     }
   ]
 }

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t1-ticket-volume.md

@@ -0,0 +1,15 @@
+# Support ticket volume — weekly, from the helpdesk
+
+Exported 2026-10-27. Brand: Ploverly (online invoicing for tradespeople; web app plus iOS and Android apps).
+
+| Week starting | Tickets created |
+|---|---|
+| 7 Sep  | 1,228 |
+| 14 Sep | 1,251 |
+| 21 Sep | 1,236 |
+| 28 Sep | 1,247 |
+| 5 Oct  | 1,734 |
+| 12 Oct | 1,812 |
+| 19 Oct | 1,763 |
+
+Note from the helpdesk admin: on 28 September the contact form was rebuilt and the "topic" dropdown was removed by mistake, so automatic topic tagging has not run on any ticket created since then. October tickets have no topic tags. Tickets do record the channel they came in on (web form, in-app, email), but the in-app form is the same in the web app and the mobile apps.

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t2-release-notes-4-2.md

@@ -0,0 +1,11 @@
+# Ploverly mobile 4.2 — release notes
+
+Released Tuesday 6 October 2026 to 100% of iOS and Android users (no staged rollout).
+
+- New bottom navigation bar replaces the side menu
+- "Invoices" and "Payments" merged into one "Money" tab
+- "Download invoice PDF" moved from the invoice screen into the "..." menu
+- Dark mode
+- Bug fixes
+
+The web app was not changed in this release.

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t3-billing-migration.md

@@ -0,0 +1,12 @@
+# Billing platform migration — completion note
+
+Author: Finance systems · 2026-10-07
+
+The move from the old billing system to the new one finished over the weekend of 3–4 October 2026. From 5 October, all customers' subscription invoices (web and app customers alike) are generated by the new system.
+
+Customer-visible changes:
+- Invoice numbers changed format (PLV-000123 became 2026-10-000123)
+- Subscription invoices are now emailed from billing@ploverly.example instead of accounts@ploverly.example
+- A known issue: some customers saw a duplicate "pending" card authorisation on 5–6 October. The second authorisation drops off on its own within 7 days and was never charged. We do not yet know how many customers were affected.
+
+Finance has not reviewed support tickets about billing since the migration.

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t4-agent-poll.md

@@ -0,0 +1,11 @@
+# #support-team poll — 2026-10-20
+
+Question from the support manager: "What's driving the extra tickets?" 9 agents answered.
+
+- App navigation / can't find things in the new app — 5
+- Billing questions (new invoice numbers, double charges, emails) — 4
+
+Free-text comments:
+- "Loads of 'where is my invoice'. Honestly could be either — some mean their subscription invoice, some mean the invoices they send to their own customers."
+- "The double charge ones are angry but I'd say there were only a handful a day in the first week."
+- "Mostly app stuff on my queue but I only do in-app chat."

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t5-app-store-reviews.md

@@ -0,0 +1,12 @@
+# App store reviews summary — October 2026
+
+Average rating (iOS and Android combined): 4.5 in September, 4.1 for reviews posted 6–25 October.
+
+Sample of October 1–2 star reviews (verbatim):
+- "Can't find where to download my invoices anymore. Why change what worked?"
+- "New menu is confusing, took me ages to find payments."
+- "Charged twice this month and no one tells me why!!"
+- "Where are my invoices??"
+- "Invoice numbers all changed, my accountant is confused."
+
+Reviews mentioning the new navigation: not counted. Reviews mentioning charges or billing: not counted.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s1-analytics-export.md

@@ -0,0 +1,29 @@
+# Trial-to-paid conversion by weekly trial cohort
+
+Exported from the product analytics workspace, 2026-10-29. Product: Tallyfold (self-serve bookkeeping, Starter plan).
+Conversion = share of trials started that week that became paid within 14 days of trial start. Cohort week starts Monday.
+
+## 2026
+
+| Cohort week | Trials started | Converted to paid | Conversion |
+|---|---|---|---|
+| 3 Aug  | 1,142 | 214 | 18.7% |
+| 10 Aug | 1,168 | 220 | 18.8% |
+| 17 Aug | 1,131 | 207 | 18.3% |
+| 24 Aug | 1,155 | 216 | 18.7% |
+| 31 Aug | 1,149 | 171 | 14.9% |
+| 7 Sep  | 1,160 | 130 | 11.2% |
+| 14 Sep | 1,137 | 132 | 11.6% |
+| 21 Sep | 1,151 | 203 | 17.6% |
+| 28 Sep | 1,146 | 207 | 18.1% |
+
+## 2025, same weeks (for comparison)
+
+| Cohort week | Conversion |
+|---|---|
+| 1 Sep 2025  | 18.2% |
+| 8 Sep 2025  | 18.9% |
+| 15 Sep 2025 | 18.4% |
+| 22 Sep 2025 | 18.6% |
+
+Notes: trial sign-up flow and the 14-day trial length were unchanged across the period. No tracking changes were made to the conversion event.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s2-email-delivery-report.md

@@ -0,0 +1,25 @@
+# Lifecycle email: incident note — onboarding sequence deliverability
+
+Author: Ines Carvalho (Lifecycle marketing) · 2026-09-22
+
+## What happened
+
+On 2 September we moved lifecycle email to a new sending provider and a new sending subdomain (mail.tallyfold.example). The DKIM record for the new subdomain was published with a typo, so messages failed DKIM signing checks at the major mailbox providers.
+
+The onboarding sequence (day 1 "Set up your books", day 3 "Connect your bank", day 7 "Your first VAT return") goes to every new trial user. It was the only sequence moved on 2 September; billing and password emails stayed on the old provider.
+
+## Impact on the onboarding sequence
+
+| Period | Delivered (accepted by receiving server) | Open rate |
+|---|---|---|
+| 1–31 Aug (old provider) | 98.1% | 52% |
+| 2–19 Sep (new provider, DKIM broken) | 97.4% | 6% |
+| 20–30 Sep (DKIM fixed) | 98.0% | 49% |
+
+"Delivered" stayed high because the receiving servers accepted the messages; seed tests on 18 September showed them landing in spam folders.
+
+The DKIM record was corrected on the evening of 19 September.
+
+## Not known
+
+We have not measured whether trial users who never opened the onboarding emails convert at a lower rate. That join between email events and billing has not been built.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s3-pricing-changelog.md

@@ -0,0 +1,9 @@
+# Website changelog — pricing page
+
+| Date | Change | Owner |
+|---|---|---|
+| 2026-06-30 | Fixed broken FAQ anchor links | Web team |
+| 2026-09-15 | Pricing page redesign went live: new layout, annual plan toggle on by default, comparison table moved below the fold. Starter price unchanged at £24/month (£19/month billed annually). | Web team / Growth |
+| 2026-10-02 | Copy tweak on Starter card ("Everything a sole trader needs") | Growth |
+
+The in-app upgrade screen that trial users see was not changed on 15 September; only the public pricing page.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s4-trial-interview-notes.md

@@ -0,0 +1,21 @@
+# Calls with September trial users who did not convert
+
+Interviewer: Femi Adebayo (Growth) · calls 5–9 October 2026 · 5 calls, 20 minutes each
+Recruited from trial users whose trial started 7–18 September and who did not pay. 31 emailed, 5 agreed.
+
+**P1 — sole trader, decorator**
+"I signed up and then didn't really know where to start. I was waiting for some kind of guide." Did not recall receiving any emails from Tallyfold. Found them in spam during the call.
+
+**P2 — small bakery, two staff**
+Got stuck connecting the bank feed. "I assumed there'd be a walkthrough." No recollection of onboarding emails.
+
+**P3 — freelance designer**
+Said the price was too high compared with "Vantor, which is free now". Had looked at the pricing page before signing up.
+
+**P4 — dog groomer**
+"Never got the setup email, I don't think." Gave up after the first day.
+
+**P5 — consultant**
+Busy month, didn't have time to try it properly. Might come back in January.
+
+Interviewer's note: small sample, self-selected. Three of five mention not getting or not finding the setup guidance.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s5-competitor-note.md

@@ -0,0 +1,9 @@
+# Competitor watch: Vantor free tier
+
+Author: Growth team · 2026-09-12
+
+Vantor announced a free tier for sole traders on their blog on 10 September 2026 (blog.vantor.example/free-for-sole-traders). Limits: one bank account, 20 invoices a month, no VAT returns.
+
+Our Starter plan includes VAT returns, which the Vantor free tier does not.
+
+We have no data yet on how many of our trial users also tried Vantor.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s6-weekly-growth-recap.md

@@ -0,0 +1,7 @@
+# #growth weekly recap — posted 2026-10-01 by the growth channel bot
+
+Trial conversion took a hit in September: 14.9% for the 31 Aug cohort, 11.2% for 7 Sep and 11.6% for 14 Sep, against about 18.7% in August. The 21 Sep cohort is back at 17.6%.
+
+Looks seasonal to me — September is always soft after the summer, people are busy with back-to-school. Probably nothing to worry about. — Ollie
+
+(figures from the analytics workspace export)

package/packs/research/skills/research-plan/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "research-plan",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Turn a vague research question into a research plan — the decision the research serves, the precise question and sub-questions, what finding would change the decision, a method per sub-question (desk research, interviews, data pull, experiment), source types with inclusion and exclusion criteria, ready-to-run search strings, a stopping rule for when you have enough, and the deliverable. Starts by asking what decision the research is for. Use when the user says \"I need to research X\", \"help me scope this research\", \"how should I investigate…\", \"what should I look into before deciding…\", or wants a research or discovery plan.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -40,7 +40,7 @@
     "search"
   ],
   "model": {
-    "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."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 79% and 79% of checks in two tier trials, against standard's 79% and heavy's 79% and 79%, within 5 points of the best both times."
   }
 }

package/packs/research/skills/source-synthesis/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "source-synthesis",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Answer a question from a set of sources the user supplied — papers, reports, articles, interview notes, emails — saying only what the material supports, labelling anything that comes from elsewhere where it appears, counting a source that repeats another once, and giving a labelled estimate when the user needs a figure the sources don't settle. Written in the length and format the user asked for; a full cited literature review only when that is the ask. Use when the user hands over several sources and asks to \"synthesise these\", \"what do these papers say\", \"pull together what we know\", \"literature review\", or \"where do the sources agree and disagree\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -36,7 +36,7 @@
   ],
   "permissions": {"network": [], "commands": [], "files": "named-paths"},
   "model": {
-    "tier": "standard",
-    "rationale": "Bounded synthesis over supplied text. The hard part is keeping outside knowledge out and checking the sources' own sums, which a mid-tier model does when told to."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 83% and 78% of checks in two tier trials, against standard's 76% and heavy's 85% and 82%, within 5 points of the best both times."
   }
 }

package/packs/skill-engineering/skills/skill-author/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "skill-author",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Write a new portable Agent Skill (a SKILL.md folder) from a described task, for Claude Code, Codex, Copilot, Cursor, Kiro or Antigravity in any repo — a description that leads with the artifact and ends with trigger phrases, decisive steps, a quality bar, when and when-not sections naming near-miss siblings, anti-patterns, a non-interactive rule, reference files and scripts that work in every tool, acceptance evals and trigger queries, and the install path for each tool. Use when the user says \"turn this into a skill\", \"write a SKILL.md for…\", \"make an agent skill that…\", or wants a repeatable task packaged so their coding agent does it the same way every time.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -35,7 +35,7 @@
     "copilot"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Structured authoring against a fixed anatomy. The judgment is in the description and sibling boundaries, which the interview anchors; skill-review is the adversarial pass."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 93% of checks in two tier trials, against standard's 93% and heavy's 100% and 92%, within 5 points of the best both times."
   }
 }