[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CQV3WDYYRAEXPQ2M8CKFZT":3,"skill-same:01M6CQV3WDYYRAEXPQ2M8CKFZT":73},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6CQV3WDYYRAEXPQ2M8CKFZT","flow-mapping",null,"Turn current-state data-flow evidence into Mermaid diagrams that compile and state payload, cadence and reliability, gated by a validation script, at .gener8v\u002Fflows\u002F with an explicit Unknowns list. Use for data-flow, system-map or integration-map deliverables, or to check existing diagrams before they are published, such as 'map how claims data moves between systems' or 'draw the integration map'. Current state only: not for future-state architecture proposals (technical-design).","gener8v\u002Fgener8v.claude-skills","gener8v","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F262388633?v=4","01M6CQT9VAG2MX3NN1CBMGR2T8","GENER8V","01M6CQT9YZXXYFF41ZYFW774DQ",3,"MIT","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fflow-mapping\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"flow mapping","flow","technical","domain","diagrams","evidence","only","reliability","use","proposals","check","design","system","file","compile","state","current state","mermaid","architecture","mermaid diagrams","2026-11-10 10:12:30",false,"---\nname: flow-mapping\ndescription: \"Turn current-state data-flow evidence into Mermaid diagrams that compile and state payload, cadence and reliability, gated by a validation script, at .gener8v\u002Fflows\u002F with an explicit Unknowns list. Use for data-flow, system-map or integration-map deliverables, or to check existing diagrams before they are published, such as 'map how claims data moves between systems' or 'draw the integration map'. Current state only: not for future-state architecture proposals (technical-design).\"\nargument-hint: \"[domain | source file]\"\n---\n\n# Flow Mapping Skill\n\n## Purpose\n\nTurn current-state data-flow findings into Mermaid diagrams that **compile, read clearly, and state\ntheir own maturity** — then iterate on them until they do. A flow map is not decoration: it is the\nartifact stakeholders argue with. A diagram that renders but hides its cadence, its reliability, or\nits evidence is worse than no diagram, because it looks authoritative while asserting nothing.\n\nThe skill pairs a **deterministic validator** (compilation + structural lints) with an **LLM review\npass** (judgement). The split matters: regex settles what is decidable, so the model's attention is\nspent only on what needs a reader's judgement.\n\n## When to Use\n\nUse this skill when:\n- A data-flow \u002F system-map \u002F integration-map deliverable needs diagrams\n- Existing diagrams need to be checked before publication (they may not even compile)\n- Current-state flows must be shown per domain (Sales, Policy, Underwriting, Claims, ...)\n- Prose describes flows that nobody has drawn, so contradictions stay invisible\n- A pipeline emits flows as `{source, target, transformation}` triples and needs them rendered\n\nDo **not** use it for future-state architecture proposals — this skill asserts what *is*, evidenced.\n\n## Input\n\n**Source:** flow findings in any of these shapes\n- `data-flow` \u002F `system-map` \u002F `integration-map` deliverables (`.json` or `.md`) produced *outside* this pipeline — by a discovery engagement, an integration inventory, or an interview-analysis tool\n- flow triples: `[{name, source, target, transformation}, ...]`\n- interview evidence describing how data moves\n- from inside the pipeline: `.gener8v\u002Fcontext.md` (external integrations, Brownfield Phase 2) and `.gener8v\u002Fbrownfield\u002Freconnaissance.md` (side effects per file)\n\n**Expects:** at minimum a source, a target, and what moves between them. Cadence, mechanism, and\nreliability are what the skill exists to force into the open — their absence is a finding, not a\nblocker.\n\n## Output\n\n**Writes to:** `.gener8v\u002Fflows\u002F[domain-slug].md` (one file per domain), each containing:\n- a short prose statement of the domain's current-state flow\n- one or more Mermaid diagrams\n- an explicit **Unknowns** list — what could not be evidenced\n\n**Gate:** `${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fvalidate-flows.sh` must exit 0 before the artifact is considered done. The path is absolute under both the plugin and a copied install, so run it exactly as written; the session's working directory is the user's project, so a relative `scripts\u002F…` never resolves.\n\n## Output Format\n\n````markdown\n# [Domain] — Current-State Data Flow\n\n## How data moves today\n[Prose: the flow in plain language, naming systems and the humans in the loop.]\n\n```mermaid\ngraph TD\n    classDef reliable fill:#d4edda,stroke:#28a745,color:#000\n    classDef fragile  fill:#fff3cd,stroke:#ffc107,color:#000\n    classDef broken   fill:#f8d7da,stroke:#dc3545,color:#000\n    classDef isolated fill:#e2e3e5,stroke:#6c757d,color:#000,stroke-dasharray: 5 5\n\n    CRM[\"CRM\"]\n    PolicyAdmin[\"Policy Admin\"]\n    class CRM fragile\n    class PolicyAdmin fragile\n\n    CRM -. \"member number, name, address | batch | nightly\" .-> PolicyAdmin\n```\n\n## Reliability\n| Node\u002FFlow | Class | Why |\n|---|---|---|\n| CRM → Policy Admin | fragile | Nightly batch; date of birth silently dropped |\n\n## Unknowns\n- [What the evidence does not establish — named, not smoothed over.]\n````\n\n## Principles\n\n1. **Compilation is non-negotiable.** A diagram that does not render is not a deliverable. Gate it\n   mechanically (`mmdc` exits 1 on a parse error); never eyeball it.\n2. **Every edge states its payload.** `A --> B` asserts nothing. Say *what* moves, *how*, and *how\n   often*: `-. \"member number | batch | nightly\" .->`.\n3. **Reliability is part of the model, not a footnote.** Use the four classes — `reliable`,\n   `fragile`, `broken`, `isolated`. An unclassed node is an unasked question.\n4. **`isolated` means deliberately unconnected.** An isolated store with no edges *is* the finding\n   (nothing reads or writes it). Do not \"fix\" it by inventing an edge, and do not lint it as an\n   orphan.\n5. **Evidence or unknown — never plausible.** A flow nobody described does not go in the diagram\n   because it would be tidy. It goes in **Unknowns**.\n6. **One domain per diagram.** Past ~18 nodes a graph stops being read and starts being admired.\n   Split by domain and link.\n7. **Contradiction is signal.** When IT and field staff describe the same flow differently, draw\n   both and mark the conflict. Averaging them destroys the finding.\n8. **Regex first, model second.** Do not spend an LLM call on what a lint decides.\n\n## Process\n\n1. **Collect** flows from the source deliverable\u002Fevidence. Group by domain.\n2. **Draft** one diagram per domain in the Output Format above.\n3. **Validate (mechanical):**\n   ```bash\n   ${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fvalidate-flows.sh .gener8v\u002Fflows\u002F*.md\n   ```\n   Fix every `ERROR` (compilation, no nodes). Treat each `WARN` as a question to answer, not noise\n   to silence — an unlabelled edge usually means the evidence never said what moves.\n4. **Review (judgement)** — the LLM pass, on what the lint cannot decide:\n   - **Clarity:** would a stakeholder who was *not* in the interviews read this the way we mean?\n     Are labels domain language, or our shorthand? Is direction consistent?\n   - **Maturity:** is each class assignment defensible from evidence? Is cadence real or assumed?\n     Are the humans in the loop drawn, or silently abstracted into a system box?\n   - **Fidelity:** does the diagram claim anything the evidence does not support? Anything in the\n     prose that is missing from the diagram (or vice versa)?\n5. **Iterate** 3–4 until validation is clean and review raises nothing new. Record what changed.\n6. **Report** unresolved conflicts and Unknowns — they are output, not failure.\n\n## Example\n\n**Input triple**\n```json\n{\"name\": \"member sync\", \"source\": \"CRM\", \"target\": \"PolicyAdmin\",\n \"transformation\": \"nightly batch; date of birth dropped\"}\n```\n\n**Draft (fails)**\n```\ngraph TD\n  CRM --> PolicyAdmin\n```\n`validate-flows.sh` → `WARN 1\u002F1 edge(s) unlabelled`, `WARN no classDef`, `WARN no cadence`.\nIt compiles, so it looks finished — and asserts nothing.\n\n**After iteration**\n```\ngraph TD\n    classDef fragile fill:#fff3cd,stroke:#ffc107,color:#000\n    CRM[\"CRM\"]\n    PolicyAdmin[\"Policy Admin\"]\n    class CRM fragile\n    class PolicyAdmin fragile\n    CRM -. \"member number, name, address | batch | nightly\" .-> PolicyAdmin\n```\nNow it says: this is a batch flow, it runs nightly, it is fragile, and here is exactly what crosses.\nThe date-of-birth loss surfaces in **Reliability** and drives a finding.\n\n## Troubleshooting\n\n- **`validate-flows.sh needs npx (Node)`, exit 2.** Nothing was validated — exit 2 is a usage problem, not a compile failure. Install Node and rerun; the artifact is not done until the gate exits 0.\n- **Every diagram reports `does not compile` with an npm or network error.** The first run fetches `@mermaid-js\u002Fmermaid-cli@11` through `npx`; without network access the fetch fails and each diagram is reported as a compile `ERROR`. The quoted error names npm, not a Mermaid token. Allow network for that first run and rerun.\n- **A compile `ERROR` shows six lines and `… more line(s)`.** The part naming the offending token is usually further down. Save that block as a `.mmd` file and run `npx --yes @mermaid-js\u002Fmermaid-cli@11 -i block.mmd -o \u002Ftmp\u002Fblock.svg` to read the whole message.\n- **`WARN … has N nodes (>18) — split by domain`.** Split the diagram by domain and link the parts (Principle 6). `MAX_NODES=24` raises the threshold for a domain that genuinely cannot be split.\n- **`WARN … node 'X' is declared but never flows anywhere`.** Either the evidence never said what reaches it — the flow belongs in **Unknowns**, not in an invented edge — or it is deliberately unconnected, and `class X isolated` says so.\n- **Running the validator asks for permission.** Expected: the skill pre-approves nothing, because a skill with `allowed-tools` must itself be approved each time Claude invokes it — which would stop a flow map Claude starts on its own. Approve the command once, or add `Bash(${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fvalidate-flows.sh *)` with the absolute path to the project's permission allow rules. Run it exactly as written: a `bash` prefix, a `cd … &&` or a relative path is a different command and will not match a rule.\n\n## Integration with Other Skills\n\n- **Upstream:** discovery deliverables from outside the pipeline; inside it, Brownfield's `context.md` and\n  `brownfield\u002Freconnaissance.md`.\n- **Technical Design:** reads `.gener8v\u002Fflows\u002F*.md` as the current-state baseline any target-state design\n  must move from.\n- **Brownfield:** flow maps are evidence for capability boundaries (Phase 3).\n- **Specification:** Unknowns become open questions.\n- **Orchestrate:** lists flow maps under `cross_cutting.flows`; Audit checks them (compilation, Unknowns\n  present, every edge labelled).\n\n## Revisions\n\n- Re-run when new evidence arrives (an interview, a discovered integration) or when a flow's cadence,\n  mechanism or reliability changes; a diagram is current-state and dates quickly — record the evidence\n  date in the prose.\n- Re-validate after any edit: the gate is cheap and a diagram that stops compiling is worse than none.\n- Flow maps are standalone artifacts: they are not invalidated by PRD or specification changes.\n\n## Notes\n\n- The validator needs `npx` (Node). It fetches `@mermaid-js\u002Fmermaid-cli@11` on first run (network access,\n  ~30 s); when `npx` is absent it says so and exits 2 rather than reporting a compile failure.\n- `MAX_NODES` (default 18) tunes the split threshold: `MAX_NODES=24 validate-flows.sh ...`.\n- The four `classDef` colors are the house convention; keep them stable so diagrams read the same across\n  projects.\n- Exit codes: `0` all diagrams compile and no ERROR lints; `1` otherwise; `2` bad usage.\n","# Flow Mapping Skill\n\n## Purpose\n\nTurn current-state data-flow findings into Mermaid diagrams that **compile, read clearly, and state\ntheir own maturity** — then iterate on them until they do. A flow map is not decoration: it is the\nartifact stakeholders argue with. A diagram that renders but hides its cadence, its reliability, or\nits evidence is worse than no diagram, because it looks authoritative while asserting nothing.\n\nThe skill pairs a **deterministic validator** (compilation + structural lints) with an **LLM review\npass** (judgement). The split matters: regex settles what is decidable, so the model's attention is\nspent only on what needs a reader's judgement.\n\n## When to Use\n\nUse this skill when:\n- A data-flow \u002F system-map \u002F integration-map deliverable needs diagrams\n- Existing diagrams need to be checked before publication (they may not even compile)\n- Current-state flows must be shown per domain (Sales, Policy, Underwriting, Claims, ...)\n- Prose describes flows that nobody has drawn, so contradictions stay invisible\n- A pipeline emits flows as `{source, target, transformation}` triples and needs them rendered\n\nDo **not** use it for future-state architecture proposals — this skill asserts what *is*, evidenced.\n\n## Input\n\n**Source:** flow findings in any of these shapes\n- `data-flow` \u002F `system-map` \u002F `integration-map` deliverables (`.json` or `.md`) produced *outside* this pipeline — by a discovery engagement, an integration inventory, or an interview-analysis tool\n- flow triples: `[{name, source, target, transformation}, ...]`\n- interview evidence describing how data moves\n- from inside the pipeline: `.gener8v\u002Fcontext.md` (external integrations, Brownfield Phase 2) and `.gener8v\u002Fbrownfield\u002Freconnaissance.md` (side effects per file)\n\n**Expects:** at minimum a source, a target, and what moves between them. Cadence, mechanism, and\nreliability are what the skill exists to force into the open — their absence is a finding, not a\nblocker.\n\n## Output\n\n**Writes to:** `.gener8v\u002Fflows\u002F[domain-slug].md` (one file per domain), each containing:\n- a short prose statement of the domain's current-state flow\n- one or more Mermaid diagrams\n- an explicit **Unknowns** list — what could not be evidenced\n\n**Gate:** `${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fvalidate-flows.sh` must exit 0 before the artifact is considered done. The path is absolute under both the plugin and a copied install, so run it exactly as written; the session's working directory is the user's project, so a relative `scripts\u002F…` never resolves.\n\n## Output Format\n\n````markdown\n# [Domain] — Current-State Data Flow\n\n## How data moves today\n[Prose: the flow in plain language, naming systems and the humans in the loop.]\n\n```mermaid\ngraph TD\n    classDef reliable fill:#d4edda,stroke:#28a745,color:#000\n    classDef fragile  fill:#fff3cd,stroke:#ffc107,color:#000\n    classDef broken   fill:#f8d7da,stroke:#dc3545,color:#000\n    classDef isolated fill:#e2e3e5,stroke:#6c757d,color:#000,stroke-dasharray: 5 5\n\n    CRM[\"CRM\"]\n    PolicyAdmin[\"Policy Admin\"]\n    class CRM fragile\n    class PolicyAdmin fragile\n\n    CRM -. \"member number, name, address | batch | nightly\" .-> PolicyAdmin\n```\n\n## Reliability\n| Node\u002FFlow | Class | Why |\n|---|---|---|\n| CRM → Policy Admin | fragile | Nightly batch; date of birth silently dropped |\n\n## Unknowns\n- [What the evidence does not establish — named, not smoothed over.]\n````\n\n## Principles\n\n1. **Compilation is non-negotiable.** A diagram that does not render is not a deliverable. Gate it\n   mechanically (`mmdc` exits 1 on a parse error); never eyeball it.\n2. **Every edge states its payload.** `A --> B` asserts nothing. Say *what* moves, *how*, and *how\n   often*: `-. \"member number | batch | nightly\" .->`.\n3. **Reliability is part of the model, not a footnote.** Use the four classes — `reliable`,\n   `fragile`, `broken`, `isolated`. An unclassed node is an unasked question.\n4. **`isolated` means deliberately unconnected.** An isolated store with no edges *is* the finding\n   (nothing reads or writes it). Do not \"fix\" it by inventing an edge, and do not lint it as an\n   orphan.\n5. **Evidence or unknown — never plausible.** A flow nobody described does not go in the diagram\n   because it would be tidy. It goes in **Unknowns**.\n6. **One domain per diagram.** Past ~18 nodes a graph stops being read and starts being admired.\n   Split by domain and link.\n7. **Contradiction is signal.** When IT and field staff describe the same flow differently, draw\n   both and mark the conflict. Averaging them destroys the finding.\n8. **Regex first, model second.** Do not spend an LLM call on what a lint decides.\n\n## Process\n\n1. **Collect** flows from the source deliverable\u002Fevidence. Group by domain.\n2. **Draft** one diagram per domain in the Output Format above.\n3. **Validate (mechanical):**\n   ```bash\n   ${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fvalidate-flows.sh .gener8v\u002Fflows\u002F*.md\n   ```\n   Fix every `ERROR` (compilation, no nodes). Treat each `WARN` as a question to answer, not noise\n   to silence — an unlabelled edge usually means the evidence never said what moves.\n4. **Review (judgement)** — the LLM pass, on what the lint cannot decide:\n   - **Clarity:** would a stakeholder who was *not* in the interviews read this the way we mean?\n     Are labels domain language, or our shorthand? Is direction consistent?\n   - **Maturity:** is each class assignment defensible from evidence? Is cadence real or assumed?\n     Are the humans in the loop drawn, or silently abstracted into a system box?\n   - **Fidelity:** does the diagram claim anything the evidence does not support? Anything in the\n     prose that is missing from the diagram (or vice versa)?\n5. **Iterate** 3–4 until validation is clean and review raises nothing new. Record what changed.\n6. **Report** unresolved conflicts and Unknowns — they are output, not failure.\n\n## Example\n\n**Input triple**\n```json\n{\"name\": \"member sync\", \"source\": \"CRM\", \"target\": \"PolicyAdmin\",\n \"transformation\": \"nightly batch; date of birth dropped\"}\n```\n\n**Draft (fails)**\n```\ngraph TD\n  CRM --> PolicyAdmin\n```\n`validate-flows.sh` → `WARN 1\u002F1 edge(s) unlabelled`, `WARN no classDef`, `WARN no cadence`.\nIt compiles, so it looks finished — and asserts nothing.\n\n**After iteration**\n```\ngraph TD\n    classDef fragile fill:#fff3cd,stroke:#ffc107,color:#000\n    CRM[\"CRM\"]\n    PolicyAdmin[\"Policy Admin\"]\n    class CRM fragile\n    class PolicyAdmin fragile\n    CRM -. \"member number, name, address | batch | nightly\" .-> PolicyAdmin\n```\nNow it says: this is a batch flow, it runs nightly, it is fragile, and here is exactly what crosses.\nThe date-of-birth loss surfaces in **Reliability** and drives a finding.\n\n## Troubleshooting\n\n- **`validate-flows.sh needs npx (Node)`, exit 2.** Nothing was validated — exit 2 is a usage problem, not a compile failure. Install Node and rerun; the artifact is not done until the gate exits 0.\n- **Every diagram reports `does not compile` with an npm or network error.** The first run fetches `@mermaid-js\u002Fmermaid-cli@11` through `npx`; without network access the fetch fails and each diagram is reported as a compile `ERROR`. The quoted error names npm, not a Mermaid token. Allow network for that first run and rerun.\n- **A compile `ERROR` shows six lines and `… more line(s)`.** The part naming the offending token is usually further down. Save that block as a `.mmd` file and run `npx --yes @mermaid-js\u002Fmermaid-cli@11 -i block.mmd -o \u002Ftmp\u002Fblock.svg` to read the whole message.\n- **`WARN … has N nodes (>18) — split by domain`.** Split the diagram by domain and link the parts (Principle 6). `MAX_NODES=24` raises the threshold for a domain that genuinely cannot be split.\n- **`WARN … node 'X' is declared but never flows anywhere`.** Either the evidence never said what reaches it — the flow belongs in **Unknowns**, not in an invented edge — or it is deliberately unconnected, and `class X isolated` says so.\n- **Running the validator asks for permission.** Expected: the skill pre-approves nothing, because a skill with `allowed-tools` must itself be approved each time Claude invokes it — which would stop a flow map Claude starts on its own. Approve the command once, or add `Bash(${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fvalidate-flows.sh *)` with the absolute path to the project's permission allow rules. Run it exactly as written: a `bash` prefix, a `cd … &&` or a relative path is a different command and will not match a rule.\n\n## Integration with Other Skills\n\n- **Upstream:** discovery deliverables from outside the pipeline; inside it, Brownfield's `context.md` and\n  `brownfield\u002Freconnaissance.md`.\n- **Technical Design:** reads `.gener8v\u002Fflows\u002F*.md` as the current-state baseline any target-state design\n  must move from.\n- **Brownfield:** flow maps are evidence for capability boundaries (Phase 3).\n- **Specification:** Unknowns become open questions.\n- **Orchestrate:** lists flow maps under `cross_cutting.flows`; Audit checks them (compilation, Unknowns\n  present, every edge labelled).\n\n## Revisions\n\n- Re-run when new evidence arrives (an interview, a discovered integration) or when a flow's cadence,\n  mechanism or reliability changes; a diagram is current-state and dates quickly — record the evidence\n  date in the prose.\n- Re-validate after any edit: the gate is cheap and a diagram that stops compiling is worse than none.\n- Flow maps are standalone artifacts: they are not invalidated by PRD or specification changes.\n\n## Notes\n\n- The validator needs `npx` (Node). It fetches `@mermaid-js\u002Fmermaid-cli@11` on first run (network access,\n  ~30 s); when `npx` is absent it says so and exits 2 rather than reporting a compile failure.\n- `MAX_NODES` (default 18) tunes the split threshold: `MAX_NODES=24 validate-flows.sh ...`.\n- The four `classDef` colors are the house convention; keep them stable so diagrams read the same across\n  projects.\n- Exit codes: `0` all diagrams compile and no ERROR lints; `1` otherwise; `2` bad usage.\n",{"name":5,"description":7,"argument-hint":44},"[domain | source file]","main","26f591c601503d32ccba54a6ddbcba75a00910c0","skills\u002Fflow-mapping",0,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills","https:\u002F\u002Fgithub.com\u002Fgener8v","gener8v.com","2026-10-22 20:18:28",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add gener8v\u002Fgener8v.claude-skills --skill flow-mapping",{"tool":59,"command":60},"bunx","bunx skills add gener8v\u002Fgener8v.claude-skills --skill flow-mapping",{"tool":62,"command":63},"pnpm","pnpm dlx skills add gener8v\u002Fgener8v.claude-skills --skill flow-mapping","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fflow-mapping\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"scripts\u002Fvalidate-flows.sh","SCRIPT","脚本",7172,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fflow-mapping\u002Fscripts\u002Fvalidate-flows.sh",[74,99,125,141,163,189],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":39},"01M6CQW5KKZVDJTN9VREPRFT06","ticket-breakdown","Decompose one capability area's requirements for one change into implementable tickets with Priority, Value, acceptance criteria, Prior Art, Output contracts, Known Hazards, dependency ordering and relative sizing: one TICKET-NNN.md per ticket plus backlog.md, in the change's tickets directory. Use when a specification is approved and the team needs work items, such as 'break this spec into tickets' or 'create the backlog for search'. Not for implementing a ticket (delivery) or ordering whole capability areas (dependencies).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fticket-breakdown\u002FSKILL.md",[],[81,82,83,84,85,86,87,88,89,27,90,91,92,93,94,95,96,97,98],"ticket breakdown","directory","spec","change","create","acceptance","search","team","work","dependency","decompose","Art","specification","contracts","acceptance criteria","backlog","dependencies","delivery",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":115,"publishedAt":39},"01M6CQW2XD2Q1JD7KFX944EH4W","technical-design","Translate specifications, constraints and dependencies into architecture decisions (AD-XXX), component boundaries, data model and interface contracts under .gener8v\u002Ftechnical-design\u002F. Use when technology or architecture choices must be settled before tickets are written, such as 'which datastore should we use' or 'design the components for search'. Skip it when the approach is obvious and uncontested. Not for judging an architecture that has already shipped (architecture-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-design\u002FSKILL.md",[105,110],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[30,21,116,117,118,119,120,37,87,121,122,31,123,124,27,94,97],"technical design","review","translate","components","component","data","constraints","model","decisions",{"skillNo":126,"name":93,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":133,"publishedAt":39},"01M6CQVZY5JC08BEMTSSST1464","Expand one capability area from .gener8v\u002Fprd.md into a functional specification with atomic, testable [PREFIX]-REQ-XXX requirements, behaviors, edge cases and open questions under .gener8v\u002Fspecifications\u002F. Use when a PRD capability area needs elaboration before constraints, technical design or tickets, or a change brief still marks an area as pending specification, such as 'spec out the search area' or 'write the requirements for billing'. Not for the whole product (planning) or work items (ticket-breakdown).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fspecification\u002FSKILL.md",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000031","产品经理",[93,30,83,84,134,135,87,136,137,138,122,139,89,21,140,27],"planning","product","edge","brief","prd","open","write",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":39},"01M6CQVX5MJQWPEEWDMRC21ZEJ","setup","Bootstrap the gener8v pipeline in a project: create .gener8v\u002F, copy the conventions, generate pipeline-state.yaml, and add the pipeline directives to CLAUDE.md. Use when the user says 'set up gener8v' or 'initialize the pipeline', when a project has no .gener8v\u002Fprd.md, or after a plugin upgrade to refresh the conventions. Not for deciding what to do next on a project already on the pipeline (orchestrate).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsetup\u002FSKILL.md",[],[143,148,149,85,150,34,151,152,138,153,154,155,156,157,158,27,159,160,161,162],"plugin","bootstrap","generate","orchestrate","yaml","pipeline","SET","Bash","python3","initialize","refresh","up","do","next","upgrade",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":172,"publishedAt":39},"01M6CQVT9PZZ64TC456Y1FWF55","security-review","OWASP-informed, code-level security review of delivered code: injection, authentication and authorization, data exposure, configuration, dependencies, cryptography and logging, with attack scenarios for Medium+ findings and compliance constraints (CC-XXX) treated as Critical. Use after a delivery, especially one touching input handling, auth, sensitive data or external integrations, such as 'security review TICKET-007' or 'check what this delivery shipped for injection or auth bypass before we merge'. Not for a whole-codebase OWASP posture assessment (owasp-top10-review) or prompt-injection risk in LLM features (owasp-llm-top10-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecurity-review\u002FSKILL.md",[169],{"categoryNo":170,"categoryName":171,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000037","律师与法务",[117,173,174,84,175,176,177,178,179,180,181,182,183,184,185,186,29,27,187,188],"security","security review","auth","merge","assessment","code","authentication","compliance","owasp-llm-top10","prompt-injection","owasp-llm","risk","integrations","prompt","files","007",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":39},"01M6CQVPP78PF4SB9H5WAD3837","rot-watch","Detect decay in code that is being actively written: measure six signals (packaging drift, dependency direction, comment language, growth slopes, tests, the detectable subset of SOLID) against a recorded baseline and report only what moved, at .gener8v\u002Frot\u002F. Use once code has been delivered and again every few deliveries, before a release, or when asked 'is the codebase getting worse' or 'has this module drifted'. The first run records the baseline and reports nothing. Not for one delivery's quality (quality-review), defects (defect-sweep) or whether the architecture was right (architecture-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Frot-watch\u002FSKILL.md",[],[196,117,197,37,198,178,199,200,201,202,203,204,205,206,27,25,90,207,208,98],"rot watch","solid","run","report","release","first","baseline","sweep","quality","growth","packaging","reports","drift"]