[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JNXXC4PRZHET47FGVRESSS":3,"skill-same:01M6JNXXC4PRZHET47FGVRESSS":87},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":14,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6JNXXC4PRZHET47FGVRESSS","project-review",null,"Review a built project's execution health before a milestone — scope alignment, roadmap \u002F execution-plan adherence, implementation maturity (what's production-ready vs stub\u002Fdeferred), and the evidence it actually works (tests, coverage, validation results, changelog). Use strategic-review for vision\u002Fpositioning\u002Fmarket; technical-debt-review for a pure code-health audit.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Farchitect\u002Fskills\u002Fproject-review\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"project","review","project review","stub","vision","audit","technical-debt","changelog","plan","milestone","maturity","code","drift","roadmap","positioning","production-ready","scope","ready","alignment","coverage","2026-11-10 10:12:30",false,"---\nname: project-review\ndescription: \"Review a built project's execution health before a milestone — scope alignment, roadmap \u002F execution-plan adherence, implementation maturity (what's production-ready vs stub\u002Fdeferred), and the evidence it actually works (tests, coverage, validation results, changelog). Use strategic-review for vision\u002Fpositioning\u002Fmarket; technical-debt-review for a pure code-health audit.\"\nwhen_to_use: \"Triggers: project review, execution review, are we on track, implementation vs roadmap, scope drift, readiness review, what's actually built, validation results review, pre-launch review.\"\ncontext: fork\nagent: general-purpose\n---\n\n# Project Review\n\nAssess how a project is actually executing against its own plan — what's built,\nwhat's claimed, what's proven, and where the gaps are. The output is an honest,\nprioritized execution picture a decision-maker can act on, not a code-by-code\ncritique. The discipline is **separating \"built\" from \"validated\" from\n\"planned\"** and refusing to let any of the three stand in for the others.\n\nThis is the **execution lens**. For vision, positioning, and market, run\n`strategic-review`; the two compose into a full pre-public \u002F pre-milestone review\n(see [templates\u002Ffull-review-prompt.md](..\u002Fstrategic-review\u002Ftemplates\u002Ffull-review-prompt.md)).\n\n## Ground rule: cite or label\n\nEvery claim is either **confirmed** (cite the file\u002Fpath\u002Fcommand output that proves\nit) or **inferred** (say so, and say from what). A reviewer who blurs the two is\nworse than no reviewer — the decision-maker can't tell evidence from optimism.\nNever report a capability as working unless you saw it work or saw a test that\nexercises it.\n\n## Step 1: Inventory the claims and the plan\n\nRead the project's own statements of intent before judging anything:\n\n- **Scope & status claims** — README, vision\u002Fstrategy docs, roadmap, execution\n  plan, CHANGELOG, milestone\u002Fissue tracker. What does the project say it is, what\n  phase does it say it's in, and what does it promise for the milestone in question?\n- **The hard boundaries** — declared scope and explicit non-goals. These are what\n  you measure scope drift against.\n- **The working agreement** — where the project says status lives and how\n  milestones close. If \"what's done\" can't be answered from where it says, or\n  there is no agreement, that is a finding: re-validate it with `working-agreement`.\n\nCapture this as the baseline. Everything downstream is \"reality vs this baseline.\"\n**The report opens with it**: a short list of what the project claims (scope,\nphase, milestone promises, headline numbers), each with its source, before any\nverdict. A bottom line that comes first has judged before the baseline exists.\nWhen the material was pasted in rather than readable, list it back from what was\ngiven. This is not a gate on delivering: write the baseline, then continue to\nStep 2 in the same response.\n\n## Step 2: Map implementation maturity\n\nWalk the actual code\u002Fartifacts and classify each major component:\n\n| Tier | Meaning | Signals |\n|------|---------|---------|\n| **Production-ready** | Built, integrated, tested | Real implementation, callers, tests, in CI |\n| **Functional \u002F thin** | Works but unproven or partial | Implemented, light\u002Fno tests, edge cases open |\n| **Stub \u002F scaffold** | Shape exists, behavior doesn't | `TODO`, `NotImplemented`, empty handlers, returns mock data |\n| **Deferred \u002F absent** | Named in the plan, not started | Referenced in docs\u002Froadmap, no code |\n\nBe specific: name the package\u002Fmodule\u002Fpath and the tier. The deliverable is a\nmaturity map, not a vibe. Grep for stub markers (`TODO`, `FIXME`, `raise\nNotImplementedError`, `throw new Error(\"not implemented\")`, `pass  # stub`).\n\n## Step 3: Reconcile against the roadmap — and find the drift\n\nLay the maturity map over the plan from Step 1:\n\n- **Ahead \u002F behind** — where is the code further along than the docs admit (common,\n  and a sign the strategy doc is stale), and where is it behind a milestone it\n  claims to have hit?\n- **Scope drift** — what got built that isn't in scope? What's in scope but\n  silently dropped? What crossed a declared non-goal boundary?\n- **Sequencing risk** — is load-bearing work scheduled after the milestone that\n  depends on it?\n\n## Step 4: Review the evidence it works\n\nThis is where most reviews are too generous. \"The code is built\" is not \"the\nconcept is validated.\" Assess the evidence chain:\n\n- **Tests** — do they exist for the load-bearing paths, or only happy paths?\n  Coverage numbers if available; quality, not just quantity.\n- **Validation \u002F experimental results** — if the project ran its own validation\n  (efficacy data, benchmarks, A\u002FB results, user trials), read the *actual numbers*\n  and report what they say, including when they're **negative or inconclusive**.\n  Foreground an uncomfortable result; don't bury it.\n- **CI \u002F checks** — does the pipeline actually gate, or is it advisory?\n- **The built-vs-validated gap** — state it explicitly: which capabilities are\n  built but unproven, and what evidence would close the gap?\n\n## Step 5: Prioritized execution findings\n\nProduce ranked, severity-tagged findings, each tied to its evidence:\n\n- **Severity** — Critical (blocks the milestone \u002F claim is false) \u002F High (material\n  risk) \u002F Medium (should fix) \u002F Low (note it).\n- **Each finding**: what, the evidence (cited), why it matters for the milestone,\n  and the smallest action that addresses it.\n- **An execution scorecard** — maturity, roadmap-adherence, evidence-strength,\n  each rated with a one-line justification, so the reader gets the picture at a glance.\n- **Hand off the market half.** When the review is for a launch, an announcement\n  or going public, end the findings with one line naming `strategic-review` for\n  vision, positioning and market, and do not answer those here, not even a\n  suggested launch framing. The execution findings stay complete in this answer;\n  only the market questions move.\n\n**Write the full report to a file** — default a gitignored location (e.g.\n`.local\u002Fproject-review-\u003Cdate>.md`) unless told otherwise — and state its path in\nyour final summary. This skill runs in a forked context: only the summary returns\nto the main conversation, so anything not written to disk is lost. If a judgment\ncall needs user input (ambiguous scope boundary, missing baseline docs, which\nmilestone to measure against), do **not** guess silently — record it in an\n**Open questions** section of the report and mention it in the summary.\n\nFor the rendered deliverable (interactive HTML report, dashboards, sortable\nfindings table), hand off to `artifact-design`.\n\n## Principles Applied\n\n- **Honesty over comfort** — a review that flatters the plan is worthless; lead\n  the findings with the most load-bearing problem, even when it undercuts the\n  project's thesis.\n- **Evidence over assertion** — confirmed vs inferred, always; cite the source.\n- **Prioritize** — a ranked short list of what matters beats an exhaustive catalog.\n- **Right altitude** — execution health, not line-level nits (that's `code-reviewing`).\n\n## Cross-Skill References\n\n- `strategic-review` — the other half of a pre-public review: vision, positioning, market.\n- `technical-debt-review` — when the question is purely codebase health \u002F remediation roadmap.\n- `code-reviewing` — for a specific diff or PR, not a whole-project assessment.\n- `metrics-and-okrs` — to turn findings into measurable readiness gates.\n- `artifact-design` — to render the review as a polished interactive report.\n","# Project Review\n\nAssess how a project is actually executing against its own plan — what's built,\nwhat's claimed, what's proven, and where the gaps are. The output is an honest,\nprioritized execution picture a decision-maker can act on, not a code-by-code\ncritique. The discipline is **separating \"built\" from \"validated\" from\n\"planned\"** and refusing to let any of the three stand in for the others.\n\nThis is the **execution lens**. For vision, positioning, and market, run\n`strategic-review`; the two compose into a full pre-public \u002F pre-milestone review\n(see [templates\u002Ffull-review-prompt.md](..\u002Fstrategic-review\u002Ftemplates\u002Ffull-review-prompt.md)).\n\n## Ground rule: cite or label\n\nEvery claim is either **confirmed** (cite the file\u002Fpath\u002Fcommand output that proves\nit) or **inferred** (say so, and say from what). A reviewer who blurs the two is\nworse than no reviewer — the decision-maker can't tell evidence from optimism.\nNever report a capability as working unless you saw it work or saw a test that\nexercises it.\n\n## Step 1: Inventory the claims and the plan\n\nRead the project's own statements of intent before judging anything:\n\n- **Scope & status claims** — README, vision\u002Fstrategy docs, roadmap, execution\n  plan, CHANGELOG, milestone\u002Fissue tracker. What does the project say it is, what\n  phase does it say it's in, and what does it promise for the milestone in question?\n- **The hard boundaries** — declared scope and explicit non-goals. These are what\n  you measure scope drift against.\n- **The working agreement** — where the project says status lives and how\n  milestones close. If \"what's done\" can't be answered from where it says, or\n  there is no agreement, that is a finding: re-validate it with `working-agreement`.\n\nCapture this as the baseline. Everything downstream is \"reality vs this baseline.\"\n**The report opens with it**: a short list of what the project claims (scope,\nphase, milestone promises, headline numbers), each with its source, before any\nverdict. A bottom line that comes first has judged before the baseline exists.\nWhen the material was pasted in rather than readable, list it back from what was\ngiven. This is not a gate on delivering: write the baseline, then continue to\nStep 2 in the same response.\n\n## Step 2: Map implementation maturity\n\nWalk the actual code\u002Fartifacts and classify each major component:\n\n| Tier | Meaning | Signals |\n|------|---------|---------|\n| **Production-ready** | Built, integrated, tested | Real implementation, callers, tests, in CI |\n| **Functional \u002F thin** | Works but unproven or partial | Implemented, light\u002Fno tests, edge cases open |\n| **Stub \u002F scaffold** | Shape exists, behavior doesn't | `TODO`, `NotImplemented`, empty handlers, returns mock data |\n| **Deferred \u002F absent** | Named in the plan, not started | Referenced in docs\u002Froadmap, no code |\n\nBe specific: name the package\u002Fmodule\u002Fpath and the tier. The deliverable is a\nmaturity map, not a vibe. Grep for stub markers (`TODO`, `FIXME`, `raise\nNotImplementedError`, `throw new Error(\"not implemented\")`, `pass  # stub`).\n\n## Step 3: Reconcile against the roadmap — and find the drift\n\nLay the maturity map over the plan from Step 1:\n\n- **Ahead \u002F behind** — where is the code further along than the docs admit (common,\n  and a sign the strategy doc is stale), and where is it behind a milestone it\n  claims to have hit?\n- **Scope drift** — what got built that isn't in scope? What's in scope but\n  silently dropped? What crossed a declared non-goal boundary?\n- **Sequencing risk** — is load-bearing work scheduled after the milestone that\n  depends on it?\n\n## Step 4: Review the evidence it works\n\nThis is where most reviews are too generous. \"The code is built\" is not \"the\nconcept is validated.\" Assess the evidence chain:\n\n- **Tests** — do they exist for the load-bearing paths, or only happy paths?\n  Coverage numbers if available; quality, not just quantity.\n- **Validation \u002F experimental results** — if the project ran its own validation\n  (efficacy data, benchmarks, A\u002FB results, user trials), read the *actual numbers*\n  and report what they say, including when they're **negative or inconclusive**.\n  Foreground an uncomfortable result; don't bury it.\n- **CI \u002F checks** — does the pipeline actually gate, or is it advisory?\n- **The built-vs-validated gap** — state it explicitly: which capabilities are\n  built but unproven, and what evidence would close the gap?\n\n## Step 5: Prioritized execution findings\n\nProduce ranked, severity-tagged findings, each tied to its evidence:\n\n- **Severity** — Critical (blocks the milestone \u002F claim is false) \u002F High (material\n  risk) \u002F Medium (should fix) \u002F Low (note it).\n- **Each finding**: what, the evidence (cited), why it matters for the milestone,\n  and the smallest action that addresses it.\n- **An execution scorecard** — maturity, roadmap-adherence, evidence-strength,\n  each rated with a one-line justification, so the reader gets the picture at a glance.\n- **Hand off the market half.** When the review is for a launch, an announcement\n  or going public, end the findings with one line naming `strategic-review` for\n  vision, positioning and market, and do not answer those here, not even a\n  suggested launch framing. The execution findings stay complete in this answer;\n  only the market questions move.\n\n**Write the full report to a file** — default a gitignored location (e.g.\n`.local\u002Fproject-review-\u003Cdate>.md`) unless told otherwise — and state its path in\nyour final summary. This skill runs in a forked context: only the summary returns\nto the main conversation, so anything not written to disk is lost. If a judgment\ncall needs user input (ambiguous scope boundary, missing baseline docs, which\nmilestone to measure against), do **not** guess silently — record it in an\n**Open questions** section of the report and mention it in the summary.\n\nFor the rendered deliverable (interactive HTML report, dashboards, sortable\nfindings table), hand off to `artifact-design`.\n\n## Principles Applied\n\n- **Honesty over comfort** — a review that flatters the plan is worthless; lead\n  the findings with the most load-bearing problem, even when it undercuts the\n  project's thesis.\n- **Evidence over assertion** — confirmed vs inferred, always; cite the source.\n- **Prioritize** — a ranked short list of what matters beats an exhaustive catalog.\n- **Right altitude** — execution health, not line-level nits (that's `code-reviewing`).\n\n## Cross-Skill References\n\n- `strategic-review` — the other half of a pre-public review: vision, positioning, market.\n- `technical-debt-review` — when the question is purely codebase health \u002F remediation roadmap.\n- `code-reviewing` — for a specific diff or PR, not a whole-project assessment.\n- `metrics-and-okrs` — to turn findings into measurable readiness gates.\n- `artifact-design` — to render the review as a polished interactive report.\n",{"name":5,"agent":57,"context":58,"description":7,"when_to_use":59},"general-purpose","fork","Triggers: project review, execution review, are we on track, implementation vs roadmap, scope drift, readiness review, what's actually built, validation results review, pre-launch review.","main","58de44ece4c8c756e2921aadf2a5d26199d61919","plugins\u002Farchitect\u002Fskills\u002Fproject-review","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill project-review",{"tool":73,"command":74},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill project-review",{"tool":76,"command":77},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill project-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Farchitect\u002Fskills\u002Fproject-review\u002FSKILL.md",true,[81],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Fevals.json","REFERENCE","参考文档",5290,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Farchitect\u002Fskills\u002Fproject-review\u002Fevals\u002Fevals.json",[88,128,153,176,209,234],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":107,"publishedAt":52},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[94,97,100,101,104],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":105,"categoryName":106,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000040","财务",[108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","triggers","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":52},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[136,32,137,138,41,139,140,141,142,143,144,145,146,147,148,149,150,151,120,152],"working agreement","definition of done","done","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":52},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[159],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[161,162,163,49,164,165,108,166,138,167,168,169,140,170,144,171,172,173,174,175],"verification","verification before completion","brief","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":189,"publishedAt":52},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[182,185,186],{"categoryNo":183,"categoryName":184,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":187,"categoryName":188,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[190,191,192,193,194,195,196,197,198,199,200,201,142,202,203,204,205,206,207,208],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":217,"publishedAt":52},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[215,216],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[218,219,220,221,222,223,190,224,225,226,43,33,227,37,228,229,230,231,232,233],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","threat model","security-audit","secure","config","go","security","trust",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":245,"publishedAt":52},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[240,241,242,243,244],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":183,"categoryName":184,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":187,"categoryName":188,"taxonomyType":26,"taxonomyTypeDesc":27},[190,246,247,248,51,249,110,250,251,166,43,252,40,112,253,254,149,255,256,120],"test suite","test","test suite design","unit","write tests","testing strategy","across","add","infrastructure","test plan","for"]