[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DNJVKEXDSYCM98DP1SRN0Y":3,"skill-same:01M6DNJVKEXDSYCM98DP1SRN0Y":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M6DNJVKEXDSYCM98DP1SRN0Y","shape-work",null,"Use when a vague idea, issue, or potentially irreversible or multi-file change needs intent shaping before planning or an ADR; trigger on \"shape this idea\", \"explore the design space\", \"stress-test this direction\", \"lock intent\", or \"interview me\" regardless of implementation language, and never use it to plan or write code.","0xgleb\u002Fdotconfig","0xgleb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F39841057?v=4","01M6DNDD83BRMM1SH4R4C6K8GY","01M6DNDDCPH33FEFB6JN6Y2GVD",3,"MIT","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Fshape-work\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"shape work","shape","work","gh","trigger","stress-test","never","use","interview","view","design","adr","shaping","explore","Bash","gh issue","file","planning","code","test","2026-11-10 10:12:30",false,"---\nname: shape-work\nuser-invocable: true\nallowed-tools:\n  - Read\n  - Grep\n  - Glob\n  - \"Bash(ls adrs *)\"\n  - \"Bash(gh issue view *)\"\n  - Write\n  - Edit\ndescription: >-\n  Use when a vague idea, issue, or potentially irreversible or multi-file\n  change needs intent shaping before planning or an ADR; trigger on \"shape\n  this idea\", \"explore the design space\", \"stress-test this direction\",\n  \"lock intent\", or \"interview me\" regardless of implementation language,\n  and never use it to plan or write code.\n---\n\nShape vague work into testable success criteria and explicit non-goals BEFORE\nany plan, ADR, or multi-file change. This is the gate that stands between \"an\nidea\" and \"a plan\". It interviews, diverges, converges, and locks intent — it\nnever plans the implementation and never writes production code.\n\n## Core process\n\n1. **GROUND.** Read before writing a single word. Pull the tracker item first:\n   `gh issue view \u003CN>` for the project's GitHub issue. Then read the relevant\n   source modules, `ls adrs\u002F` and the matching `adrs\u002FNN-*.md`, and `ROADMAP.md`.\n   You cannot shape work you have not read. If the idea touches a crate you have\n   not opened, open it (Grep \u002F Glob \u002F Read) before reframing it.\n\n2. **DIVERGE (optional, when the framing itself is in doubt).** Reframe as a\n   How-Might-We that names _who it serves in domain terms_ (\"How might we let\n   the settlement engine reject an underfunded order before it touches the\n   ledger?\" — not \"How might we add validation?\"). Generate 5-8 variations\n   through lenses tuned to this engineer:\n   - **inversion** — what if the invariant held by construction instead of by\n     check?\n   - **constraint removal** — drop a self-imposed limit and see what collapses.\n   - **simplification** — the smallest thing that could possibly work.\n   - **push-it-into-the-type-system** — make the bad state a compile error.\n   - **move-the-check-to-compile-time** — from runtime assert to trait bound \u002F\n     const \u002F typestate.\n   - **model-as-discriminated-union** — replace a bool or a stringly-typed flag\n     with an enum that makes invalid states unrepresentable. Keep them\n     considered, not shallow: 5-8 real options beat 20 throwaways.\n\n3. **LOCK INTENT (interview).** State a one-line hypothesis of what they want\n   plus a confidence level (and, below ~70%, one line on what is missing). Then\n   ask **ONE question at a time**, each carrying your current best guess so the\n   engineer reacts to a concrete wrong guess instead of generating from scratch:\n\n   ```\n   Q: Should an underfunded order be rejected at the API boundary or at ledger commit?\n   GUESS: at the API boundary, so the ledger only ever sees fundable orders.\n   ```\n\n   Reacting to a wrong guess is faster than answering an open prompt. Probe\n   **want vs. should-want**: when an answer leans on \"best practice\", \"make it\n   generic\", \"for future flexibility\", or \"we might need it later\", flag the\n   over-engineering tell against their YAGNI style and ask: \"if you did not have\n   to justify it to anyone, what would you actually want here?\"\n\n4. **SURFACE ASSUMPTIONS.** Emit an `ASSUMPTIONS` block and STOP for correction.\n   It must cover at least:\n   - **crate \u002F module boundaries** — where does this live, what does it depend\n     on, what depends on it.\n   - **on-chain vs off-chain split** — what runs in a contract vs a service.\n   - **units \u002F decimals** — token decimals, wei\u002Fgwei, basis points, cents vs\n     dollars, fixed-point scale.\n   - **error shapes** — `Result\u003C_, E>` variants, revert reasons, how failure is\n     represented.\n   - **nix target** — darwwwin (aarch64-darwin) vs nixxxos (x86_64-linux), if\n     relevant.\n\n   ```\n   ASSUMPTIONS (correct any that are wrong before I continue):\n   - Lives in `crates\u002Fsettlement`, called by the order intake service.\n   - Off-chain check; the contract stays the source of truth on commit.\n   - Amounts are u256 base units at the token's own decimals (no rescaling here).\n   - Failure is a typed `RejectReason` enum, not a bool \u002F Option.\n   - No nix target impact.\n   ```\n\n5. **CONVERGE.** Cluster the surviving options into 2-3 distinct directions.\n   Stress-test each against:\n   - **domain value** — does it serve the actual capability, or an\n     implementation detail?\n   - **money-safety \u002F invariants** — can it lose, double-count, or mis-scale\n     funds? What invariant must hold?\n   - **external-contract assumptions** — units, encoding, field presence, error\n     shapes of anything we do not own (an ABI, an RPC response, a bridge\n     message). Treat each as a guess until pinned.\n   - **feasibility** — can it actually be built with the tools and time?\n   - **coupling** — does it couple things that vary independently, or split\n     things that always change together?\n\n6. **VALIDATE.** For every surviving assumption, state _how_ it gets validated\n   in this engineer's terms — never a vague \"we should check\":\n   - a **failing test** (type-driven TDD: the test that compiles and fails),\n   - a **spike** (a throwaway branch to learn one thing, then deleted),\n   - a **forge \u002F testnet run** (`forge test`, `forge inspect`, a fork test),\n   - or **reading the actual contract \u002F ABI \u002F protocol doc** and citing it.\n\n7. **OUTPUT.** Reframe the ask into:\n   - **Testable success criteria, phrased as the first failing test** — \"the\n     order intake rejects an order whose total exceeds available balance with\n     `RejectReason::Underfunded`\" — concrete enough to drop straight into a\n     `#[test]` or a `forge` test.\n   - An explicit **Non-goals \u002F Out-of-scope** list. Then route it:\n   - **architectural decision** → draft `adrs\u002FNN-name.md` (next free `NN` from\n     `ls adrs\u002F`) and **STOP for review** before proceeding.\n   - **roadmap-level** → an epic-based entry (goal-first prose, then checkboxes;\n     never numbered \"Phase 1\u002F2\"; mermaid graph when streams run in parallel).\n   - **otherwise** → fold the criteria + non-goals into the GitHub issue body.\n\n8. **HAND OFF.** Pass the confirmed intent to the plan stage and to type-driven\n   TDD. This skill stops here. It does not plan the steps and it does not write\n   implementation code.\n\n## Common rationalizations\n\n| Excuse                                                       | Reality                                                                                                                                                            |\n| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| \"The ask is clear enough to start coding.\"                   | If you cannot write the first failing test in one line right now, it is not clear — run the interview.                                                             |\n| \"Asking questions is slower than just building it.\"          | Post-merge rework on the wrong abstraction costs far more than 4-6 guess-carrying questions. A wrong type that reaches `crates\u002F` propagates everywhere.            |\n| \"Let me make it generic so it is future-proof.\"              | That is a want-vs-should-want tell. YAGNI: shape for the capability you have evidence for; a discriminated union you can extend beats a generic you cannot delete. |\n| \"I will figure out the units \u002F decimals while implementing.\" | Decimals and encoding are exactly where money bugs hide. Pin them in the ASSUMPTIONS block before a line of code, not in a hotfix.                                 |\n| \"I will write the spec after I get it working.\"              | A spec written after the code just describes the code's accidents. Success criteria must exist as a failing test first, or they are not criteria.                  |\n| \"It's a small reversible change, skip the ceremony.\"         | Then skip the skill — shaping is for the irreversible or multi-file calls. Do not write a one-pager for a rename.                                                  |\n| \"They said 'whatever you think.'\"                            | That is not a yes. Offer two concrete directions as a choice; never let delegation substitute for locked intent.                                                   |\n\n## Red flags\n\n- Reframing or generating options before reading the issue, the source, `adrs\u002F`,\n  and `ROADMAP.md`.\n- Several questions in one message (that is surveying, not interviewing).\n- A question that carries no guess (you are extracting work from them, not\n  committing a testable prediction).\n- Confidence stated below ~70% with no one-line reason for the gap.\n- Proceeding past the ASSUMPTIONS block without an explicit correction or yes.\n- No Non-goals \u002F Out-of-scope list in the output.\n- A surviving assumption with no concrete validation (test \u002F spike \u002F forge run \u002F\n  cited doc) attached.\n- Success criteria written as prose intentions (\"handle errors gracefully\")\n  instead of a failing test you could paste into the suite.\n- An external boundary (ABI, RPC, bridge message, SDK return) whose units \u002F\n  encoding \u002F field presence is assumed but never cited or pinned to a test.\n- Drafting an ADR and then continuing to plan instead of STOPPING for review.\n- A roadmap entry with numbered \"Phase 1 \u002F Phase 2\" headings.\n- Producing the spec after the code already exists.\n\n## Hard rules\n\n1. **Gated on an explicit yes.** Reject \"whatever you think\", \"sounds good\", and\n   silence as terminal. Loop the restatement until you get an unambiguous yes.\n2. **Never fabricate CLI flags or values.** Run `--help` or read the config \u002F\n   source first. If you are unsure of a `cargo`, `forge`, `nix`, `but`, or `gh`\n   flag, say \"see `--help`\" — never invent one.\n3. **Not done without non-goals.** Every output carries an explicit Non-goals \u002F\n   Out-of-scope list.\n4. **Not done without per-assumption validation.** Every surviving assumption\n   names how it gets validated (failing test \u002F spike \u002F forge or testnet run \u002F\n   cited contract doc).\n5. **Emit a real artifact, not a generic one-pager.** An ADR at\n   `adrs\u002FNN-name.md` (then STOP for review) OR an epic-based roadmap entry\n   (never numbered phases; mermaid for parallel streams) OR locked criteria\n   folded into the tracker issue. The shape matches the decision.\n6. **This skill never plans and never codes.** Hand confirmed intent to the plan\n   stage and type-driven TDD. If you catch yourself writing implementation steps\n   or production code, stop — that is the next stage's job.\n\n## Failure modes\n\n- **Surveying.** Firing several questions at once, or asking any question that\n  carries no guess. The discipline is one guess-carrying question at a time.\n- **Yes-machine.** Treating the engineer's first phrasing as gospel and\n  affirming it. Your job is to stress-test against money-safety, coupling, and\n  external-contract assumptions — push back with specificity.\n- **Spec-after-code.** Producing success criteria once the implementation\n  already exists. The criteria must precede the code as a failing test.\n- **Over-shaping the trivial.** Writing an ASSUMPTIONS block and an ADR for a\n  small, reversible choice (a rename, a one-line config tweak). Shaping is for\n  the irreversible or multi-file work; skip it otherwise.\n- **Confidence theatre.** Stating a confidence number with no reasoning, or\n  grinding three-plus rounds with flat confidence instead of flagging that the\n  foundational ask itself is malformed.\n\n## Verification\n\nThe work is shaped only when ALL of these are concretely true (not \"seems\nshaped\"):\n\n- [ ] The tracker issue, the relevant source, `adrs\u002F`, and `ROADMAP.md` were\n      read before any reframing.\n- [ ] A one-line hypothesis with a confidence level was stated (sub-70% carries\n      a reason).\n- [ ] Questions were asked one at a time, each carrying a concrete guess.\n- [ ] At least one want-vs-should-want probe was deployed where an\n      over-engineering tell appeared.\n- [ ] An ASSUMPTIONS block (crate\u002Fmodule boundaries, on-chain vs off-chain,\n      units\u002Fdecimals, error shapes, nix target) was emitted and corrected.\n- [ ] Surviving directions were stress-tested against domain value,\n      money-safety\u002Finvariants, external-contract assumptions, feasibility, and\n      coupling.\n- [ ] Every surviving assumption names a concrete validation (failing test \u002F\n      spike \u002F forge or testnet run \u002F cited contract doc).\n- [ ] Output includes testable success criteria phrased as the first failing\n      test AND an explicit Non-goals \u002F Out-of-scope list.\n- [ ] The right artifact exists: `adrs\u002FNN-name.md` (STOPPED for review) OR an\n      epic-based roadmap entry OR criteria folded into the issue — never a\n      generic one-pager, never numbered phases.\n- [ ] The engineer gave an explicit yes; intent was handed to the plan stage,\n      not implemented here.\n","Shape vague work into testable success criteria and explicit non-goals BEFORE\nany plan, ADR, or multi-file change. This is the gate that stands between \"an\nidea\" and \"a plan\". It interviews, diverges, converges, and locks intent — it\nnever plans the implementation and never writes production code.\n\n## Core process\n\n1. **GROUND.** Read before writing a single word. Pull the tracker item first:\n   `gh issue view \u003CN>` for the project's GitHub issue. Then read the relevant\n   source modules, `ls adrs\u002F` and the matching `adrs\u002FNN-*.md`, and `ROADMAP.md`.\n   You cannot shape work you have not read. If the idea touches a crate you have\n   not opened, open it (Grep \u002F Glob \u002F Read) before reframing it.\n\n2. **DIVERGE (optional, when the framing itself is in doubt).** Reframe as a\n   How-Might-We that names _who it serves in domain terms_ (\"How might we let\n   the settlement engine reject an underfunded order before it touches the\n   ledger?\" — not \"How might we add validation?\"). Generate 5-8 variations\n   through lenses tuned to this engineer:\n   - **inversion** — what if the invariant held by construction instead of by\n     check?\n   - **constraint removal** — drop a self-imposed limit and see what collapses.\n   - **simplification** — the smallest thing that could possibly work.\n   - **push-it-into-the-type-system** — make the bad state a compile error.\n   - **move-the-check-to-compile-time** — from runtime assert to trait bound \u002F\n     const \u002F typestate.\n   - **model-as-discriminated-union** — replace a bool or a stringly-typed flag\n     with an enum that makes invalid states unrepresentable. Keep them\n     considered, not shallow: 5-8 real options beat 20 throwaways.\n\n3. **LOCK INTENT (interview).** State a one-line hypothesis of what they want\n   plus a confidence level (and, below ~70%, one line on what is missing). Then\n   ask **ONE question at a time**, each carrying your current best guess so the\n   engineer reacts to a concrete wrong guess instead of generating from scratch:\n\n   ```\n   Q: Should an underfunded order be rejected at the API boundary or at ledger commit?\n   GUESS: at the API boundary, so the ledger only ever sees fundable orders.\n   ```\n\n   Reacting to a wrong guess is faster than answering an open prompt. Probe\n   **want vs. should-want**: when an answer leans on \"best practice\", \"make it\n   generic\", \"for future flexibility\", or \"we might need it later\", flag the\n   over-engineering tell against their YAGNI style and ask: \"if you did not have\n   to justify it to anyone, what would you actually want here?\"\n\n4. **SURFACE ASSUMPTIONS.** Emit an `ASSUMPTIONS` block and STOP for correction.\n   It must cover at least:\n   - **crate \u002F module boundaries** — where does this live, what does it depend\n     on, what depends on it.\n   - **on-chain vs off-chain split** — what runs in a contract vs a service.\n   - **units \u002F decimals** — token decimals, wei\u002Fgwei, basis points, cents vs\n     dollars, fixed-point scale.\n   - **error shapes** — `Result\u003C_, E>` variants, revert reasons, how failure is\n     represented.\n   - **nix target** — darwwwin (aarch64-darwin) vs nixxxos (x86_64-linux), if\n     relevant.\n\n   ```\n   ASSUMPTIONS (correct any that are wrong before I continue):\n   - Lives in `crates\u002Fsettlement`, called by the order intake service.\n   - Off-chain check; the contract stays the source of truth on commit.\n   - Amounts are u256 base units at the token's own decimals (no rescaling here).\n   - Failure is a typed `RejectReason` enum, not a bool \u002F Option.\n   - No nix target impact.\n   ```\n\n5. **CONVERGE.** Cluster the surviving options into 2-3 distinct directions.\n   Stress-test each against:\n   - **domain value** — does it serve the actual capability, or an\n     implementation detail?\n   - **money-safety \u002F invariants** — can it lose, double-count, or mis-scale\n     funds? What invariant must hold?\n   - **external-contract assumptions** — units, encoding, field presence, error\n     shapes of anything we do not own (an ABI, an RPC response, a bridge\n     message). Treat each as a guess until pinned.\n   - **feasibility** — can it actually be built with the tools and time?\n   - **coupling** — does it couple things that vary independently, or split\n     things that always change together?\n\n6. **VALIDATE.** For every surviving assumption, state _how_ it gets validated\n   in this engineer's terms — never a vague \"we should check\":\n   - a **failing test** (type-driven TDD: the test that compiles and fails),\n   - a **spike** (a throwaway branch to learn one thing, then deleted),\n   - a **forge \u002F testnet run** (`forge test`, `forge inspect`, a fork test),\n   - or **reading the actual contract \u002F ABI \u002F protocol doc** and citing it.\n\n7. **OUTPUT.** Reframe the ask into:\n   - **Testable success criteria, phrased as the first failing test** — \"the\n     order intake rejects an order whose total exceeds available balance with\n     `RejectReason::Underfunded`\" — concrete enough to drop straight into a\n     `#[test]` or a `forge` test.\n   - An explicit **Non-goals \u002F Out-of-scope** list. Then route it:\n   - **architectural decision** → draft `adrs\u002FNN-name.md` (next free `NN` from\n     `ls adrs\u002F`) and **STOP for review** before proceeding.\n   - **roadmap-level** → an epic-based entry (goal-first prose, then checkboxes;\n     never numbered \"Phase 1\u002F2\"; mermaid graph when streams run in parallel).\n   - **otherwise** → fold the criteria + non-goals into the GitHub issue body.\n\n8. **HAND OFF.** Pass the confirmed intent to the plan stage and to type-driven\n   TDD. This skill stops here. It does not plan the steps and it does not write\n   implementation code.\n\n## Common rationalizations\n\n| Excuse                                                       | Reality                                                                                                                                                            |\n| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| \"The ask is clear enough to start coding.\"                   | If you cannot write the first failing test in one line right now, it is not clear — run the interview.                                                             |\n| \"Asking questions is slower than just building it.\"          | Post-merge rework on the wrong abstraction costs far more than 4-6 guess-carrying questions. A wrong type that reaches `crates\u002F` propagates everywhere.            |\n| \"Let me make it generic so it is future-proof.\"              | That is a want-vs-should-want tell. YAGNI: shape for the capability you have evidence for; a discriminated union you can extend beats a generic you cannot delete. |\n| \"I will figure out the units \u002F decimals while implementing.\" | Decimals and encoding are exactly where money bugs hide. Pin them in the ASSUMPTIONS block before a line of code, not in a hotfix.                                 |\n| \"I will write the spec after I get it working.\"              | A spec written after the code just describes the code's accidents. Success criteria must exist as a failing test first, or they are not criteria.                  |\n| \"It's a small reversible change, skip the ceremony.\"         | Then skip the skill — shaping is for the irreversible or multi-file calls. Do not write a one-pager for a rename.                                                  |\n| \"They said 'whatever you think.'\"                            | That is not a yes. Offer two concrete directions as a choice; never let delegation substitute for locked intent.                                                   |\n\n## Red flags\n\n- Reframing or generating options before reading the issue, the source, `adrs\u002F`,\n  and `ROADMAP.md`.\n- Several questions in one message (that is surveying, not interviewing).\n- A question that carries no guess (you are extracting work from them, not\n  committing a testable prediction).\n- Confidence stated below ~70% with no one-line reason for the gap.\n- Proceeding past the ASSUMPTIONS block without an explicit correction or yes.\n- No Non-goals \u002F Out-of-scope list in the output.\n- A surviving assumption with no concrete validation (test \u002F spike \u002F forge run \u002F\n  cited doc) attached.\n- Success criteria written as prose intentions (\"handle errors gracefully\")\n  instead of a failing test you could paste into the suite.\n- An external boundary (ABI, RPC, bridge message, SDK return) whose units \u002F\n  encoding \u002F field presence is assumed but never cited or pinned to a test.\n- Drafting an ADR and then continuing to plan instead of STOPPING for review.\n- A roadmap entry with numbered \"Phase 1 \u002F Phase 2\" headings.\n- Producing the spec after the code already exists.\n\n## Hard rules\n\n1. **Gated on an explicit yes.** Reject \"whatever you think\", \"sounds good\", and\n   silence as terminal. Loop the restatement until you get an unambiguous yes.\n2. **Never fabricate CLI flags or values.** Run `--help` or read the config \u002F\n   source first. If you are unsure of a `cargo`, `forge`, `nix`, `but`, or `gh`\n   flag, say \"see `--help`\" — never invent one.\n3. **Not done without non-goals.** Every output carries an explicit Non-goals \u002F\n   Out-of-scope list.\n4. **Not done without per-assumption validation.** Every surviving assumption\n   names how it gets validated (failing test \u002F spike \u002F forge or testnet run \u002F\n   cited contract doc).\n5. **Emit a real artifact, not a generic one-pager.** An ADR at\n   `adrs\u002FNN-name.md` (then STOP for review) OR an epic-based roadmap entry\n   (never numbered phases; mermaid for parallel streams) OR locked criteria\n   folded into the tracker issue. The shape matches the decision.\n6. **This skill never plans and never codes.** Hand confirmed intent to the plan\n   stage and type-driven TDD. If you catch yourself writing implementation steps\n   or production code, stop — that is the next stage's job.\n\n## Failure modes\n\n- **Surveying.** Firing several questions at once, or asking any question that\n  carries no guess. The discipline is one guess-carrying question at a time.\n- **Yes-machine.** Treating the engineer's first phrasing as gospel and\n  affirming it. Your job is to stress-test against money-safety, coupling, and\n  external-contract assumptions — push back with specificity.\n- **Spec-after-code.** Producing success criteria once the implementation\n  already exists. The criteria must precede the code as a failing test.\n- **Over-shaping the trivial.** Writing an ASSUMPTIONS block and an ADR for a\n  small, reversible choice (a rename, a one-line config tweak). Shaping is for\n  the irreversible or multi-file work; skip it otherwise.\n- **Confidence theatre.** Stating a confidence number with no reasoning, or\n  grinding three-plus rounds with flat confidence instead of flagging that the\n  foundational ask itself is malformed.\n\n## Verification\n\nThe work is shaped only when ALL of these are concretely true (not \"seems\nshaped\"):\n\n- [ ] The tracker issue, the relevant source, `adrs\u002F`, and `ROADMAP.md` were\n      read before any reframing.\n- [ ] A one-line hypothesis with a confidence level was stated (sub-70% carries\n      a reason).\n- [ ] Questions were asked one at a time, each carrying a concrete guess.\n- [ ] At least one want-vs-should-want probe was deployed where an\n      over-engineering tell appeared.\n- [ ] An ASSUMPTIONS block (crate\u002Fmodule boundaries, on-chain vs off-chain,\n      units\u002Fdecimals, error shapes, nix target) was emitted and corrected.\n- [ ] Surviving directions were stress-tested against domain value,\n      money-safety\u002Finvariants, external-contract assumptions, feasibility, and\n      coupling.\n- [ ] Every surviving assumption names a concrete validation (failing test \u002F\n      spike \u002F forge or testnet run \u002F cited contract doc).\n- [ ] Output includes testable success criteria phrased as the first failing\n      test AND an explicit Non-goals \u002F Out-of-scope list.\n- [ ] The right artifact exists: `adrs\u002FNN-name.md` (STOPPED for review) OR an\n      epic-based roadmap entry OR criteria folded into the issue — never a\n      generic one-pager, never numbered phases.\n- [ ] The engineer gave an explicit yes; intent was handed to the plan stage,\n      not implemented here.\n",{"name":5,"description":7,"allowed-tools":43,"user-invocable":51},[44,45,46,47,48,49,50],"Read","Grep","Glob","Bash(ls adrs *)","Bash(gh issue view *)","Write","Edit",true,"master","78a61ce3053fc3d49eefd21d7051baf0c300af2d","ai\u002Fskills\u002Fshape-work",0,"https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig","https:\u002F\u002Fgithub.com\u002F0xgleb","2026-11-13 14:58:56",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":51},[61,64,67],{"tool":62,"command":63},"npx","npx skills add 0xgleb\u002Fdotconfig --skill shape-work",{"tool":65,"command":66},"bunx","bunx skills add 0xgleb\u002Fdotconfig --skill shape-work",{"tool":68,"command":69},"pnpm","pnpm dlx skills add 0xgleb\u002Fdotconfig --skill shape-work","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Fshape-work\u002FSKILL.md",[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"index.json","REFERENCE","参考文档",652,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Femail\u002Fphishing\u002Fproofpoint\u002Fdetect\u002Findex.json",[79,101,124,149,174,190],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":38},"01M6DNKHP7NV7KR552KFZ6EW3R","worktree","Manage worktrees only for concurrent work by the owner or agents launched by the owner on the same repository, or for explicitly requested inventory and cleanup; never create one for isolation alone.","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Fworktree\u002FSKILL.md",[],[81,86,20,24,87,88,89,90,91,92,93,94,95,32,96,97,98,99,100],"create","worktrees","manage","inventory","repository","fix","git","only","cleanup","cd","isolation","ls","for","mkdir","true",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":38},"01M6DNKEGPR8F3BA95ZMWQ48V9","unslop","Rewrite draft prose before owner-facing replies, docs, issues, PR text, handoffs, or Telegram reports to remove AI tells while preserving facts, links, tone, and authority; auto-trigger on externally visible prose, but never on code, commands, logs, tool output, quoted sources, or user text.","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Funslop\u002FSKILL.md",[],[103,108,24,109,110,22,111,112,113,114,36,115,116,117,118,119,120,121,122,123],"draft","pr","remove","tool","issues","auto","rewrite","tone","telegram","sources","links","authority","logs","facts","output","replies",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":38},"01M6DNK9VFNJYKB6GMA15WJ3HZ","threat-model-first","Use at the START of a change that moves money, changes balances or custody, touches access control or signing, deserializes untrusted input, adds an external or on-chain integration, or wires an LLM tool. Design-time threat modeling that turns abuse cases into the first failing tests; it precedes the post-hoc security-review pass.","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Fthreat-model-first\u002FSKILL.md",[],[131,132,133,134,135,136,137,138,28,139,140,32,141,142,143,144,145,146,147,148],"model","threat model","threat","first","threat model first","chain","time","security-review","forge","access","cargo audit","review","change","audit","read","write","edit","modeling",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":160,"publishedAt":38},"01M6DNK6M72QAMH2TYVMPYJGDM","test-inspector","Auto-run for new or changed retained behavior, even without test changes, and for test, fixture, snapshot or mock changes; verify real happy-path and error-path coverage, expose false-confidence assertions and over-mocking, but do not perform general production-code correctness review.","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Ftest-inspector\u002FSKILL.md",[155],{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[37,161,162,163,113,164,32,36,142,165,145,166,167,168,169,170,171,92,172,173],"test inspector","fixture","do","false","run","coverage","error","number","URL","mktemp","snapshot","but","path",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":38},"01M6DNK3BPN73D003FFADEWJP5","strong-typing-inspector","Lightweight review — flags primitives used where a domain type already exists (e.g. String for a USD field when Usd exists) and missed newtype opportunities.","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Fstrong-typing-inspector\u002FSKILL.md",[],[181,182,37,183,109,184,145,185,186,92,187,21,32,188,142,189],"strong typing inspector","type","missed","domain","flags","grep","usd","primitives","newtype",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":199,"publishedAt":38},"01M6DNJZHG2RK3MC4VPB9KWPYF","spec-review","Critique existing specifications and design proposals, including whether their approach or addition is justified, and refine them through adversarial Pi review and authorized author revisions. Not for code review, implementation-plan sequencing, creating a design from scratch or minor copy edits.","https:\u002F\u002Fgithub.com\u002F0xgleb\u002Fdotconfig\u002Fblob\u002Fmaster\u002Fai\u002Fskills\u002Fspec-review\u002FSKILL.md",[196],{"categoryNo":197,"categoryName":198,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000007","代码审查",[200,201,142,202,203,204,205,206,28,207,36,98,208,209,210,211,212,213,214,215],"spec review","spec","plan","critique","code review","pi","refine","implementation","sequencing","specifications","proposals","scratch","Existing","author","From Scratch","adversarial"]