[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JP2V773BDPW337TFZXFW9F":3,"skill-same:01M6JP2V773BDPW337TFZXFW9F":93},{"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":58,"commitSha":59,"skillDirectory":60,"forksCount":14,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6JP2V773BDPW337TFZXFW9F","code-reviewing",null,"Structured code reviews enforcing DRY, KISS, YAGNI, SRP, best practices, and project conventions.","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\u002Fdata-scientist\u002Fskills\u002Fcode-reviewing\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"code","code reviewing","yagni","changes","my","reviews","you","dry","triggers","project","do","code review","good","check","feedback","best practices","project conventions","pr","commit","review","2026-11-10 10:12:30",false,"---\nname: code-reviewing\ndescription: \"Structured code reviews enforcing DRY, KISS, YAGNI, SRP, best practices, and project conventions.\"\nwhen_to_use: \"Triggers: review this code, code review, check my code, what do you think of this implementation, review this PR, is this code good, feedback on my code, review staged changes before commit.\"\n---\n\n# Code Reviewing\n\nPerform thorough, constructive code reviews that catch bugs, enforce principles, and improve code quality. Good reviews are specific, actionable, and educational — they explain *why*, not just *what*.\n\n## Review Process\n\n### Step 1: Understand the Context\n\nWhen the review target is local work, start from `git diff --stat` for the\nworking-tree changes. If it's empty (a clean tree, not a git repo) or the review\ntargets something else, such as pasted code or a PR, proceed with the code as\nprovided.\n\n**Called from the pre-commit gate?** When `verification-before-completion` routes\nhere before a commit, the review target is `git diff --staged` — the change about\nto be published, not the whole branch. Scope to it, keep the pass proportionate to\nwhat tripped the gate, and report findings in time to fix them before the commit.\n\nBefore reviewing line-by-line, understand the big picture:\n\n- **What is this code supposed to do?** Read the PR description, linked issue, or ask the user.\n- **What changed?** If reviewing a diff, understand the scope of changes — run the\n  full `git diff` (or `git diff --staged`) when the stat summary isn't enough.\n- **What's the surrounding code like?** Read adjacent files for conventions and patterns.\n\n**A review request often arrives with a symptom attached** — \"this endpoint is slow\",\n\"memory climbs overnight\". Review the code against what you can actually see and report\nthe defects you find, including the ones that plausibly explain the symptom. What you must\nnot do is assert that a defect you spotted *is* the cause: that claim needs measurement,\nwhich is `performance-optimization`'s work. Name the suspect, say it is unconfirmed, and\nkeep the review's findings standing on their own.\n\n### Step 2: First Pass — Structural Review\n\nLook at the forest before the trees. Check:\n\n- **Does the change belong here?** Is it in the right module\u002Ffile?\n- **Is the scope right?** Does it do one thing or is it mixing concerns?\n- **Is the approach sound?** Before nitpicking syntax, is the overall strategy correct?\n- **Are there missing pieces?** Tests? Documentation? Error handling? Migration?\n\n**Step outside the diff.** The most common AI slop is invisible in a single hunk —\nit only shows up repo-wide. For any new helper, block, command, or exported symbol in\nthe diff, run three greps before accepting it:\n- **A twin?** Grep the repo for an existing function\u002Fblock that already does this — AI\n  assistants generate a fourth copy instead of finding copies #1–3 (see `code-slop-cleanup`'s\n  *Reuse Before Write*).\n- **Any importer?** A newly-`export`ed symbol with no consumer is dead surface (often\n  exported just to silence the unused-symbol checker).\n- **Any consumer?** A new schema field, prop, or param that nothing reads or sets is\n  speculative plumbing — the API looks finished but is wired to nothing.\n- **A comment in the wrong place?** For any new comment block of four or more lines,\n  ask what it explains. System-level rationale — why the component exists, what was\n  rejected, how it relates to other services — belongs in an ADR or architecture doc\n  with the comment reduced to a pointer; a local invariant the types can't express\n  stays inline; a restatement of the code goes nowhere. The essay-in-a-header rots\n  unread and is unfindable by anyone grepping the docs for it.\n- **A reference nobody can resolve?** `Phase 2`, `CP1.3`, `T02`, `finding #17`,\n  `checkpoint 3\u002F5` in comments, names, or strings — check whether a **git-tracked**\n  document defines it (`git ls-files '*.md' | xargs grep -l`). Anchored, it's a real\n  cross-reference. Unanchored, it names a conversation the reader wasn't in: the\n  finding is \"write the meaning instead of the label\".\n- **Any doc still describing the old shape?** If the diff renames, removes, or adds\n  something a user types or configures — a flag, env var, endpoint, config key,\n  command, script, install step — grep the README and `docs\u002F` for it, old name\n  included. Check tables, diagrams, and layout blocks first: prose gets reread when\n  someone edits the feature, inventories don't.\n\nWhen the diff *is* documentation, review it against the code rather than for prose\nquality. The failure mode is a confident sentence nobody verified — check each claim\nagainst the file it describes, and treat an unverifiable one as a finding.\n\nAlso check the *unit being grown*, not just the hunk: adding 15 lines to an already\n800-line function or 200-line file is how god-functions form one reviewer-approved PR at\na time. Judge the total size after the change, not the size of the diff.\n\n### Step 3: Detailed Review\n\nReview the code against these categories, in order of importance. See [references\u002Freview-checklist.md](references\u002Freview-checklist.md) for the detailed checklist.\n\n**Severity levels for findings:**\n\n- ? **Blocker**: Must fix before merge (bugs, security issues, data loss risks) — including a doc the diff makes *wrong* where the doc is an instruction someone follows: install steps, setup commands, the API contract, config keys. A stale instruction fails for the next person, silently, and is worse than no instruction. **Secrets or real personal data in the diff are always blockers** — they survive removal in git history, so flag them before the commit, not after.\n- ? **Suggestion**: Should fix, significantly improves quality (principle violations, missing tests, docs the diff leaves incomplete rather than wrong, misplaced comment essays, unanchored internal terminology)\n- ? **Nit**: Optional improvement (naming, style, minor simplification)\n\n### Step 4: Present Findings\n\nStructure your review as:\n\n1. **Summary** (1-2 sentences: overall impression and most important finding)\n2. **Blockers** (if any — these must be addressed)\n3. **Suggestions** (improvements that meaningfully raise quality)\n4. **Nits** (optional, non-blocking)\n5. **Positive notes** (what's done well — this matters for morale and learning)\n\nFor each finding, provide:\n- The specific location (file and line\u002Ffunction)\n- What the issue is\n- Why it matters (link to principle)\n- A concrete suggestion for fixing it (show code when helpful)\n\n### Step 5: Offer to Help Fix\n\nAfter presenting findings, offer to help implement the suggested changes. Don't just criticize — help improve.\n\n## Review Dimensions\n\nThese are the lenses through which code is examined:\n\n**Correctness**: Does it work? Does it handle edge cases? Can it fail silently?\n\n**Design Principles**: DRY, KISS, YAGNI, SRP, functional independence. See [references\u002Freview-checklist.md](references\u002Freview-checklist.md).\n\n**Security**: Input validation, auth checks, SQL injection, XSS, secrets in code.\n\n**Performance**: Obvious N+1 queries, unnecessary allocations, missing indexes. Don't optimize prematurely, but flag clearly wasteful patterns.\n\n**Testability**: Is the code testable? Are there tests? Do tests test behavior or implementation?\n\n**Readability**: Can someone unfamiliar with this code understand it in one reading? Good naming, manageable function length, and comments that are both *why, not what* and **in the right place** — the why of a system belongs in an ADR the comment points at; the why of a line belongs on the line. Judge \"unfamiliar\" literally: a reader with the repo and nothing else, who was in none of the conversations that produced it.\n\n**Error Handling**: Are errors caught, logged, and handled appropriately? Are error messages helpful? See [references\u002Ferror-handling.md](references\u002Ferror-handling.md) for detailed patterns (null safety, exception context, caller-oriented exceptions).\n\n## Tone Guidelines\n\n- Be specific: \"This function does three things\" beats \"this could be cleaner\"\n- Be constructive: \"Consider extracting X into its own function because...\" beats \"this is messy\"\n- Ask questions when uncertain: \"Is this intentionally returning null here?\" invites discussion\n- Acknowledge good work: If something is well-written, say so\n- Propose, don't command: \"What do you think about...\" respects the author's judgment\n- Apply the Boy Scout Rule: note small cleanup opportunities near the changed code — a renamed variable, a dead import removed. These compound over time.\n\n## Cross-Skill References\n\n- `performance-optimization` — when a review turns up a suspected cause of a real latency or memory symptom, confirming it by measurement\n- `refactoring` — when the review surfaces code smells worth a structured cleanup\n- `code-slop-cleanup` — strip AI-slop patterns from the diff before (or instead of) debating them in review\n- `security-audit` — for a dedicated, deep security pass beyond the review checklist\n- `verification-before-completion` — verify the change actually runs before approving, not from the diff alone; also the pre-commit gate that routes staged diffs here\n- `architecture-design` — where a system-level rationale found in a comment belongs instead (an ADR)\n","# Code Reviewing\n\nPerform thorough, constructive code reviews that catch bugs, enforce principles, and improve code quality. Good reviews are specific, actionable, and educational — they explain *why*, not just *what*.\n\n## Review Process\n\n### Step 1: Understand the Context\n\nWhen the review target is local work, start from `git diff --stat` for the\nworking-tree changes. If it's empty (a clean tree, not a git repo) or the review\ntargets something else, such as pasted code or a PR, proceed with the code as\nprovided.\n\n**Called from the pre-commit gate?** When `verification-before-completion` routes\nhere before a commit, the review target is `git diff --staged` — the change about\nto be published, not the whole branch. Scope to it, keep the pass proportionate to\nwhat tripped the gate, and report findings in time to fix them before the commit.\n\nBefore reviewing line-by-line, understand the big picture:\n\n- **What is this code supposed to do?** Read the PR description, linked issue, or ask the user.\n- **What changed?** If reviewing a diff, understand the scope of changes — run the\n  full `git diff` (or `git diff --staged`) when the stat summary isn't enough.\n- **What's the surrounding code like?** Read adjacent files for conventions and patterns.\n\n**A review request often arrives with a symptom attached** — \"this endpoint is slow\",\n\"memory climbs overnight\". Review the code against what you can actually see and report\nthe defects you find, including the ones that plausibly explain the symptom. What you must\nnot do is assert that a defect you spotted *is* the cause: that claim needs measurement,\nwhich is `performance-optimization`'s work. Name the suspect, say it is unconfirmed, and\nkeep the review's findings standing on their own.\n\n### Step 2: First Pass — Structural Review\n\nLook at the forest before the trees. Check:\n\n- **Does the change belong here?** Is it in the right module\u002Ffile?\n- **Is the scope right?** Does it do one thing or is it mixing concerns?\n- **Is the approach sound?** Before nitpicking syntax, is the overall strategy correct?\n- **Are there missing pieces?** Tests? Documentation? Error handling? Migration?\n\n**Step outside the diff.** The most common AI slop is invisible in a single hunk —\nit only shows up repo-wide. For any new helper, block, command, or exported symbol in\nthe diff, run three greps before accepting it:\n- **A twin?** Grep the repo for an existing function\u002Fblock that already does this — AI\n  assistants generate a fourth copy instead of finding copies #1–3 (see `code-slop-cleanup`'s\n  *Reuse Before Write*).\n- **Any importer?** A newly-`export`ed symbol with no consumer is dead surface (often\n  exported just to silence the unused-symbol checker).\n- **Any consumer?** A new schema field, prop, or param that nothing reads or sets is\n  speculative plumbing — the API looks finished but is wired to nothing.\n- **A comment in the wrong place?** For any new comment block of four or more lines,\n  ask what it explains. System-level rationale — why the component exists, what was\n  rejected, how it relates to other services — belongs in an ADR or architecture doc\n  with the comment reduced to a pointer; a local invariant the types can't express\n  stays inline; a restatement of the code goes nowhere. The essay-in-a-header rots\n  unread and is unfindable by anyone grepping the docs for it.\n- **A reference nobody can resolve?** `Phase 2`, `CP1.3`, `T02`, `finding #17`,\n  `checkpoint 3\u002F5` in comments, names, or strings — check whether a **git-tracked**\n  document defines it (`git ls-files '*.md' | xargs grep -l`). Anchored, it's a real\n  cross-reference. Unanchored, it names a conversation the reader wasn't in: the\n  finding is \"write the meaning instead of the label\".\n- **Any doc still describing the old shape?** If the diff renames, removes, or adds\n  something a user types or configures — a flag, env var, endpoint, config key,\n  command, script, install step — grep the README and `docs\u002F` for it, old name\n  included. Check tables, diagrams, and layout blocks first: prose gets reread when\n  someone edits the feature, inventories don't.\n\nWhen the diff *is* documentation, review it against the code rather than for prose\nquality. The failure mode is a confident sentence nobody verified — check each claim\nagainst the file it describes, and treat an unverifiable one as a finding.\n\nAlso check the *unit being grown*, not just the hunk: adding 15 lines to an already\n800-line function or 200-line file is how god-functions form one reviewer-approved PR at\na time. Judge the total size after the change, not the size of the diff.\n\n### Step 3: Detailed Review\n\nReview the code against these categories, in order of importance. See [references\u002Freview-checklist.md](references\u002Freview-checklist.md) for the detailed checklist.\n\n**Severity levels for findings:**\n\n- ? **Blocker**: Must fix before merge (bugs, security issues, data loss risks) — including a doc the diff makes *wrong* where the doc is an instruction someone follows: install steps, setup commands, the API contract, config keys. A stale instruction fails for the next person, silently, and is worse than no instruction. **Secrets or real personal data in the diff are always blockers** — they survive removal in git history, so flag them before the commit, not after.\n- ? **Suggestion**: Should fix, significantly improves quality (principle violations, missing tests, docs the diff leaves incomplete rather than wrong, misplaced comment essays, unanchored internal terminology)\n- ? **Nit**: Optional improvement (naming, style, minor simplification)\n\n### Step 4: Present Findings\n\nStructure your review as:\n\n1. **Summary** (1-2 sentences: overall impression and most important finding)\n2. **Blockers** (if any — these must be addressed)\n3. **Suggestions** (improvements that meaningfully raise quality)\n4. **Nits** (optional, non-blocking)\n5. **Positive notes** (what's done well — this matters for morale and learning)\n\nFor each finding, provide:\n- The specific location (file and line\u002Ffunction)\n- What the issue is\n- Why it matters (link to principle)\n- A concrete suggestion for fixing it (show code when helpful)\n\n### Step 5: Offer to Help Fix\n\nAfter presenting findings, offer to help implement the suggested changes. Don't just criticize — help improve.\n\n## Review Dimensions\n\nThese are the lenses through which code is examined:\n\n**Correctness**: Does it work? Does it handle edge cases? Can it fail silently?\n\n**Design Principles**: DRY, KISS, YAGNI, SRP, functional independence. See [references\u002Freview-checklist.md](references\u002Freview-checklist.md).\n\n**Security**: Input validation, auth checks, SQL injection, XSS, secrets in code.\n\n**Performance**: Obvious N+1 queries, unnecessary allocations, missing indexes. Don't optimize prematurely, but flag clearly wasteful patterns.\n\n**Testability**: Is the code testable? Are there tests? Do tests test behavior or implementation?\n\n**Readability**: Can someone unfamiliar with this code understand it in one reading? Good naming, manageable function length, and comments that are both *why, not what* and **in the right place** — the why of a system belongs in an ADR the comment points at; the why of a line belongs on the line. Judge \"unfamiliar\" literally: a reader with the repo and nothing else, who was in none of the conversations that produced it.\n\n**Error Handling**: Are errors caught, logged, and handled appropriately? Are error messages helpful? See [references\u002Ferror-handling.md](references\u002Ferror-handling.md) for detailed patterns (null safety, exception context, caller-oriented exceptions).\n\n## Tone Guidelines\n\n- Be specific: \"This function does three things\" beats \"this could be cleaner\"\n- Be constructive: \"Consider extracting X into its own function because...\" beats \"this is messy\"\n- Ask questions when uncertain: \"Is this intentionally returning null here?\" invites discussion\n- Acknowledge good work: If something is well-written, say so\n- Propose, don't command: \"What do you think about...\" respects the author's judgment\n- Apply the Boy Scout Rule: note small cleanup opportunities near the changed code — a renamed variable, a dead import removed. These compound over time.\n\n## Cross-Skill References\n\n- `performance-optimization` — when a review turns up a suspected cause of a real latency or memory symptom, confirming it by measurement\n- `refactoring` — when the review surfaces code smells worth a structured cleanup\n- `code-slop-cleanup` — strip AI-slop patterns from the diff before (or instead of) debating them in review\n- `security-audit` — for a dedicated, deep security pass beyond the review checklist\n- `verification-before-completion` — verify the change actually runs before approving, not from the diff alone; also the pre-commit gate that routes staged diffs here\n- `architecture-design` — where a system-level rationale found in a comment belongs instead (an ADR)\n",{"name":5,"description":7,"when_to_use":57},"Triggers: review this code, code review, check my code, what do you think of this implementation, review this PR, is this code good, feedback on my code, review staged changes before commit.","main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fdata-scientist\u002Fskills\u002Fcode-reviewing","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":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill code-reviewing",{"tool":71,"command":72},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill code-reviewing",{"tool":74,"command":75},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill code-reviewing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdata-scientist\u002Fskills\u002Fcode-reviewing\u002FSKILL.md",true,[79,85,89],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"evals\u002Fevals.json","REFERENCE","参考文档",10966,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdata-scientist\u002Fskills\u002Fcode-reviewing\u002Fevals\u002Fevals.json",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Ferror-handling.md",4960,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdata-scientist\u002Fskills\u002Fcode-reviewing\u002Freferences\u002Ferror-handling.md",{"path":90,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Freview-checklist.md",12988,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdata-scientist\u002Fskills\u002Fcode-reviewing\u002Freferences\u002Freview-checklist.md",[94,133,158,181,214,240],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":113,"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",[100,103,106,107,110],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":108,"categoryName":109,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":111,"categoryName":112,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000040","财务",[114,115,116,117,118,119,120,121,122,123,124,125,40,126,127,128,129,130,131,132],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"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",[139],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[141,41,142,143,144,145,146,147,148,149,150,151,152,153,154,42,155,156,40,157],"working agreement","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","README","session","routines",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":165,"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",[164],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[166,167,168,169,170,171,114,172,143,50,173,174,146,175,150,176,177,178,179,180],"verification","verification before completion","brief","ready","fix","claim","workflow","text","route","message","merge","release","git","act","ship",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":194,"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",[187,190,191],{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":192,"categoryName":193,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",[195,196,197,198,199,200,201,202,203,204,205,206,148,207,208,209,210,211,212,213],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":218,"categories":219,"keywords":222,"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",[220,221],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[223,224,225,226,227,228,195,229,230,231,32,51,232,233,234,235,236,237,238,239],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":244,"categories":245,"keywords":251,"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",[246,247,248,249,250],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":192,"categoryName":193,"taxonomyType":29,"taxonomyTypeDesc":30},[195,252,253,254,255,256,116,257,258,172,32,259,260,118,261,262,42,263,264,40],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]