[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H85D8RE4V6VT781G3EKMV3":3,"skill-same:01M6H85D8RE4V6VT781G3EKMV3":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6H85D8RE4V6VT781G3EKMV3","flow-friction-audit",null,"Drives a live web flow through a real browser, turns the run into evidence-backed friction findings, then routes them into the impeccable skill for critique and redesign. Use whenever the user wants to know where a real user gets stuck, confused or slowed down in a running flow — \"audit the signup flow\", \"where's the friction in checkout\", \"walk through onboarding and tell me what's clunky\", \"usability audit of the live app\", \"why do people drop off here\". Trigger on \"usability\", \"UX audit\", \"friction\", \"drop-off\" or \"walk the flow\" without this skill being named, and when the user only supplies a URL and asks what's wrong with the experience. Trigger before any URL or credentials exist — settling the goal, flow and environment is this skill's own first step, so ask for what's missing from inside the skill. Also use to run the design half alone from an agreed problems doc.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"audit","flow","flow friction audit","friction","only","when","playwright-cli","URL","ux audit","people","checkout","app","drop","me","design","usability","ask","Bash","critique","credentials","browser","cli","2026-11-10 10:12:30",false,"---\nname: flow-friction-audit\ndescription: >\n  Drives a live web flow through a real browser, turns the run into evidence-backed friction\n  findings, then routes them into the impeccable skill for critique and redesign. Use whenever\n  the user wants to know where a real user gets stuck, confused or slowed down in a running\n  flow — \"audit the signup flow\", \"where's the friction in checkout\", \"walk through onboarding\n  and tell me what's clunky\", \"usability audit of the live app\", \"why do people drop off here\".\n  Trigger on \"usability\", \"UX audit\", \"friction\", \"drop-off\" or \"walk the flow\" without this\n  skill being named, and when the user only supplies a URL and asks what's wrong with the\n  experience. Trigger before any URL or credentials exist — settling the goal, flow and\n  environment is this skill's own first step, so ask for what's missing from inside the skill.\n  Also use to run the design half alone from an agreed problems doc.\nallowed-tools: Bash(playwright-cli:*), Bash(od:*), Bash(odo:*)\n---\n\n# Flow Friction Audit\n\nDrive a real, running flow through the browser and turn what happens into friction evidence a designer can act on. The value is the **middle**: most UX tooling either drives a browser (no judgement) or critiques a design (no live behaviour). Do both — observe the running product, convert each interaction into named evidence, agree what those problems are, and only then shape fixes against them.\n\nEvidence and agreed problems are the load-bearing output; they stand on their own even if nothing is designed. `impeccable` owns the critique and sharpens the directions — it doesn't decide what's wrong.\n\n## Two modes, one skill\n\nThe pipeline splits at the 3b alignment gate, and each half is invoked separately. Running all five stages in one pass makes a single audit expensive, and it leaves the agreed problem space living only in that conversation — so the next run re-derives what's wrong instead of designing against it.\n\n- **`audit` — stages 1 to 4.** Walk the flow, score it, agree the problems, write the alignment doc and `findings.md`. Ends at alignment; no design work.\n- **`shape` — stage 5.** Take an already-aligned problem set and produce researched fix directions. Re-runnable: the problem space is settled, so each invocation spends its budget on ideas rather than rediscovering the friction.\n\n**Route on entry:** the user points at or names an aligned-problems doc → `shape`. Otherwise → `audit`, from stage 1. **Never go looking for a doc the user didn't name** — auto-discovery is the same mistake as reading a prior audit ([Fresh runs](#fresh-runs)): it quietly makes someone else's stale problem set the frame for a flow you haven't looked at yet.\n\n## Prerequisites\n\n- **A browser driver** — required in `audit` mode, irrelevant in `shape`. Default to `playwright-cli`; behind enterprise SSO, drive the user's authenticated Chrome session with `claude-in-chrome` (stage 1b). If neither is available, stop and say so rather than improvising.\n- **the `playwright-cli` skill** — optional. Defer to it for command syntax rather than reinventing flags here.\n- **Open Design (`od`\u002F`odo`)** — optional; `shape` mode's wireframe renderer. If it's absent or the renderer is unavailable, fall back to ASCII and say so — never hard-fail an audit for a missing design tool. [references\u002Fopen-design.md](references\u002Fopen-design.md).\n\n## The pipeline\n\nFive stages, hinged on the human gate at 3b. Don't skip scope to \"just start clicking\" — an unscoped walk produces observations nobody can prioritise. Don't skip the gate to get to the designs; that's the more expensive mistake.\n\n### 1. Scope\n\nSettle three things before opening a browser (ask only for what you can't infer):\n\n- **The goal.** *Friction discovery* (where does anyone get stuck?), *conversion* (where do people drop before the key action?), or *concept validation* (is the core idea legible?). The goal decides what counts — a slow-but-clear step is a finding for conversion, noise for concept validation.\n- **One flow.** A flow can span several screens; auditing 3–5 flows at once cannot. This skill is precise and re-invoked per scenario, not run as a sprawling sweep.\n- **An explicit URL**, plus credentials and test data. The URL must come from the user — **never infer it, never default to `localhost`, never start a dev server.** Environments differ in seeded data, feature flags and auth, so a guessed URL silently audits the wrong product. If none was given, ask before anything else.\n\n**Start from nothing** — don't go looking for previous audits of this flow, and don't read one you happen to know about ([Fresh runs](#fresh-runs)). Then state the scope back in a line or two and start.\n\n### 1b. Auth precondition\n\nConfirm the app is authenticated before driving — a walk that starts logged-out audits the login screen instead of the flow. Open the URL, `snapshot`, and check the target UI rendered rather than a sign-in page or a stuck loading overlay.\n\n**Never automate the login.** Google and friends block automated sign-in (CAPTCHA, 2FA, bot detection), so scripting it is flaky and burns the run. If the flow can't continue, stop and ask the user to log in manually in the open session, then resume. One session runs the whole audit (stage 2), so a single manual login carries through every step.\n\n**Behind enterprise SSO**, a fresh `playwright-cli` profile can't get past at all — no cookies, no device trust, and manual login in a throwaway profile is often blocked outright. Drive the user's already-authenticated browser with `claude-in-chrome` instead; everything downstream is unchanged. Record the driver in `findings.md` — evidence from a live account has different provenance than a clean profile.\n\nA logged-out app shows a sign-in page or a stuck loading overlay in the `snapshot`, never the app content; treat either as unauthenticated.\n\n### 2. Drive\n\nAttach to the user's running browser at the stage-1 URL rather than launching a fresh profile — the running session carries the auth and app state a real user arrives with. Keep that one session for the whole walk; close it once, at the end of stage 4, since `shape` never drives.\n\nWork from snapshot element refs, never hand-rolled selectors: `snapshot` to read the page, act on refs like `e15`, re-`snapshot` after anything that changes it. **Don't persist screenshots** — the step log below is the evidence record, and images cost more context than they return. Prefer `read_page`\u002F`get_page_text` for structure; screenshot only to see something a text read can't show, and discard it after.\n\n**Mutating live state.** **Never** act in a way that notifies a third party or spends money — invites, outbound mail, OAuth grants, anything billable. **Freely** take genuinely reversible UI-state actions (expand, dismiss, open a composer you don't submit); no need to ask. Where only an irreversible action would answer a question, answer it from source instead (3a) — and name the steps you never exercised in the report, so a reader can tell an observed claim from an inferred one.\n\n**Walk one step at a time, logging each as a triple:**\n\n```\nelement (ref + label) → expected outcome → actual outcome\n```\n\nThe gap between expected and actual is where much of the friction lives:\n\n- **Mismatch** (actual ≠ expected) → confusion. The label promised one thing, the app did another.\n- **Retry** (you acted more than once, or hunted for the right element) → \"wait, how do I…\".\n- **Long wait \u002F no feedback** → invisible system status.\n- **Dead end** (expected a next step, got nothing) → the flow breaks here.\n\nThe triple is one lens, not the whole game — a step can do exactly what its label promised and still overload. So at every step also ask \"would a first-time user know where to start?\" and \"is everything needed to decide visible right now?\" — the *recognition-over-recall* and *aesthetic\u002Fminimalist* questions the rubric scores, and the friction automated walks miss most.\n\nRecord the wait qualitatively (instant \u002F a beat \u002F had-to-wait \u002F stalled) — which steps made you wait without telling you why.\n\n**Audit intended behaviour, not defects.** A design finding is one where the product worked as built and still failed the user. Browser automation is janky by nature, so an anomaly (dead click, error banner, blank region) is a signal to re-test on a fresh load, never a result. Reproduces identically → may be design; score it. Intermittent or gone on retry → a bug; mention it to the user in conversation and stop there.\n\n**Defects never enter the report** — not as a finding, not as evidence inside one, and not as an out-of-scope section. A defect list beside the findings competes for attention and sends `impeccable` designing around something someone should just fix.\n\n### 3. Score\n\nTurn the step log into **named findings** with the timed rubric in [references\u002Frubric.md](references\u002Frubric.md) — read it now. It converts Nielsen's heuristics into concrete questions (\"was the result visible within ~1s?\") so a finding is a rubric failure with evidence attached, not a vibe.\n\nTwo heuristics earn extra weight, being the ones automated walks surface best and teams miss most: **user control & freedom** — watch every point where you felt trapped with no undo, cancel or way back — and **recognition rather than recall** — watch every point where you had to hold something in your head instead of reading it off the screen.\n\nWork at the **micro level**: one interaction (\"the email field only errors after submit\"), not a whole-flow grade (\"signup is confusing\"). Whole-flow verdicts can't be fixed or re-tested; micro findings can.\n\nGive every finding a **stable, descriptive ID** — `\u003Cflow>-\u003Cwhat>`, e.g. `signup-email-late-validation` — describing the friction, not its position. Never bare sequence numbers. **Every finding cites its evidence:** the step-log row number(s) it rests on, plus `file:line` for anything read from source. A claim a reader can't trace isn't a finding.\n\nThen **synthesise the findings into 2–4 named problems.** A finding is an observation; a problem is what a cluster of them *means* — \"arrival is empty of purpose\", not ten separate complaints about one screen. **Each finding belongs to exactly one problem.** If a finding seems to belong to three, the problems aren't yet distinct — re-cluster until each owns its own evidence. Problems are what gets designed against; findings are what prove them.\n\n### 3a. Corroborate against source\n\nWhen the audited product's source is available, read the components behind each finding before scoring is final. It turns \"the progress bar never moved\" into \"the criterion measures threads, not connected channels\", and answers questions that would otherwise need a live mutation. **State no claim the code doesn't support** — if a criterion ticks under some condition you didn't hit, name that condition rather than rounding it up to \"never\".\n\n### 3b. Align the problems with the user\n\n**Stop and get agreement before spending anything downstream.** Stages 2 and 3 run **blind** — a steered walk finds the friction the user already suspected and misses the rest — so this gate is the first point of human input, after the evidence exists and before any design work does.\n\nAlign **on a document, not in chat.** Write the problems to `alignment.md` in the run's artifacts directory (stage 4) and iterate there: a settled problem space is worth more than an agreement one person remembers — the team reads the same statement of what's wrong, and `shape` re-enters from it as many times as the ideas need reworking.\n\nThe page carries a descriptive title, the flow's goal with an honest assessment of how well the flow serves it, and a `## problems` list — things to solve outright or areas to mitigate. **No solution ideas on this page.** An idea smuggled in as a problem gets agreed by proxy and quietly becomes the only direction anyone designs.\n\nTemplate, the questions to ask while aligning, and the bounded re-entry context the page must carry: [references\u002Falignment-doc.md](references\u002Falignment-doc.md).\n\n**Allocate the design budget here too.** The problems are rarely peers — one is often the mechanism behind another — so ask which get design work and which is load-bearing, before any research runs. The user already holds that answer, and stage 5 is far too late to learn it. Weigh it against the team's current goal metrics, asked for at this gate and never before the walk ([references\u002Falignment-doc.md](references\u002Falignment-doc.md)).\n\nRevise until the user agrees, then carry the aligned problems into stage 4. Everything after this — critique, research, fix directions, wireframes — is expensive and shaped entirely by this list.\n\n### 4. Report\n\nOne artifacts directory per run: **`\u003Caudited-repo>\u002F.claude\u002Ffriction-audit\u002F\u003Cflow>-\u003CYYYYMMDD>\u002F`** — the repo of the product you audited, not wherever you were invoked from. An audit belongs next to its product. It holds `findings.md`, `alignment.md` and the wireframe HTML; no screenshots, and no throwaway scripts you used to generate them.\n\n**Two files, one link each.** `alignment.md` owns the summary and the problems — the product layer the team aligns on. `findings.md` owns the evidence, and later the critique and fix directions. Link each to the other exactly once rather than restating either inside the other.\n\nWrite `findings.md` with [assets\u002Ffindings-template.md](assets\u002Ffindings-template.md), which fixes the section order. Two rules that order enforces: **lead with a summary** (goal, flow, driver, one-paragraph verdict, the problems as bullets, headline counts) so a reader gets the story in thirty seconds; and **problems before findings**, each citing its IDs, with the findings as the layer that proves them and the step log after. State the conclusion, then show the work — and state it **once**, so no restatement drifts out of sync.\n\n### 5. Shape the fix directions (`shape` mode)\n\nEntered with an aligned problem set — straight from 3b, or from a doc the user named. Read the doc and its re-entry context and take the problems as given; re-deriving them here throws away the agreement they represent. Close the browser first if this run drove one.\n\n- **Critique:** invoke `impeccable` in `critique` mode against the audited surface with `findings.md` as evidence, so its review is grounded in observed behaviour rather than a static read. **Fold what comes back into `findings.md`** — score, specificity verdict and P0s as a `## Critique` section. A critique in a separate file gets read separately or not at all; the point is that its emphasis visibly drives the directions.\n- **One research-and-ideation agent per problem** — the fan-out unit; each agent owns a single problem end to end.\n  - **Research the precedent.** How well-regarded products solve that problem, with **at least one primary source** (the product's own docs, changelog, release notes, or a first-hand teardown), naming the specific surface examined. Aggregator listicles find candidates but are never a citation, and **no statistic without a primary source** — a vendor's conversion claim is marketing until you can point at where it's measured. Two or three worked examples beat a survey.\n  - **Then ideate against it.** **Three divergent ideas argued in prose**, each naming the problem and the critique point it answers, plus **the signal that would show it worked** — a direction with no observable outcome is a proposal, not something a team can ship and check. Three is the *generation* target, not the output contract; the gate below decides what survives. Route them through `impeccable` in `shape` mode to sharpen.\n- **Converge before anything is drawn.** With every problem's ideas sharpened, read them all against each other in one pass and take that read to the user: which theses collapse into one, what composes and what's mutually exclusive, and a recommended bundle in ship order — ship now \u002F this quarter \u002F rewrite — from the directions' own cost notes. One field is required rather than lucky: **the cheapest change that repairs the walked blocker, even when it is none of the directions.** Keep sharpening *before* this gate — `impeccable`'s corrections are often what decide whether a direction is viable, which is exactly what the gate needs to choose on. Then ask what gets wireframed; the count is an output of that answer, so one problem may carry four frames and another one. Draw to a fixed quota instead and the run discovers its own duplicates only after paying to research, argue and draw them.\n- **Wireframes illustrate ideas; they never produce them.** Draw only **what the gate selected**, and only once the ideas exist as prose, grounded in the surface's current code. The test: **if an idea can't be written as a paragraph before it's drawn, it isn't an idea yet.** Sketch first and you end up reading the rationale off your own drawings, with justifications retrofitted onto them. Fidelity and framing: [references\u002Fwireframe-style.md](references\u002Fwireframe-style.md), read before drawing. Render mechanics and the fallback: [references\u002Fopen-design.md](references\u002Fopen-design.md).\n- **Close with the trail:** end `findings.md` with `## Inspiration — where to look next` — per problem, the products worth studying and one line on what each does right. The research is worth more as a trail the user can follow than as a citation buried in a fix direction.\n\nReport what you handed off and what came back, and end on the gate's recommendation — an unranked menu of alternatives is a stall for a team working in weeks. Don't editorialise a second critique on top; recommending a bundle isn't re-arguing `impeccable`'s verdict.\n\n## Execution shape\n\nStages 2 and 3 stay one context, one session, serial — each step informs the next, and the 3b gate needs one context holding the whole evidence set. The rest is fan-out shaped:\n\n- **3a corroboration and the stage-5 research agents** — independent per file and per problem, so run them as parallel subagents. Serial shallow searches are what produce listicle-grade precedent.\n- **`impeccable critique`'s two assessments** — isolation is a *correctness* requirement here, not a speed-up: run inline and the critique has already absorbed your findings, so its agreement proves nothing. If subagents are unavailable, say so in the report and state that agreement is not corroboration.\n- **Wireframe authoring** — single-context. One shared style pass beats the same fix made four times.\n\nYou stay the synthesis point; subagents return evidence, not conclusions.\n\n**Match the model to the work.** An all-Opus run costs several times a tiered one and buys nothing on the mechanical stages, so spend the expensive model only where judgement actually happens:\n\n- **Sonnet** — 3a source corroboration, precedent gathering, and wireframe authoring and rendering. These are read-heavy and style-constrained; the reference files already carry the judgement.\n- **Opus** — scoring and clustering (stage 3), each problem's idea synthesis, the convergence read, and `impeccable critique`. Deciding what a cluster of findings *means*, what collapses into what, and what to build instead is the part that degrades when you economise.\n\n## Fresh runs\n\n**Every invocation starts clean.** Don't search for prior `friction-audit` directories, don't read one you know exists, don't present cached findings as current. Old evidence goes stale, and a prior run's fix directions quietly become the ceiling on the new ones — the second audit reproduces the first instead of seeing the flow again. Compare across runs **only when the user asks**; then diff by finding ID (gone is fixed, surviving isn't, new is a regression) and say which prior IDs you couldn't re-test.\n\nAn alignment doc the user hands you in `shape` mode isn't an exception to this — they named it, so it's their current problem set, not a cached one you went looking for.\n\n## Scope boundaries\n\n- **You don't own the critique** — `impeccable` does, and its verdict gets folded in rather than argued with. Ideation is shared: the per-problem research agents form the ideas, `impeccable` sharpens them.\n- **You don't decide the problems alone** — the 3b gate does, with the user. A problem set you never got agreed is a guess with a document around it.\n- **You don't hunt bugs** — defects and automation artifacts never reach the report (stage 2). A broken thing needs fixing, not redesigning.\n- **You don't write tests** — the walk is throwaway observation. Regression tests are `playwright-cli`'s job.\n- **You don't do participant recruiting, fidelity ladders, video, or network mocking** — one agent, one live flow.\n","# Flow Friction Audit\n\nDrive a real, running flow through the browser and turn what happens into friction evidence a designer can act on. The value is the **middle**: most UX tooling either drives a browser (no judgement) or critiques a design (no live behaviour). Do both — observe the running product, convert each interaction into named evidence, agree what those problems are, and only then shape fixes against them.\n\nEvidence and agreed problems are the load-bearing output; they stand on their own even if nothing is designed. `impeccable` owns the critique and sharpens the directions — it doesn't decide what's wrong.\n\n## Two modes, one skill\n\nThe pipeline splits at the 3b alignment gate, and each half is invoked separately. Running all five stages in one pass makes a single audit expensive, and it leaves the agreed problem space living only in that conversation — so the next run re-derives what's wrong instead of designing against it.\n\n- **`audit` — stages 1 to 4.** Walk the flow, score it, agree the problems, write the alignment doc and `findings.md`. Ends at alignment; no design work.\n- **`shape` — stage 5.** Take an already-aligned problem set and produce researched fix directions. Re-runnable: the problem space is settled, so each invocation spends its budget on ideas rather than rediscovering the friction.\n\n**Route on entry:** the user points at or names an aligned-problems doc → `shape`. Otherwise → `audit`, from stage 1. **Never go looking for a doc the user didn't name** — auto-discovery is the same mistake as reading a prior audit ([Fresh runs](#fresh-runs)): it quietly makes someone else's stale problem set the frame for a flow you haven't looked at yet.\n\n## Prerequisites\n\n- **A browser driver** — required in `audit` mode, irrelevant in `shape`. Default to `playwright-cli`; behind enterprise SSO, drive the user's authenticated Chrome session with `claude-in-chrome` (stage 1b). If neither is available, stop and say so rather than improvising.\n- **the `playwright-cli` skill** — optional. Defer to it for command syntax rather than reinventing flags here.\n- **Open Design (`od`\u002F`odo`)** — optional; `shape` mode's wireframe renderer. If it's absent or the renderer is unavailable, fall back to ASCII and say so — never hard-fail an audit for a missing design tool. [references\u002Fopen-design.md](references\u002Fopen-design.md).\n\n## The pipeline\n\nFive stages, hinged on the human gate at 3b. Don't skip scope to \"just start clicking\" — an unscoped walk produces observations nobody can prioritise. Don't skip the gate to get to the designs; that's the more expensive mistake.\n\n### 1. Scope\n\nSettle three things before opening a browser (ask only for what you can't infer):\n\n- **The goal.** *Friction discovery* (where does anyone get stuck?), *conversion* (where do people drop before the key action?), or *concept validation* (is the core idea legible?). The goal decides what counts — a slow-but-clear step is a finding for conversion, noise for concept validation.\n- **One flow.** A flow can span several screens; auditing 3–5 flows at once cannot. This skill is precise and re-invoked per scenario, not run as a sprawling sweep.\n- **An explicit URL**, plus credentials and test data. The URL must come from the user — **never infer it, never default to `localhost`, never start a dev server.** Environments differ in seeded data, feature flags and auth, so a guessed URL silently audits the wrong product. If none was given, ask before anything else.\n\n**Start from nothing** — don't go looking for previous audits of this flow, and don't read one you happen to know about ([Fresh runs](#fresh-runs)). Then state the scope back in a line or two and start.\n\n### 1b. Auth precondition\n\nConfirm the app is authenticated before driving — a walk that starts logged-out audits the login screen instead of the flow. Open the URL, `snapshot`, and check the target UI rendered rather than a sign-in page or a stuck loading overlay.\n\n**Never automate the login.** Google and friends block automated sign-in (CAPTCHA, 2FA, bot detection), so scripting it is flaky and burns the run. If the flow can't continue, stop and ask the user to log in manually in the open session, then resume. One session runs the whole audit (stage 2), so a single manual login carries through every step.\n\n**Behind enterprise SSO**, a fresh `playwright-cli` profile can't get past at all — no cookies, no device trust, and manual login in a throwaway profile is often blocked outright. Drive the user's already-authenticated browser with `claude-in-chrome` instead; everything downstream is unchanged. Record the driver in `findings.md` — evidence from a live account has different provenance than a clean profile.\n\nA logged-out app shows a sign-in page or a stuck loading overlay in the `snapshot`, never the app content; treat either as unauthenticated.\n\n### 2. Drive\n\nAttach to the user's running browser at the stage-1 URL rather than launching a fresh profile — the running session carries the auth and app state a real user arrives with. Keep that one session for the whole walk; close it once, at the end of stage 4, since `shape` never drives.\n\nWork from snapshot element refs, never hand-rolled selectors: `snapshot` to read the page, act on refs like `e15`, re-`snapshot` after anything that changes it. **Don't persist screenshots** — the step log below is the evidence record, and images cost more context than they return. Prefer `read_page`\u002F`get_page_text` for structure; screenshot only to see something a text read can't show, and discard it after.\n\n**Mutating live state.** **Never** act in a way that notifies a third party or spends money — invites, outbound mail, OAuth grants, anything billable. **Freely** take genuinely reversible UI-state actions (expand, dismiss, open a composer you don't submit); no need to ask. Where only an irreversible action would answer a question, answer it from source instead (3a) — and name the steps you never exercised in the report, so a reader can tell an observed claim from an inferred one.\n\n**Walk one step at a time, logging each as a triple:**\n\n```\nelement (ref + label) → expected outcome → actual outcome\n```\n\nThe gap between expected and actual is where much of the friction lives:\n\n- **Mismatch** (actual ≠ expected) → confusion. The label promised one thing, the app did another.\n- **Retry** (you acted more than once, or hunted for the right element) → \"wait, how do I…\".\n- **Long wait \u002F no feedback** → invisible system status.\n- **Dead end** (expected a next step, got nothing) → the flow breaks here.\n\nThe triple is one lens, not the whole game — a step can do exactly what its label promised and still overload. So at every step also ask \"would a first-time user know where to start?\" and \"is everything needed to decide visible right now?\" — the *recognition-over-recall* and *aesthetic\u002Fminimalist* questions the rubric scores, and the friction automated walks miss most.\n\nRecord the wait qualitatively (instant \u002F a beat \u002F had-to-wait \u002F stalled) — which steps made you wait without telling you why.\n\n**Audit intended behaviour, not defects.** A design finding is one where the product worked as built and still failed the user. Browser automation is janky by nature, so an anomaly (dead click, error banner, blank region) is a signal to re-test on a fresh load, never a result. Reproduces identically → may be design; score it. Intermittent or gone on retry → a bug; mention it to the user in conversation and stop there.\n\n**Defects never enter the report** — not as a finding, not as evidence inside one, and not as an out-of-scope section. A defect list beside the findings competes for attention and sends `impeccable` designing around something someone should just fix.\n\n### 3. Score\n\nTurn the step log into **named findings** with the timed rubric in [references\u002Frubric.md](references\u002Frubric.md) — read it now. It converts Nielsen's heuristics into concrete questions (\"was the result visible within ~1s?\") so a finding is a rubric failure with evidence attached, not a vibe.\n\nTwo heuristics earn extra weight, being the ones automated walks surface best and teams miss most: **user control & freedom** — watch every point where you felt trapped with no undo, cancel or way back — and **recognition rather than recall** — watch every point where you had to hold something in your head instead of reading it off the screen.\n\nWork at the **micro level**: one interaction (\"the email field only errors after submit\"), not a whole-flow grade (\"signup is confusing\"). Whole-flow verdicts can't be fixed or re-tested; micro findings can.\n\nGive every finding a **stable, descriptive ID** — `\u003Cflow>-\u003Cwhat>`, e.g. `signup-email-late-validation` — describing the friction, not its position. Never bare sequence numbers. **Every finding cites its evidence:** the step-log row number(s) it rests on, plus `file:line` for anything read from source. A claim a reader can't trace isn't a finding.\n\nThen **synthesise the findings into 2–4 named problems.** A finding is an observation; a problem is what a cluster of them *means* — \"arrival is empty of purpose\", not ten separate complaints about one screen. **Each finding belongs to exactly one problem.** If a finding seems to belong to three, the problems aren't yet distinct — re-cluster until each owns its own evidence. Problems are what gets designed against; findings are what prove them.\n\n### 3a. Corroborate against source\n\nWhen the audited product's source is available, read the components behind each finding before scoring is final. It turns \"the progress bar never moved\" into \"the criterion measures threads, not connected channels\", and answers questions that would otherwise need a live mutation. **State no claim the code doesn't support** — if a criterion ticks under some condition you didn't hit, name that condition rather than rounding it up to \"never\".\n\n### 3b. Align the problems with the user\n\n**Stop and get agreement before spending anything downstream.** Stages 2 and 3 run **blind** — a steered walk finds the friction the user already suspected and misses the rest — so this gate is the first point of human input, after the evidence exists and before any design work does.\n\nAlign **on a document, not in chat.** Write the problems to `alignment.md` in the run's artifacts directory (stage 4) and iterate there: a settled problem space is worth more than an agreement one person remembers — the team reads the same statement of what's wrong, and `shape` re-enters from it as many times as the ideas need reworking.\n\nThe page carries a descriptive title, the flow's goal with an honest assessment of how well the flow serves it, and a `## problems` list — things to solve outright or areas to mitigate. **No solution ideas on this page.** An idea smuggled in as a problem gets agreed by proxy and quietly becomes the only direction anyone designs.\n\nTemplate, the questions to ask while aligning, and the bounded re-entry context the page must carry: [references\u002Falignment-doc.md](references\u002Falignment-doc.md).\n\n**Allocate the design budget here too.** The problems are rarely peers — one is often the mechanism behind another — so ask which get design work and which is load-bearing, before any research runs. The user already holds that answer, and stage 5 is far too late to learn it. Weigh it against the team's current goal metrics, asked for at this gate and never before the walk ([references\u002Falignment-doc.md](references\u002Falignment-doc.md)).\n\nRevise until the user agrees, then carry the aligned problems into stage 4. Everything after this — critique, research, fix directions, wireframes — is expensive and shaped entirely by this list.\n\n### 4. Report\n\nOne artifacts directory per run: **`\u003Caudited-repo>\u002F.claude\u002Ffriction-audit\u002F\u003Cflow>-\u003CYYYYMMDD>\u002F`** — the repo of the product you audited, not wherever you were invoked from. An audit belongs next to its product. It holds `findings.md`, `alignment.md` and the wireframe HTML; no screenshots, and no throwaway scripts you used to generate them.\n\n**Two files, one link each.** `alignment.md` owns the summary and the problems — the product layer the team aligns on. `findings.md` owns the evidence, and later the critique and fix directions. Link each to the other exactly once rather than restating either inside the other.\n\nWrite `findings.md` with [assets\u002Ffindings-template.md](assets\u002Ffindings-template.md), which fixes the section order. Two rules that order enforces: **lead with a summary** (goal, flow, driver, one-paragraph verdict, the problems as bullets, headline counts) so a reader gets the story in thirty seconds; and **problems before findings**, each citing its IDs, with the findings as the layer that proves them and the step log after. State the conclusion, then show the work — and state it **once**, so no restatement drifts out of sync.\n\n### 5. Shape the fix directions (`shape` mode)\n\nEntered with an aligned problem set — straight from 3b, or from a doc the user named. Read the doc and its re-entry context and take the problems as given; re-deriving them here throws away the agreement they represent. Close the browser first if this run drove one.\n\n- **Critique:** invoke `impeccable` in `critique` mode against the audited surface with `findings.md` as evidence, so its review is grounded in observed behaviour rather than a static read. **Fold what comes back into `findings.md`** — score, specificity verdict and P0s as a `## Critique` section. A critique in a separate file gets read separately or not at all; the point is that its emphasis visibly drives the directions.\n- **One research-and-ideation agent per problem** — the fan-out unit; each agent owns a single problem end to end.\n  - **Research the precedent.** How well-regarded products solve that problem, with **at least one primary source** (the product's own docs, changelog, release notes, or a first-hand teardown), naming the specific surface examined. Aggregator listicles find candidates but are never a citation, and **no statistic without a primary source** — a vendor's conversion claim is marketing until you can point at where it's measured. Two or three worked examples beat a survey.\n  - **Then ideate against it.** **Three divergent ideas argued in prose**, each naming the problem and the critique point it answers, plus **the signal that would show it worked** — a direction with no observable outcome is a proposal, not something a team can ship and check. Three is the *generation* target, not the output contract; the gate below decides what survives. Route them through `impeccable` in `shape` mode to sharpen.\n- **Converge before anything is drawn.** With every problem's ideas sharpened, read them all against each other in one pass and take that read to the user: which theses collapse into one, what composes and what's mutually exclusive, and a recommended bundle in ship order — ship now \u002F this quarter \u002F rewrite — from the directions' own cost notes. One field is required rather than lucky: **the cheapest change that repairs the walked blocker, even when it is none of the directions.** Keep sharpening *before* this gate — `impeccable`'s corrections are often what decide whether a direction is viable, which is exactly what the gate needs to choose on. Then ask what gets wireframed; the count is an output of that answer, so one problem may carry four frames and another one. Draw to a fixed quota instead and the run discovers its own duplicates only after paying to research, argue and draw them.\n- **Wireframes illustrate ideas; they never produce them.** Draw only **what the gate selected**, and only once the ideas exist as prose, grounded in the surface's current code. The test: **if an idea can't be written as a paragraph before it's drawn, it isn't an idea yet.** Sketch first and you end up reading the rationale off your own drawings, with justifications retrofitted onto them. Fidelity and framing: [references\u002Fwireframe-style.md](references\u002Fwireframe-style.md), read before drawing. Render mechanics and the fallback: [references\u002Fopen-design.md](references\u002Fopen-design.md).\n- **Close with the trail:** end `findings.md` with `## Inspiration — where to look next` — per problem, the products worth studying and one line on what each does right. The research is worth more as a trail the user can follow than as a citation buried in a fix direction.\n\nReport what you handed off and what came back, and end on the gate's recommendation — an unranked menu of alternatives is a stall for a team working in weeks. Don't editorialise a second critique on top; recommending a bundle isn't re-arguing `impeccable`'s verdict.\n\n## Execution shape\n\nStages 2 and 3 stay one context, one session, serial — each step informs the next, and the 3b gate needs one context holding the whole evidence set. The rest is fan-out shaped:\n\n- **3a corroboration and the stage-5 research agents** — independent per file and per problem, so run them as parallel subagents. Serial shallow searches are what produce listicle-grade precedent.\n- **`impeccable critique`'s two assessments** — isolation is a *correctness* requirement here, not a speed-up: run inline and the critique has already absorbed your findings, so its agreement proves nothing. If subagents are unavailable, say so in the report and state that agreement is not corroboration.\n- **Wireframe authoring** — single-context. One shared style pass beats the same fix made four times.\n\nYou stay the synthesis point; subagents return evidence, not conclusions.\n\n**Match the model to the work.** An all-Opus run costs several times a tiered one and buys nothing on the mechanical stages, so spend the expensive model only where judgement actually happens:\n\n- **Sonnet** — 3a source corroboration, precedent gathering, and wireframe authoring and rendering. These are read-heavy and style-constrained; the reference files already carry the judgement.\n- **Opus** — scoring and clustering (stage 3), each problem's idea synthesis, the convergence read, and `impeccable critique`. Deciding what a cluster of findings *means*, what collapses into what, and what to build instead is the part that degrades when you economise.\n\n## Fresh runs\n\n**Every invocation starts clean.** Don't search for prior `friction-audit` directories, don't read one you know exists, don't present cached findings as current. Old evidence goes stale, and a prior run's fix directions quietly become the ceiling on the new ones — the second audit reproduces the first instead of seeing the flow again. Compare across runs **only when the user asks**; then diff by finding ID (gone is fixed, surviving isn't, new is a regression) and say which prior IDs you couldn't re-test.\n\nAn alignment doc the user hands you in `shape` mode isn't an exception to this — they named it, so it's their current problem set, not a cached one you went looking for.\n\n## Scope boundaries\n\n- **You don't own the critique** — `impeccable` does, and its verdict gets folded in rather than argued with. Ideation is shared: the per-problem research agents form the ideas, `impeccable` sharpens them.\n- **You don't decide the problems alone** — the 3b gate does, with the user. A problem set you never got agreed is a guess with a document around it.\n- **You don't hunt bugs** — defects and automation artifacts never reach the report (stage 2). A broken thing needs fixing, not redesigning.\n- **You don't write tests** — the walk is throwaway observation. Regression tests are `playwright-cli`'s job.\n- **You don't do participant recruiting, fidelity ladders, video, or network mocking** — one agent, one live flow.\n",{"name":5,"description":51,"allowed-tools":52},"Drives a live web flow through a real browser, turns the run into evidence-backed friction findings, then routes them into the impeccable skill for critique and redesign. Use whenever the user wants to know where a real user gets stuck, confused or slowed down in a running flow — \"audit the signup flow\", \"where's the friction in checkout\", \"walk through onboarding and tell me what's clunky\", \"usability audit of the live app\", \"why do people drop off here\". Trigger on \"usability\", \"UX audit\", \"friction\", \"drop-off\" or \"walk the flow\" without this skill being named, and when the user only supplies a URL and asks what's wrong with the experience. Trigger before any URL or credentials exist — settling the goal, flow and environment is this skill's own first step, so ask for what's missing from inside the skill. Also use to run the design half alone from an agreed problems doc.\n","Bash(playwright-cli:*), Bash(od:*), Bash(odo:*)","main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fproduct\u002Fflow-friction-audit","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 22:26:34",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill flow-friction-audit",{"tool":67,"command":68},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill flow-friction-audit",{"tool":70,"command":71},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill flow-friction-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002FSKILL.md",true,[75,81,87,91,95,99,103],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"assets\u002Ffindings-template.md","ASSET","资产文件",3865,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Fassets\u002Ffindings-template.md",{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Ftrigger-eval.json","REFERENCE","参考文档",4153,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Fevals\u002Ftrigger-eval.json",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Falignment-doc.md",4941,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Freferences\u002Falignment-doc.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fopen-design.md",7822,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Freferences\u002Fopen-design.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Frubric.md",3660,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Freferences\u002Frubric.md",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fwireframe-style.md",6259,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Freferences\u002Fwireframe-style.md",{"path":104,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":105,"sourceHtmlUrl":106},"skill-feedback-ledger.md",24752,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fflow-friction-audit\u002Fskill-feedback-ledger.md",[108,116,123,151,180,205],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":115},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":115},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":46},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150],"tickets","to tickets","new","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","repo","for","feature","run","worktrees","as","cut",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":162,"publishedAt":46},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":160,"taxonomyTypeDesc":161},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[163,164,132,165,166,167,168,169,170,171,172,29,173,141,174,175,176,144,145,177,178,179,149,143],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":189,"publishedAt":46},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[186],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理",[190,191,192,149,146,193,194,29,195,196,197,130,198,199,135,200,201,141,142,202,203,204],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":212,"publishedAt":46},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[211],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},[213,214,215,216,217,218,219,220,130,221,135,222,223,40,141,203,146,224,225,149],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","problem","which"]