skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/experience-design/skills/information-architecture/reference.md

@@ -0,0 +1,54 @@
+# information-architecture — reference
+
+## Organising schemes
+
+Pick one per level. Name it in the spec.
+
+| Scheme | Groups by | Works when | Breaks when |
+|---|---|---|---|
+| Task | What the user is trying to do ("Get paid", "Hire") | Products people use to get jobs done | Tasks overlap heavily, or the content is mostly reference |
+| Topic / subject | What the content is about ("Taxes", "Benefits") | Help centres, knowledge bases, content sites | Topics are org terms users don't share |
+| Audience | Who it's for ("For employers", "For employees") | Audiences need almost entirely different content | Most content serves several audiences; users can't tell which bucket they're in |
+| Object | The thing being managed ("Invoices", "People", "Projects") | Tools where users manage records | Users think in tasks that span objects |
+| Exact (alphabetical, chronological, geographic) | A known ordering | Users already know the item name, date or place | Users are browsing, not looking up |
+
+Mixed schemes at one level ("Products / Developers / Pricing / Help") make users guess which axis to try first. If you must mix, put the odd one in utility nav or a footer.
+
+## Card sorting — when the grouping or labels are unproven
+
+- **Open sort:** participants group cards and name the groups. Use it to learn users' categories and words. Output: common groupings, the labels participants wrote, cards with no agreed home.
+- **Closed sort:** participants place cards into groups you name. Use it to check whether proposed groups are understood.
+- **Hybrid:** proposed groups, but participants may add their own. A sensible default for a redesign.
+- **Cards:** 30–60 items from the inventory, written in plain words, not the current labels.
+- **Participants:** a common rule of thumb is around 15 per distinct audience for an open sort; more for closed sorts if you want to compare percentages.
+- **Read the results:** look at agreement on which cards go together, and at the cards that split across groups. Split cards are the findability risks.
+
+## Tree testing — when the structure exists and needs proving
+
+A tree test shows participants the text-only hierarchy (no visual design) and asks them where they would go to complete a task.
+
+- **Tasks:** 6–10, written as goals in the user's situation. Never use the label words. Cover the top tasks and the riskiest items from the findability table.
+- **Each task records:** the correct destination(s), and which risk it tests.
+- **Metrics:**
+  - *Success rate* — reached a correct destination.
+  - *Directness* — got there without backtracking.
+  - *First click* — the first top-level choice. A wrong first click predicts failure.
+  - *Time* — secondary; use it to compare versions.
+- **Thresholds (set before running):** a common starting point is 70%+ success for top tasks and 80%+ correct first click; set your own and write it down before seeing results.
+- **Participants:** tree tests are usually run unmoderated with a larger sample than card sorts (often 50 or more) so per-task percentages are stable.
+- **Decision rule:** name what changes if a task fails — rename the label, move the item, add a cross-link — before you run it.
+
+## Label tests
+
+A label passes when:
+- a user would say or type it (check search logs and support tickets if available);
+- it is distinct from its siblings (no two labels a user could confuse);
+- it predicts what's inside (no surprise on click);
+- it is short enough for the nav slot (aim for 1–3 words in global nav);
+- it is consistent with the terminology list, if `ux-writing` has produced one.
+
+## Depth and breadth
+
+- Broad and shallow beats narrow and deep for things people use often; each extra level is another chance to choose wrong.
+- Fewer than 3 or more than ~10 children in a group is a signal to merge or split.
+- The global nav limit of 5–7 is a working default for scannability, not a law; exceed it only with a stated reason.

skilldrop_cli/data/packs/experience-design/skills/information-architecture/templates/ia-spec.md

@@ -0,0 +1,77 @@
+# Information architecture: {product or site}
+
+**Status:** hypothesis, not yet validated · **Evidence level:** {[observational] / [analytics] / [assumption-based]}
+**Assumptions to confirm first:** {list, or "none"}
+
+## Audiences and top tasks
+
+| Audience | Top tasks (ranked) |
+|---|---|
+| {audience} | 1. {task} 2. {task} 3. {task} |
+
+## Content inventory
+
+| # | Item | Type | Audience | Status | Notes |
+|---|---|---|---|---|---|
+| 1 | {item} | {task / reference / account / legal / marketing} | {audience} | {keep / merge into # / cut / [inferred]} | {} |
+
+## Organising scheme
+
+- **Level 1:** {task / topic / audience / object} — {why}
+- **Level 2:** {scheme} — {why}
+
+## Sitemap
+
+```
+{Product}
+├── {Global item 1}
+│   ├── {Local item}
+│   └── {Local item}
+├── {Global item 2}
+└── [Utility] {Account · Help · Search}
+```
+
+```mermaid
+flowchart TD
+    root["{Product}"] --> g1["{Global item 1}"]
+    g1 --> l1["{Local item}"]
+    root --> g2["{Global item 2}"]
+    root -.-> u["Utility: {Account · Help · Search}"]
+```
+
+## Navigation model
+
+| System | Items | Where it appears |
+|---|---|---|
+| Global | {5–7 items} | Every page |
+| Local | {per global area} | {sidebar / tabs} |
+| Utility | {account, settings, help, search} | {header right / avatar menu} |
+| Cross-links | {item → also linked from} | {} |
+| Search | {role, synonyms to add} | {} |
+
+## Label rationale
+
+| Label | Holds | Why this word | Rejected alternatives | Evidence |
+|---|---|---|---|---|
+| {label} | {} | {} | {} | {[search logs] / [support tickets] / [interview] / [assumption]} |
+
+## Findability risks
+
+| Severity | Item | Why users will look elsewhere | Mitigation |
+|---|---|---|---|
+| 🟥 / 🟧 / 🟨 | {} | {} | {} |
+
+## Validation plan
+
+**Method:** {open / hybrid card sort, tree test} · **Participants:** {n per audience} · **Threshold:** {success %, first-click %}
+
+| # | Task (no label words) | Correct destination | Tests risk |
+|---|---|---|---|
+| 1 | {} | {} | {} |
+
+**What changes the design:** {result → action}
+
+## Hand-offs
+
+- {Key page} → `content-design`
+- Nav and button strings → `ux-writing`

skilldrop_cli/data/packs/experience-design/skills/service-blueprint/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: service-blueprint
+description: Build a service blueprint — per step, the evidence the customer sees, the customer's actions, frontstage staff and system actions, backstage actions, and support processes, separated by the lines of interaction, visibility and internal interaction, with fail points, wait times and owners marked — as a table plus a Mermaid diagram and the ranked fixes. Use when the user wants a service blueprint, "what happens behind the scenes when a customer does X", to find where a service breaks or stalls, or to take a journey map down to the people, systems and handoffs that deliver it.
+---
+
+# service-blueprint
+
+Shows how a service is delivered, not just how it feels. Each customer step is lined up against what staff and systems do in front of the customer, what they do out of sight, and the processes that support them. Fail points and waits are marked where they happen. Builds on `user-journey-map`, which covers one persona's frontstage experience and emotions. The hand-off is the journey map's backstage note: when a pain's cause sits behind the line of visibility, the blueprint is where it gets found. This skill maps people, roles, systems and handoffs; for the technical architecture of the systems themselves, use `architecture-diagrams`.
+
+## How to respond
+
+1. **Get the scope in one message.** Ask at most 2 questions, spent on the weakest of: *which service and which scenario* (one customer type, one path, a start and end), and *what's known about the backstage* (teams, systems, SLAs, tickets, process docs). If a `user-journey-map` exists, take its persona, stages and customer actions as the top rows instead of asking. Default to the as-is service, not the ideal one. Tag the blueprint's evidence level: `[observed]`, `[documented]`, or `[assumption-based]`.
+
+2. **Fix one scenario with clear edges.** One customer type, one path, a trigger and an end state: ✅ *"A home-insurance customer reports a burst pipe and gets paid"* — ❌ *"Claims"*. Name the happy path, and list variants (rejected claim, second visit) as separate blueprints or a note. A blueprint that tries to show every branch becomes unreadable.
+
+3. **Lay out the customer actions first**, left to right, as the columns: 6–12 steps, in the customer's words. Every other lane hangs off these steps. If a `user-journey-map` was supplied, the steps sit inside its stages; keep its stage names as column groups.
+
+4. **Fill the lanes, top to bottom, for each step:**
+   - **Evidence:** what the customer sees, holds or receives (email, web page, letter, van, invoice).
+   - **Customer actions.**
+   - — *line of interaction* —
+   - **Frontstage:** what staff or self-service systems do that the customer sees or talks to (agent on the phone, the app, the technician on site).
+   - — *line of visibility* —
+   - **Backstage:** what staff and systems do out of sight to make the frontstage work (assessor reviews photos, case is routed).
+   - — *line of internal interaction* —
+   - **Support processes:** systems, third parties and internal teams that backstage depends on (policy system, payments provider, contractor network).
+   Name the **owner** (role or team, not a person) for every frontstage and backstage cell. An action with no owner is a finding.
+
+5. **Mark fail points and waits.** ⚠ **Fail point**: where the step can go wrong, with the failure, its effect on the customer, and how often if known. ⏱ **Wait**: where the customer waits, with the duration (measured, SLA, or `[estimate]`) and whether they're told how long. Handoffs between teams across a lane boundary are the usual sources of both; mark every handoff. Look especially for waits the customer can't see the reason for.
+
+6. **Trace the journey map's pains to their causes.** For each customer pain (from `user-journey-map` or the input), point to the backstage or support cell that causes it: ✅ *"Customer re-sends photos (pain) ← assessor can't see the portal uploads; they arrive by email to a shared inbox (backstage)"*. This trace is what the blueprint adds over the journey map.
+
+7. **Rank the fixes.** Score each fail point and wait by customer impact × frequency × how many steps it touches. Name the top 2–3 as fixes with an owner and the lane they change. The rest are listed, explicitly not prioritised now. Fixes are stated as outcomes: ✅ *"Assessor sees uploads within minutes"*, not *"Buy a new CRM"*.
+
+8. **Emit with [`templates/blueprint.md`](templates/blueprint.md)** in one message: scenario and evidence level, the blueprint table (lanes as rows, steps as columns, with the three lines drawn as separator rows), a Mermaid flowchart with one subgraph per lane, fail points and waits, the pain-to-cause trace, ranked fixes, and open questions. Check the Mermaid syntax before emitting. Hand-offs: a fix becomes committed work → `prd-draft`; the systems in the support lane need their technical design → `architecture-diagrams`; no journey map yet and the frontstage emotions matter → `user-journey-map` first. See [`examples/insurance-claim-blueprint.md`](examples/insurance-claim-blueprint.md).
+
+**Non-interactive runs** (subagent, CI, headless): a missing backstage becomes `[assumption]` cells with the whole blueprint tagged `[assumption-based]`, and missing wait times are `[estimate]`. If the service or scenario can't be identified from the input, emit `BLOCKED: need the service and one customer scenario`.
+
+## Useful references in this skill
+
+- [`templates/blueprint.md`](templates/blueprint.md) — the blueprint table with the three lines, Mermaid skeleton, fail-point and wait tables, pain-to-cause trace
+- [`examples/insurance-claim-blueprint.md`](examples/insurance-claim-blueprint.md) — worked example: a home-insurance claim built on a journey map, with fail points, waits and ranked fixes
+
+## Quality bar
+
+- **One scenario, one customer type**, with a trigger and an end state, named in the title.
+- **All five lanes and all three lines are present.** Evidence, customer, frontstage, backstage, support; interaction, visibility, internal interaction.
+- **Every frontstage and backstage action has an owner** (role or team), or is flagged as unowned.
+- **Every handoff across teams is marked**, and fail points ⚠ and waits ⏱ are marked where they occur, with durations or `[estimate]`.
+- **Customer pains are traced to backstage or support causes.**
+- **2–3 fixes are ranked and named**, stated as outcomes, each with an owner and the lane it changes.
+- **The table and the Mermaid diagram match**, and the Mermaid renders.
+- **Nothing is invented.** Teams, systems, SLAs and durations not in the input are tagged `[assumption]` or `[estimate]`, and the evidence level is declared at the top.
+
+## When to use this skill
+
+- ✅ "What actually happens behind the scenes when a customer does X?"
+- ✅ Finding where a service stalls, breaks or bounces between teams
+- ✅ Taking a journey map's pain points down to their operational causes
+- ✅ Designing a new service and agreeing who does what before launch
+
+## When NOT to use this skill
+
+- ❌ One persona's stages, emotions and pains, frontstage only — that's `user-journey-map` (run it first if the customer side isn't known)
+- ❌ The technical architecture of the systems in the support lane — that's `architecture-diagrams`
+- ❌ Requirements for a fix the blueprint found — that's `prd-draft`
+
+## Anti-patterns to avoid
+
+- ❌ **The everything blueprint.** Every branch and exception on one page. One scenario per blueprint; variants get their own.
+- ❌ **Departments instead of actions.** A backstage cell that says "Claims team" says who, not what. Write the action and the owner.
+- ❌ **No line of visibility.** Without it, nobody can see which delays the customer feels but can't explain.
+- ❌ **Waits without numbers.** "Customer waits for assessment" hides whether it's an hour or three weeks. Give a figure or an `[estimate]`.
+- ❌ **The ideal process, drawn as the current one.** Copying the process doc instead of what happens. Tag the evidence level honestly.
+- ❌ **A tool as the fix.** "Implement a new CRM" isn't an outcome. Say what must be true for the customer.
+- ❌ **Redoing the journey map.** Emotion scores belong in `user-journey-map`; the blueprint takes its steps and goes down, not sideways.

skilldrop_cli/data/packs/experience-design/skills/service-blueprint/evals/eval_queries.json

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Create a service blueprint for our returns process",
+    "should_trigger": true
+  },
+  {
+    "query": "What happens behind the scenes when a customer reports a fault? Show frontstage, backstage and where it breaks",
+    "should_trigger": true
+  },
+  {
+    "query": "Take our onboarding journey map and show the teams, systems and handoffs behind each step",
+    "should_trigger": true
+  },
+  {
+    "query": "Find the fail points and wait times in how we deliver a mortgage application",
+    "should_trigger": true
+  },
+  {
+    "query": "Map our customer's onboarding journey with emotions and pain points at each stage",
+    "should_trigger": false
+  },
+  {
+    "query": "Draw the system architecture for our claims platform as a C4 diagram",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a PRD for fixing the slow refund process",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/experience-design/skills/service-blueprint/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "service-blueprint",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Blueprint Acme Broadband's home installation service for a new customer, from placing the order online to having working internet. What we know: orders go into our order system, a scheduling team books an engineer from our contractor Northwind Field Services, the router is shipped by a courier, and activation is done by the network ops team once the engineer marks the job done. Customers complain that the router arrives after the engineer visit, and that they don't know when the line will go live. Our install SLA is 10 working days.",
+      "assertions": [
+        "The title names one customer type and one scenario with a trigger and an end state",
+        "All five lanes (evidence, customer, frontstage, backstage, support) and all three lines (interaction, visibility, internal interaction) are present",
+        "Every frontstage and backstage action has an owning role or team, or is flagged as unowned",
+        "Fail points and waits are marked at the steps where they happen, with durations from the prompt or tagged [estimate]",
+        "The router-arrives-late and no-go-live-date complaints are each traced to a backstage or support cause",
+        "2–3 ranked fixes are stated as outcomes, each with an owner and the lane it changes",
+        "A Mermaid diagram with one subgraph per lane matches the table",
+        "Does not invent teams, systems, SLAs or durations not in the prompt; inferred ones are tagged [assumption] or [estimate]"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/experience-design/skills/service-blueprint/examples/insurance-claim-blueprint.md

@@ -0,0 +1,107 @@
+# Worked example — a home-insurance claim, from burst pipe to payment
+
+## Input given to the skill
+
+> We did a journey map for Northwind Insurance's home claims. The two worst moments were "uploads
+> photos, then gets asked for the same photos again by phone" and "waits with no update after the
+> assessor visit". Can you blueprint what happens behind that? What we know: customers report on
+> the app or by phone to the contact centre. Claims go into ClaimDesk (our claims system). A desk
+> assessor reviews the claim and decides whether to send a field assessor; field assessors are a
+> third-party firm, Acme Loss Adjusting, who email their report back. Photos uploaded in the app
+> land in a shared inbox, not in ClaimDesk. Payment goes through the finance team in a weekly batch.
+> Our SLA is to contact the customer within 2 working days of the claim.
+
+## Output
+
+# Service blueprint: home-insurance customer claims for a burst pipe, from reporting it to being paid
+
+**Evidence level:** [documented], from the team's description and the journey map. Durations without an SLA are `[estimate]`.
+**Built on:** Northwind home claims journey map (the two pains above).
+**Variants not shown:** claim declined; emergency repair needed first; customer reports by phone (it differs at steps 1–2 only).
+**Assumptions to confirm first:** desk assessors work only in ClaimDesk and don't watch the shared inbox; Acme's report arrives as a PDF attached to an email.
+
+### Blueprint
+
+| Lane | 1. Reports the claim | 2. Uploads photos | 3. Gets a call from the desk assessor | 4. Hosts the field assessor | 5. Waits for a decision | 6. Gets paid |
+|---|---|---|---|---|---|---|
+| **Evidence** | App claim form, confirmation email with claim number | "Photos received" screen | Phone call | Assessor visit, business card | Nothing | Settlement email, bank credit |
+| **Customer actions** | Fills in the claim form in the app | Uploads 6–10 photos | Answers questions, is asked for photos again | Shows the damage | Chases by phone | Checks the amount |
+| *— line of interaction —* | | | | | | |
+| **Frontstage** (owner) | App submits the claim (digital team) | App confirms upload (digital team) | Calls the customer (desk assessor) | Inspects and measures (Acme field assessor) | Takes the chase call, can't see status (contact centre) | Sends settlement email (claims) |
+| *— line of visibility —* | | | | | | |
+| **Backstage** (owner) | Claim created in ClaimDesk (automated) | Photos go to the shared inbox (no owner) | Reviews the claim in ClaimDesk, can't see photos, decides on field visit (desk assessor) | Writes the report, emails it to the shared inbox (Acme) | Report waits in the inbox, then is attached by hand to ClaimDesk; desk assessor decides (desk assessor, claims admin) | Approves payment and adds it to the weekly batch (finance) |
+| *— line of internal interaction —* | | | | | | |
+| **Support processes** | ClaimDesk | Shared email inbox | ClaimDesk, policy system | Acme Loss Adjusting | Shared email inbox, ClaimDesk | Weekly payment batch |
+| **Fail points / waits** | | ⚠1 photos not linked to the claim | ⏱2 up to 2 working days (SLA) · ⚠3 asks for photos again | ⏱4 visit booking `[estimate]` 3–5 days | ⏱5 report to decision `[estimate]` 5–10 days · ⚠6 report sits unseen | ⏱7 up to 7 days for the batch |
+
+### Diagram
+
+```mermaid
+flowchart LR
+    subgraph EV["Evidence"]
+        direction LR
+        e1["Confirmation email"] ~~~ e2["Photos received screen"] ~~~ e3["Phone call"] ~~~ e4["Assessor visit"] ~~~ e5["Nothing"] ~~~ e6["Settlement email"]
+    end
+    subgraph CU["Customer actions"]
+        direction LR
+        c1["1. Reports claim"] --> c2["2. Uploads photos"] --> c3["3. Call from desk assessor"] --> c4["4. Hosts field assessor"] --> c5["5. Waits and chases"] --> c6["6. Gets paid"]
+    end
+    subgraph FR["Frontstage, below the line of interaction"]
+        direction LR
+        f1["App submits claim"] ~~~ f2["App confirms upload"] ~~~ f3["Desk assessor calls"] ~~~ f4["Acme inspects"] ~~~ f5["Contact centre takes chase call"] ~~~ f6["Claims sends settlement"]
+    end
+    subgraph BA["Backstage, below the line of visibility"]
+        direction LR
+        b1["Claim created in ClaimDesk"] ~~~ b2["Photos to shared inbox ⚠1"] ~~~ b3["Desk review, no photos ⚠3"] ~~~ b4["Acme emails report"] ~~~ b5["Report attached by hand ⚠6"] ~~~ b6["Finance weekly batch ⏱7"]
+    end
+    subgraph SU["Support, below the line of internal interaction"]
+        direction LR
+        s1["ClaimDesk"] ~~~ s2["Shared inbox"] ~~~ s3["Policy system"] ~~~ s4["Acme Loss Adjusting"] ~~~ s6["Payment batch"]
+    end
+    c1 --> f1 --> b1 --> s1
+    c2 --> f2 --> b2 --> s2
+    c3 --> f3 --> b3
+    b3 --> s3
+    c4 --> f4 --> b4 --> s4
+    c5 --> f5
+    b4 --> b5 --> s1
+    c6 --> f6
+    b6 --> s6
+```
+
+### Fail points and waits
+
+| # | Step | Type | What happens | Customer effect | Frequency / duration | Handoff? |
+|---|---|---|---|---|---|---|
+| 1 | 2 | ⚠ fail | Photos land in a shared inbox, not on the claim | Their upload goes nowhere useful | Every app claim `[assumption]` | App → inbox (no owner) |
+| 2 | 3 | ⏱ wait | Time to first contact | Doesn't know if the claim was received by a person | Up to 2 working days (SLA) | ClaimDesk → desk assessor |
+| 3 | 3 | ⚠ fail | Desk assessor can't see the photos and asks for them again | Journey-map pain 1 | Every app claim `[assumption]` | |
+| 4 | 4 | ⏱ wait | Booking the field visit | Waits with damage unrepaired | 3–5 days `[estimate]` | Desk assessor → Acme |
+| 5 | 5 | ⏱ wait | Report to decision | Journey-map pain 2: no update | 5–10 days `[estimate]` | Acme → inbox → claims admin → desk assessor |
+| 6 | 5 | ⚠ fail | Report sits in the shared inbox until someone attaches it | Longer wait, chase calls | Unknown | Acme → inbox (no owner) |
+| 7 | 6 | ⏱ wait | Approved payment waits for the weekly batch | Paid up to a week after approval | Up to 7 days | Claims → finance |
+
+### Pain → cause
+
+| Customer pain (journey map) | Cause (lane, step) |
+|---|---|
+| Asked for the same photos again | Backstage 2: uploads go to an unowned shared inbox; backstage 3: desk assessor works only in ClaimDesk |
+| No update after the assessor visit | Backstage 5: Acme's report goes to the same inbox and waits to be attached by hand; frontstage 5: contact centre can't see status, so chase calls go nowhere |
+
+### Ranked fixes
+
+| Rank | Fix (outcome) | Lane it changes | Owner | Addresses |
+|---|---|---|---|---|
+| 1 | Photos uploaded in the app appear on the claim in ClaimDesk, with no inbox step | Backstage, support | Digital team with claims | ⚠1, ⚠3 |
+| 2 | Acme's report reaches the claim directly, and the customer is told when it has arrived and when to expect a decision | Backstage, frontstage | Claims, with Acme | ⚠6, ⏱5 |
+| 3 | The contact centre can see claim status, so a chase call ends with an answer | Frontstage | Contact centre | ⏱5 |
+
+**Not prioritised now:** ⏱7 weekly payment batch (a finance process change with wider impact; revisit after fixes 1–2); ⏱2 first-contact SLA (met today, and fix 1 makes the first call shorter).
+
+### Open questions
+
+- How many claims a month arrive through the app vs by phone? This sizes fix 1.
+- What does Acme's contract say about report turnaround? It may already have an SLA nobody tracks.
+- Who owns the shared inbox today? The blueprint found no owner.
+
+**Hand-offs:** fix 1 becomes committed work → `prd-draft`. The ClaimDesk integration design → `architecture-diagrams`.

skilldrop_cli/data/packs/experience-design/skills/service-blueprint/manifest.json

@@ -0,0 +1,45 @@
+{
+  "name": "service-blueprint",
+  "version": "0.1.0",
+  "description": "Build a service blueprint — per step, the evidence the customer sees, the customer's actions, frontstage staff and system actions, backstage actions, and support processes, separated by the lines of interaction, visibility and internal interaction, with fail points, wait times and owners marked — as a table plus a Mermaid diagram and the ranked fixes. Use when the user wants a service blueprint, \"what happens behind the scenes when a customer does X\", to find where a service breaks or stalls, or to take a journey map down to the people, systems and handoffs that deliver it.",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "architecture-diagrams",
+    "prd-draft",
+    "user-journey-map"
+  ],
+  "handoff": [
+    {
+      "to": "user-journey-map",
+      "when": "there is no journey map and the customer's stages and emotions aren't known",
+      "purpose": "Establish the frontstage experience the blueprint hangs off.",
+      "fallback": "If user-journey-map is absent, list the customer steps and the two worst moments inline, tagged [assumption], before filling the lanes."
+    },
+    {
+      "to": "prd-draft",
+      "when": "a ranked fix is accepted as committed work",
+      "purpose": "Turn the fix into requirements with goals and non-goals.",
+      "fallback": "If prd-draft is absent, write the fix as a problem statement, the owner, and one measurable 'we'll know it worked when' line."
+    }
+  ],
+  "tags": [
+    "service-design",
+    "service-blueprint",
+    "cx",
+    "operations",
+    "ux",
+    "mermaid"
+  ],
+  "model": {
+    "tier": "standard",
+    "rationale": "Structured mapping of a described service into fixed lanes, with fail points, waits and a ranking. Tracing causes needs judgment, but the lane structure and the input bound it."
+  }
+}

skilldrop_cli/data/packs/experience-design/skills/service-blueprint/templates/blueprint.md

@@ -0,0 +1,72 @@
+# Service blueprint: {customer type} {does what}, from {trigger} to {end state}
+
+**Evidence level:** {[observed] / [documented] / [assumption-based]} · **Built on:** {user-journey-map title, or "no journey map"}
+**Variants not shown:** {list} · **Assumptions to confirm first:** {list, or "none"}
+
+## Blueprint
+
+| Lane | 1. {step} | 2. {step} | 3. {step} |
+|---|---|---|---|
+| **Evidence** | {} | {} | {} |
+| **Customer actions** | {} | {} | {} |
+| *— line of interaction —* | | | |
+| **Frontstage** (owner) | {action} ({role}) | | |
+| *— line of visibility —* | | | |
+| **Backstage** (owner) | {action} ({team}) | | |
+| *— line of internal interaction —* | | | |
+| **Support processes** | {system / third party} | | |
+| **Fail points / waits** | ⚠ {} · ⏱ {duration} | | |
+
+## Diagram
+
+```mermaid
+flowchart LR
+    subgraph EV["Evidence"]
+        direction LR
+        e1["{evidence}"]
+    end
+    subgraph CU["Customer actions"]
+        direction LR
+        c1["1. {step}"] --> c2["2. {step}"]
+    end
+    subgraph FR["Frontstage (line of interaction above)"]
+        direction LR
+        f1["{action}"]
+    end
+    subgraph BA["Backstage (line of visibility above)"]
+        direction LR
+        b1["{action}"]
+    end
+    subgraph SU["Support (line of internal interaction above)"]
+        direction LR
+        s1["{system}"]
+    end
+    c1 --- e1
+    c1 --> f1
+    f1 --> b1
+    b1 --> s1
+```
+
+## Fail points and waits
+
+| # | Step | Type | What happens | Customer effect | Frequency / duration | Handoff? |
+|---|---|---|---|---|---|---|
+| 1 | {} | ⚠ fail / ⏱ wait | {} | {} | {measured / SLA / [estimate]} | {team → team} |
+
+## Pain → cause
+
+| Customer pain | Cause (lane, step) |
+|---|---|
+| {} | {} |
+
+## Ranked fixes
+
+| Rank | Fix (outcome) | Lane it changes | Owner | Addresses |
+|---|---|---|---|---|
+| 1 | {} | {} | {} | {#} |
+
+**Not prioritised now:** {list}
+
+## Open questions
+
+- {}

skilldrop_cli/data/packs/experience-design/skills/ux-writing/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: ux-writing
+description: Write the interface copy for a flow or component — buttons, labels, hints, errors, empty states, confirmations, loading and success messages — as a string table where each string has its context, a character budget, a recommended version and one variant, with error messages that say what happened and what to do next, and a terminology list so the same thing has the same name everywhere. Use when the user wants UI copy, microcopy, button text, error messages, empty states, "write the strings for this screen", or "our wording is inconsistent".
+---
+
+# ux-writing
+
+Writes the short strings people read while they are in the middle of doing something. The unit is the string, and each one is written for its exact slot: the button, the field hint, the error under the field, the empty table. The output is a string table a developer can paste from and a terminology list that keeps the product consistent. This is not `content-design`, which decides what a whole page says from user needs; ux-writing works inside a flow that already exists and fills its slots. Longer help articles and how-tos belong to `guide-builder`.
+
+## How to respond
+
+1. **Get the flow and the voice in one message.** Ask at most 2 questions, spent on the weakest of: *the flow or screens* (a screenshot, wireframe, component list, or step list), and *the voice* (a `brand.json` from `brand-kit`, a style guide, or three words). Default the voice to plain, direct, second person ("you"), sentence case, no exclamation marks. Default the platform to web. Say which defaults you used.
+
+2. **List every slot before writing any copy.** Walk the flow step by step and list each string slot: page title, labels, hints, placeholders, buttons, links, errors (one per validation rule and per system failure), empty states, loading, success, confirmation dialogs, toasts. A missing error state is the most common gap; ask what each field can reject and what the system can fail on. A slot you inferred is tagged `[inferred]`.
+
+3. **Give each slot a character budget.** Use the real width when known; otherwise default: button 20, label 30, hint 80, toast 60, dialog title 40, dialog body 160, error 100. Count characters, including spaces, and put the count next to each string. Over budget means rewrite, not truncate. Allow about 30% extra length for languages that run longer when the product is localised, and say so.
+
+4. **Write each string for its job:**
+   - **Buttons** say what happens, as a verb plus object: ✅ *"Send invite"* — ❌ *"Submit"*, *"OK"*. The confirm button in a dialog repeats the action in the title: title *"Delete this project?"*, button *"Delete project"*, not *"Yes"*.
+   - **Labels** are nouns that name the data; hints say the format or the reason we ask. Placeholder text is never the only label, because it disappears on typing.
+   - **Errors** say what happened and what to do, in that order, without blame: ✅ *"That email is already in use. Sign in instead, or use a different email."* — ❌ *"Invalid input"*, *"Error 409"*, *"You entered a wrong email"*. Name the field; give the fix; keep the user's input.
+   - **Empty states** say what will appear here and how to make it appear, with one action: ✅ *"No invoices yet. Invoices you send will show here."* + *"Create invoice"*.
+   - **Loading** says what is happening if it takes more than a moment: *"Uploading 3 of 12 files…"*, not *"Please wait"*.
+   - **Success** confirms the outcome and the next step, if there is one: *"Invite sent to sam@northwind.example"*.
+   - **Destructive confirmations** name the thing, the consequence, and whether it can be undone.
+
+5. **Write one variant per string.** The variant differs on purpose: shorter, warmer, or more explicit, labelled as such. Recommend one and say why in a few words. Variants are for review and testing, not a menu for the reader to choose from without guidance.
+
+6. **Build the terminology list.** For every concept that appears more than once (the thing being created, the people involved, the actions), pick one term and list the terms to avoid: ✅ *Use "workspace". Avoid: project, team, account.* Then check every string against it. Two names for one thing is the defect this list exists to catch; flag any existing UI or doc that already uses a banned term.
+
+7. **Check the strings for access and tone.** Link and button text makes sense out of context (no "Click here", no "Learn more" repeated five times). Errors aren't conveyed by colour alone; say in the string what's wrong. No idioms or jokes in errors. Plain words over jargon: *"sign in"* over *"authenticate"*. This is a writing check, not an accessibility audit; send the built UI to `accessibility-audit`.
+
+8. **Emit with [`templates/string-table.md`](templates/string-table.md)** in one message: voice and defaults used, the string table (ID, screen, slot, context, budget, recommended string with character count, variant, notes), the terminology list, and open questions (states nobody has defined yet, error cases that need engineering to confirm). String IDs follow `screen.slot.state` so developers can key them. Component-level content rules for a design system → `design-system-spec`. See [`examples/team-invite-flow.md`](examples/team-invite-flow.md).
+
+**Non-interactive runs** (subagent, CI, headless): missing voice falls back to the default voice with an `[assumption]` line at the top; missing error cases are written as `[inferred]` and listed as open questions. If the flow itself can't be identified (no screens, steps or component named), emit `BLOCKED: need the flow or component and its steps` and write nothing.
+
+## Useful references in this skill
+
+- [`templates/string-table.md`](templates/string-table.md) — the string table, terminology list and open-questions skeleton
+- [`examples/team-invite-flow.md`](examples/team-invite-flow.md) — worked example: a three-step invite flow, with errors, empty state and a terminology list
+
+## Quality bar
+
+- **Every slot in the flow has a string**, including each error, the empty state, loading and success. No "TBD".
+- **Every string shows its character count against its budget**, and none is over.
+- **Every error says what happened and what to do next**, names the field or object, and blames no one. No error codes on their own.
+- **Buttons are verb + object.** No "Submit", "OK" or "Yes" on a primary action.
+- **Each string has one labelled variant and a recommendation.**
+- **The terminology list exists, and every string obeys it.** One concept, one term.
+- **The voice matches the given brand or the stated default.**
+- **Nothing is invented about the product.** Limits, prices, timings and policies not in the input are left as `{placeholder}` and listed in open questions.
+
+## When to use this skill
+
+- ✅ Writing or rewriting the copy for a flow, screen or component
+- ✅ Error messages that confuse people or generate support tickets
+- ✅ Empty, loading and success states nobody has written yet
+- ✅ Wording that differs between screens and needs one terminology list
+
+## When NOT to use this skill
+
+- ❌ Deciding what a whole page or journey should say from user needs — that's `content-design`
+- ❌ A help article, setup guide or walkthrough — that's `guide-builder`
+- ❌ Capturing the brand's voice and visual identity — that's `brand-kit`
+- ❌ Checking a built UI against WCAG — that's `accessibility-audit`
+- ❌ The full component spec (states, tokens, behaviour) — that's `design-system-spec`; this skill can supply its content rules
+
+## Anti-patterns to avoid
+
+- ❌ **"Something went wrong."** Says nothing about what failed or what to do. If the cause is unknown, say what to try and how to get help.
+- ❌ **Blaming the user.** "You entered an invalid date." Write "Enter a date after today", which is the fix.
+- ❌ **"Submit", "OK", "Yes/No" on actions.** The user has to read the dialog to know what the button does.
+- ❌ **Placeholder as label.** The hint vanishes on the first keystroke, and the user forgets what the field was.
+- ❌ **Three names for one thing.** "Workspace" in the nav, "project" in the dialog, "team" in the email.
+- ❌ **Writing to the wireframe's lorem ipsum length.** The real string runs longer, the layout breaks, and someone truncates it in code.
+- ❌ **Cheerful errors.** "Oops! 🙈" on a failed payment reads as mockery.
+- ❌ **Inventing the rules.** "Passwords must be 12 characters" when nobody said so. Leave a placeholder and ask.

skilldrop_cli/data/packs/experience-design/skills/ux-writing/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write the button labels and error messages for our signup form",
+    "should_trigger": true
+  },
+  {
+    "query": "We need empty states, loading and success messages for the file upload screen",
+    "should_trigger": true
+  },
+  {
+    "query": "Our app calls the same thing a project, a board and a space — fix the microcopy and give us a terminology list",
+    "should_trigger": true
+  },
+  {
+    "query": "Rewrite these error messages so people know what to do: 'Invalid input', 'Error 500', 'Request failed'",
+    "should_trigger": true
+  },
+  {
+    "query": "Plan the content for our benefits page from user needs: what questions it answers and what to cut",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a getting-started guide for new admins setting up the product",
+    "should_trigger": false
+  },
+  {
+    "query": "Set up our brand kit from this logo and our tone-of-voice guidelines",
+    "should_trigger": false
+  },
+  {
+    "query": "Audit this checkout page for WCAG 2.2 AA issues",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/experience-design/skills/ux-writing/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "ux-writing",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the UI copy for Acme Bank's 'add a payee' flow in our mobile app. Steps: enter payee name, sort code and account number; we run a name check against the bank's records (match, close match, no match); then confirm and add. Users can also see an empty Payees list before they've added anyone. Our style guide says: plain, calm, second person, no exclamation marks.",
+      "assertions": [
+        "Every slot has a string, including an error for each field rule, each name-check result, a network failure, the empty Payees list, loading and success",
+        "Every string shows a character count against a stated budget, and no recommended string exceeds its budget",
+        "Every error says what happened and what to do next, names the field, and does not blame the user",
+        "Primary buttons are verb plus object; none says Submit, OK or Yes",
+        "Each string has one labelled variant and a recommendation",
+        "A terminology list picks one term per concept (e.g. payee vs recipient) with terms to avoid, and the strings follow it",
+        "No exclamation marks, matching the given style guide",
+        "Does not invent limits, fees, processing times or policies not in the prompt; unknowns are placeholders listed as open questions"
+      ]
+    }
+  ]
+}