[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJ20J3TSPBGK1C5JEAXNJS":3,"skill-same:01M6QJ20J3TSPBGK1C5JEAXNJS":86},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":13,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":71,"install":72,"resources":85},"01M6QJ20J3TSPBGK1C5JEAXNJS","pre-commit-review",null,"Chain-combined skill that merges git-commit behavior with code-review judgment to create intelligent pre-commit workflow. Encapsulates the decision of WHEN to require review before commit, WHAT to check in pre-commit review, and HOW to structure commit workflow. Use when user mentions pre-commit review, commit with review, pre-commit checks, or when they want to establish commit quality gates. Triggers especially when user says \"should I review before commit?\", \"what should I check before committing?\", \"commit workflow\", or when they're unsure whether their commit is ready.","ImaginerLabs\u002Fskill-manager","ImaginerLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F214277308?v=4","01M6QGGDPNF15RMMT1RCFDH9FN","01M6QGGDTH5BY64DQ123NR8M33",0,"MIT","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fpre-commit-review\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"review","commit","pre commit review","pre commit","combined","check in","commit workflow","re","how to","chain","judgment","structure","ready","decision","how","code-review","git","code","create","workflow","2026-11-10 10:12:30",false,"---\nname: pre-commit-review\ndescription: >-\n  Chain-combined skill that merges git-commit behavior with code-review judgment to create intelligent pre-commit workflow. Encapsulates the decision of WHEN to require review before commit, WHAT to check in pre-commit review, and HOW to structure commit workflow. Use when user mentions pre-commit review, commit with review, pre-commit checks, or when they want to establish commit quality gates. Triggers especially when user says \"should I review before commit?\", \"what should I check before committing?\", \"commit workflow\", or when they're unsure whether their commit is ready.\ncategory: coding\npriority: P0\ntrigger_patterns:\n  - \"pre-commit review\"\n  - \"commit with review\"\n  - \"pre-commit check\"\n  - \"commit workflow\"\n  - \"commit quality\"\n  - \"before commit\"\n  - \"is my commit ready\"\n  - \"commit review\"\ncombines:\n  - git-commit\n  - code-review\n  - staged-code-review\n---\n\n# Pre-Commit Review — Intelligent Commit Quality Gates\n\n## Overview\n\nPre-commit-review is a **chain-combined behavioral specification skill** that merges:\n\n- `git-commit` — Intelligent commit behavior规范\n- `code-review` — Review judgment and criteria\n- `staged-code-review` — Focused pre-commit workflow\n\nThe core judgment it encapsulates: **\"When should I require review before committing, and what should that review cover?\"**\n\nThis skill doesn't just execute a workflow — it embodies the decision-making framework of an experienced developer who knows when commits need extra scrutiny.\n\n## Core Philosophy\n\n### The Commit Readiness Spectrum\n\nNot every commit needs review. This skill helps you navigate the spectrum:\n\n```\n┌─────────────┐     ┌──────────────┐     ┌─────────────┐\n│  Quick Fix  │ ──► │  Normal Push  │ ──► │  Major UX   │\n│  (instant)  │     │  (reviewed)  │     │  (reviewed) │\n└─────────────┘     └──────────────┘     └─────────────┘\n     │                    │                    │\n     │                    │                    │\n     ▼                    ▼                    ▼\n┌─────────────┐     ┌──────────────┐     ┌─────────────┐\n│ Any pattern │     │   Complex    │     │  Breaking   │\n│ Trivial fix │     │   logic      │     │  changes    │\n│ Doc updates │     │   Business   │     │  New API    │\n└─────────────┘     │   logic      │     └─────────────┘\n                    └──────────────┘\n```\n\n### The Pre-Commit Decision Tree\n\n```\n                    ┌─ Is this a hotfix?\n                    │   └─ NO → Continue\n                    │       └─ YES → Commit freely (but document)\n                    │\n                    └─ Does this affect other teams?\n                        └─ YES → Require review\n                        └─ NO → Continue\n                                │\n                                └─ Is logic complex (>10 lines changed)?\n                                    └─ YES → Recommend review\n                                    └─ NO → Continue\n                                            │\n                                            └─ Does this touch security\u002Fauth?\n                                                └─ YES → Require review\n                                                └─ NO → Commit freely\n```\n\n## Behavioral Specification\n\n### Phase 1: Pre-Commit Self-Review\n\nBefore EVERY commit, run through these checkpoints:\n\n#### 1.1 Staged Changes Analysis\n\n```bash\n# Review what you're about to commit\ngit diff --staged --stat\n\n# Check for unexpected changes\ngit diff --staged --name-only\n```\n\n**Ask yourself:**\n- Are all these changes intentional?\n- Are there any debug statements or console.logs?\n- Are there any .env or credentials files staged?\n\n#### 1.2 Code Quality Gates\n\nRun these checks mentally (or with tools):\n\n| Check | What to Look For |\n|-------|------------------|\n| Naming | Variables\u002Ffunctions clearly named? |\n| Complexity | Any function >20 lines doing multiple things? |\n| Comments | Comments explain WHY, not WHAT? |\n| Tests | Logic changes have corresponding tests? |\n| Types | New code properly typed (TypeScript)? |\n\n#### 1.3 Commit Message Check\n\nDoes your commit message follow convention?\n\n```\n\u003Ctype>(\u003Cscope>): \u003Csubject>\n\n[optional body]\n\n[optional footer]\n```\n\n**Check:**\n- Subject line ≤72 characters\n- Uses imperative mood (\"add\" not \"added\")\n- Describes WHAT changed, not HOW\n- Body explains WHY if non-obvious\n\n### Phase 2: Risk Assessment\n\nDetermine if this commit needs extra review:\n\n#### High-Risk Commits (Require Review)\n\n| Risk Type | Indicators | Action |\n|-----------|------------|--------|\n| Security | Auth, permissions, data handling | Mandatory review |\n| Data | Database, migrations, queries | Mandatory review |\n| API | Endpoint changes, contracts | Mandatory review |\n| Breaking | Public API, major behavior | Mandatory review |\n\n#### Medium-Risk Commits (Review Recommended)\n\n| Risk Type | Indicators | Action |\n|-----------|------------|--------|\n| Business | Core logic, calculations | Consider review |\n| Complex | Multi-file, non-trivial | Consider review |\n| Shared | Utils, shared components | Consider review |\n\n#### Low-Risk Commits (Self-Approve)\n\n| Type | Examples |\n|------|----------|\n| Chores | Deps, configs, build |\n| Docs | Readme, comments |\n| Fixes | Simple bug fixes (1-3 lines) |\n| Refactors | Rename, format (no logic) |\n\n### Phase 3: Quick Review Protocol\n\nWhen review IS needed, here's the focused protocol:\n\n#### What to Review (5 minutes max)\n\n1. **Correctness**: Does the code do what it claims?\n2. **Safety**: Any security or data integrity risks?\n3. **Clarity**: Can someone understand this in 6 months?\n4. **Tests**: Are there tests for the new logic?\n\n#### What NOT to Review (Save for later)\n\n- Style debates (use linters)\n- Minor nits (non-blocking)\n- \"I would have done it differently\" (opinion)\n- Future concerns (out of scope)\n\n## Commit Type Recommendations\n\nBased on risk assessment, here's when to use each type:\n\n| Type | When to Use | Review Needed? |\n|------|-------------|----------------|\n| `feat` | New features | Recommended |\n| `fix` | Bug fixes | Low risk: No \u002F High risk: Yes |\n| `docs` | Documentation | No |\n| `refactor` | Restructure (no behavior change) | Low risk: No \u002F Complex: Yes |\n| `perf` | Performance improvements | Recommended |\n| `test` | Adding tests | No |\n| `build` | Build system changes | Yes |\n| `ci` | CI\u002FCD changes | Yes |\n| `chore` | Maintenance | No |\n\n## The Pre-Commit Review Checklist\n\n```\nPRE-COMMIT REVIEW CHECKLIST\n==========================\n\n□ 1. Changes are intentional\n□ 2. No debug code (console.log, debugger)\n□ 3. No credentials or secrets\n□ 4. Code follows project conventions\n□ 5. Types are properly defined\n□ 6. Tests cover new logic\n□ 7. Commit message follows convention\n□ 8. Subject line ≤72 chars\n□ 9. Imperative mood used\n□ 10. Breaking changes documented\n\nRISK ASSESSMENT\n===============\n□ Security-sensitive changes?\n□ Data integrity affected?\n□ API contract changed?\n□ Breaking change?\n\nREVIEW REQUIRED? [ ] YES  [ ] NO\nIf YES, reviewer: _______________\n```\n\n## Integration with git-commit\n\nWhen using `git-commit`, extend it with pre-commit-review judgment:\n\n### Commit Flow\n\n```\n1. git add \u003Cfiles>\n2. Run pre-commit-review judgment\n3. Based on risk assessment:\n   - Low risk → Proceed with git commit\n   - Medium risk → Do quick self-review\n   - High risk → Find a reviewer first\n4. Write commit message (use convention)\n5. Execute commit\n```\n\n### Commit Message Template\n\n```markdown\n\u003Ctype>(\u003Cscope>): \u003Csubject>\n\n\u003Cbody>\n\n\u003Cfooter>\n---\nReviewed by: [reviewer]\nRisk level: [low\u002Fmedium\u002Fhigh]\nTests added: [yes\u002Fno]\nBreaking change: [yes\u002Fno]\n```\n\n## Common Scenarios\n\n### Scenario 1: \"Is this commit ready?\"\n\n```markdown\nAnalysis:\n- 3 files changed, 50 lines added\n- Touches authentication logic\n- Adds new API endpoint\n\nRisk: HIGH (security + API)\n\nRecommendation: Get review before committing.\n```\n\n### Scenario 2: \"Quick documentation fix\"\n\n```markdown\nAnalysis:\n- 1 file changed, 5 lines\n- Documentation only\n- No logic affected\n\nRisk: LOW\n\nRecommendation: Commit freely.\n```\n\n### Scenario 3: \"Refactoring a shared utility\"\n\n```markdown\nAnalysis:\n- 5 files changed\n- Shared utility used by 10+ places\n- No behavior change (rename\u002Fformat)\n\nRisk: MEDIUM (high blast radius)\n\nRecommendation: Self-review carefully, or get quick review from one person.\n```\n\n## Key Principles\n\n### 1. Review is a Gift\n\nCode review isn't criticism — it's collaboration. Frame it positively.\n\n### 2. Small Commits = Easy Reviews\n\nLarge commits are hard to review. If you need review, small commits are easier to approve.\n\n### 3. Trust, but Verify\n\nYour judgment about \"is this ready\" improves with experience. This skill helps you formalize that judgment.\n\n### 4. Context Matters\n\nThe same change might need review in one codebase but not another. Consider:\n- Team size\n- Code ownership\n- Release cadence\n- Risk tolerance\n\n### 5. When in Doubt, Review\n\nIf you're unsure whether to review, the answer is usually \"yes.\"\n\n## Relationship to Other Skills\n\n- `git-commit` — The commit execution skill this builds upon\n- `code-review` — Provides the review criteria\n- `staged-code-review` — Provides the focused review protocol\n- `safe-refactor` — Use before refactoring to ensure coverage\n- `test-think` — Use to determine what tests are needed\n","# Pre-Commit Review — Intelligent Commit Quality Gates\n\n## Overview\n\nPre-commit-review is a **chain-combined behavioral specification skill** that merges:\n\n- `git-commit` — Intelligent commit behavior规范\n- `code-review` — Review judgment and criteria\n- `staged-code-review` — Focused pre-commit workflow\n\nThe core judgment it encapsulates: **\"When should I require review before committing, and what should that review cover?\"**\n\nThis skill doesn't just execute a workflow — it embodies the decision-making framework of an experienced developer who knows when commits need extra scrutiny.\n\n## Core Philosophy\n\n### The Commit Readiness Spectrum\n\nNot every commit needs review. This skill helps you navigate the spectrum:\n\n```\n┌─────────────┐     ┌──────────────┐     ┌─────────────┐\n│  Quick Fix  │ ──► │  Normal Push  │ ──► │  Major UX   │\n│  (instant)  │     │  (reviewed)  │     │  (reviewed) │\n└─────────────┘     └──────────────┘     └─────────────┘\n     │                    │                    │\n     │                    │                    │\n     ▼                    ▼                    ▼\n┌─────────────┐     ┌──────────────┐     ┌─────────────┐\n│ Any pattern │     │   Complex    │     │  Breaking   │\n│ Trivial fix │     │   logic      │     │  changes    │\n│ Doc updates │     │   Business   │     │  New API    │\n└─────────────┘     │   logic      │     └─────────────┘\n                    └──────────────┘\n```\n\n### The Pre-Commit Decision Tree\n\n```\n                    ┌─ Is this a hotfix?\n                    │   └─ NO → Continue\n                    │       └─ YES → Commit freely (but document)\n                    │\n                    └─ Does this affect other teams?\n                        └─ YES → Require review\n                        └─ NO → Continue\n                                │\n                                └─ Is logic complex (>10 lines changed)?\n                                    └─ YES → Recommend review\n                                    └─ NO → Continue\n                                            │\n                                            └─ Does this touch security\u002Fauth?\n                                                └─ YES → Require review\n                                                └─ NO → Commit freely\n```\n\n## Behavioral Specification\n\n### Phase 1: Pre-Commit Self-Review\n\nBefore EVERY commit, run through these checkpoints:\n\n#### 1.1 Staged Changes Analysis\n\n```bash\n# Review what you're about to commit\ngit diff --staged --stat\n\n# Check for unexpected changes\ngit diff --staged --name-only\n```\n\n**Ask yourself:**\n- Are all these changes intentional?\n- Are there any debug statements or console.logs?\n- Are there any .env or credentials files staged?\n\n#### 1.2 Code Quality Gates\n\nRun these checks mentally (or with tools):\n\n| Check | What to Look For |\n|-------|------------------|\n| Naming | Variables\u002Ffunctions clearly named? |\n| Complexity | Any function >20 lines doing multiple things? |\n| Comments | Comments explain WHY, not WHAT? |\n| Tests | Logic changes have corresponding tests? |\n| Types | New code properly typed (TypeScript)? |\n\n#### 1.3 Commit Message Check\n\nDoes your commit message follow convention?\n\n```\n\u003Ctype>(\u003Cscope>): \u003Csubject>\n\n[optional body]\n\n[optional footer]\n```\n\n**Check:**\n- Subject line ≤72 characters\n- Uses imperative mood (\"add\" not \"added\")\n- Describes WHAT changed, not HOW\n- Body explains WHY if non-obvious\n\n### Phase 2: Risk Assessment\n\nDetermine if this commit needs extra review:\n\n#### High-Risk Commits (Require Review)\n\n| Risk Type | Indicators | Action |\n|-----------|------------|--------|\n| Security | Auth, permissions, data handling | Mandatory review |\n| Data | Database, migrations, queries | Mandatory review |\n| API | Endpoint changes, contracts | Mandatory review |\n| Breaking | Public API, major behavior | Mandatory review |\n\n#### Medium-Risk Commits (Review Recommended)\n\n| Risk Type | Indicators | Action |\n|-----------|------------|--------|\n| Business | Core logic, calculations | Consider review |\n| Complex | Multi-file, non-trivial | Consider review |\n| Shared | Utils, shared components | Consider review |\n\n#### Low-Risk Commits (Self-Approve)\n\n| Type | Examples |\n|------|----------|\n| Chores | Deps, configs, build |\n| Docs | Readme, comments |\n| Fixes | Simple bug fixes (1-3 lines) |\n| Refactors | Rename, format (no logic) |\n\n### Phase 3: Quick Review Protocol\n\nWhen review IS needed, here's the focused protocol:\n\n#### What to Review (5 minutes max)\n\n1. **Correctness**: Does the code do what it claims?\n2. **Safety**: Any security or data integrity risks?\n3. **Clarity**: Can someone understand this in 6 months?\n4. **Tests**: Are there tests for the new logic?\n\n#### What NOT to Review (Save for later)\n\n- Style debates (use linters)\n- Minor nits (non-blocking)\n- \"I would have done it differently\" (opinion)\n- Future concerns (out of scope)\n\n## Commit Type Recommendations\n\nBased on risk assessment, here's when to use each type:\n\n| Type | When to Use | Review Needed? |\n|------|-------------|----------------|\n| `feat` | New features | Recommended |\n| `fix` | Bug fixes | Low risk: No \u002F High risk: Yes |\n| `docs` | Documentation | No |\n| `refactor` | Restructure (no behavior change) | Low risk: No \u002F Complex: Yes |\n| `perf` | Performance improvements | Recommended |\n| `test` | Adding tests | No |\n| `build` | Build system changes | Yes |\n| `ci` | CI\u002FCD changes | Yes |\n| `chore` | Maintenance | No |\n\n## The Pre-Commit Review Checklist\n\n```\nPRE-COMMIT REVIEW CHECKLIST\n==========================\n\n□ 1. Changes are intentional\n□ 2. No debug code (console.log, debugger)\n□ 3. No credentials or secrets\n□ 4. Code follows project conventions\n□ 5. Types are properly defined\n□ 6. Tests cover new logic\n□ 7. Commit message follows convention\n□ 8. Subject line ≤72 chars\n□ 9. Imperative mood used\n□ 10. Breaking changes documented\n\nRISK ASSESSMENT\n===============\n□ Security-sensitive changes?\n□ Data integrity affected?\n□ API contract changed?\n□ Breaking change?\n\nREVIEW REQUIRED? [ ] YES  [ ] NO\nIf YES, reviewer: _______________\n```\n\n## Integration with git-commit\n\nWhen using `git-commit`, extend it with pre-commit-review judgment:\n\n### Commit Flow\n\n```\n1. git add \u003Cfiles>\n2. Run pre-commit-review judgment\n3. Based on risk assessment:\n   - Low risk → Proceed with git commit\n   - Medium risk → Do quick self-review\n   - High risk → Find a reviewer first\n4. Write commit message (use convention)\n5. Execute commit\n```\n\n### Commit Message Template\n\n```markdown\n\u003Ctype>(\u003Cscope>): \u003Csubject>\n\n\u003Cbody>\n\n\u003Cfooter>\n---\nReviewed by: [reviewer]\nRisk level: [low\u002Fmedium\u002Fhigh]\nTests added: [yes\u002Fno]\nBreaking change: [yes\u002Fno]\n```\n\n## Common Scenarios\n\n### Scenario 1: \"Is this commit ready?\"\n\n```markdown\nAnalysis:\n- 3 files changed, 50 lines added\n- Touches authentication logic\n- Adds new API endpoint\n\nRisk: HIGH (security + API)\n\nRecommendation: Get review before committing.\n```\n\n### Scenario 2: \"Quick documentation fix\"\n\n```markdown\nAnalysis:\n- 1 file changed, 5 lines\n- Documentation only\n- No logic affected\n\nRisk: LOW\n\nRecommendation: Commit freely.\n```\n\n### Scenario 3: \"Refactoring a shared utility\"\n\n```markdown\nAnalysis:\n- 5 files changed\n- Shared utility used by 10+ places\n- No behavior change (rename\u002Fformat)\n\nRisk: MEDIUM (high blast radius)\n\nRecommendation: Self-review carefully, or get quick review from one person.\n```\n\n## Key Principles\n\n### 1. Review is a Gift\n\nCode review isn't criticism — it's collaboration. Frame it positively.\n\n### 2. Small Commits = Easy Reviews\n\nLarge commits are hard to review. If you need review, small commits are easier to approve.\n\n### 3. Trust, but Verify\n\nYour judgment about \"is this ready\" improves with experience. This skill helps you formalize that judgment.\n\n### 4. Context Matters\n\nThe same change might need review in one codebase but not another. Consider:\n- Team size\n- Code ownership\n- Release cadence\n- Risk tolerance\n\n### 5. When in Doubt, Review\n\nIf you're unsure whether to review, the answer is usually \"yes.\"\n\n## Relationship to Other Skills\n\n- `git-commit` — The commit execution skill this builds upon\n- `code-review` — Provides the review criteria\n- `staged-code-review` — Provides the focused review protocol\n- `safe-refactor` — Use before refactoring to ensure coverage\n- `test-think` — Use to determine what tests are needed\n",{"name":5,"category":53,"combines":54,"priority":57,"description":7,"trigger_patterns":58},"coding",[55,43,56],"git-commit","staged-code-review","P0",[59,60,61,34,62,63,64,65],"pre-commit review","commit with review","pre-commit check","commit quality","before commit","is my commit ready","commit review","main","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Fcoding\u002Fpre-commit-review","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill pre-commit-review",{"tool":78,"command":79},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill pre-commit-review",{"tool":81,"command":82},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill pre-commit-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fpre-commit-review\u002FSKILL.md",true,[],[87,116,136,162,193,218],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":97,"publishedAt":48},"01M6QJCB2SD5KHC41ZDQC0GA1T","meeting-minutes","Generate concise, actionable meeting minutes for internal meetings. Includes metadata, attendees, agenda, decisions, action items (owner + due date), and follow-up steps.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fmeeting-minutes\u002FSKILL.md",[93,94],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":95,"categoryName":96,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000034","行政与办公人员",[98,99,100,101,102,103,104,105,106,107,89,66,108,109,110,111,112,113,114,115],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action","for",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":48},"01M6QJC71RRGTGNNFEHJG6S20G","documentation-writer","Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[],[123,124,125,101,102,103,126,127,128,129,130,131,66,39,132,133,134,112,113,135],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","authoring","software","principles","high",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":149,"publishedAt":48},"01M6QJC0V3C7C4R9768J1AJYWY","doc-coauthoring","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdoc-coauthoring\u002FSKILL.md",[142,145,146],{"categoryNo":143,"categoryName":144,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":147,"categoryName":148,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000036","内容创作者",[150,151,101,47,152,123,153,41,154,155,156,157,66,158,159,132,160,161,112,115],"doc coauthoring","doc","official","tasks","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":176,"publishedAt":48},"01M6QJBJ0YPVEWGEXZH3PJRRTT","code-review-workflow","Executes comprehensive 4-phase code review: basic review, quality check, bundle analysis, and test coverage. Should be used when the user mentions comprehensive code review, checking code quality, or reviewing staged changes with multi-phase analysis. This is the comprehensive review workflow, distinct from focused skills like frontend-code-review, staged-code-review, or code-change-test-designer.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-review-workflow\u002FSKILL.md",[168,171,174,175],{"categoryNo":169,"categoryName":170,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":172,"categoryName":173,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},[177,28,47,45,178,179,180,181,182,183,43,184,185,186,187,188,189,190,191,192],"code review","code review workflow","testing","frontend","test","change","code quality","analysis","check","coverage","quality check","basic","multi","comprehensive code review","with","phase",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":208,"publishedAt":48},"01M6QJB7XNHV3VEEQF4W7FMWF6","code-change-test-designer","Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes, and designs test cases covering main flows and edge cases. Should be used when the user mentions test coverage, designing tests for code changes, or analyzing diff\u002Fcommit for testing purposes. Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on test case design for code changes.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",[199,200,203,204,205],{"categoryNo":172,"categoryName":173,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":201,"categoryName":202,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},{"categoryNo":206,"categoryName":207,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[181,182,45,209,210,179,211,212,47,29,43,213,186,214,66,215,216,217,115,192],"designer","code change test designer","design","diffs","edge","diff","tests","flows","which",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":225,"publishedAt":48},"01M6QJB195WD7DCJWDMKWKB29S","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fskill-creator\u002FSKILL.md",[224],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[226,227,228,229,152,230,46,231,232,233,184,234,235,236,66,237,238,112,115,220],"skill creator","creator","performance","run evals","variance analysis","run","benchmark","Meta","improve","edit","evals","optimize","existing skill"]