[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHT8H36GG9PS51CSSWW1GP":3,"skill-same:01M6CHT8H36GG9PS51CSSWW1GP":103},{"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":30,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":66,"install":67,"resources":80},"01M6CHT8H36GG9PS51CSSWW1GP","reviewer",null,"[ADD v{{VERSION}}] Review code for spec compliance and quality — produces review report","MountainUnicorn\u002Fadd","MountainUnicorn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199411549?v=4","01M6CHRAWFWD275ANP1S2A0HXC","01M6CHRB0QE1678D913B438SAR",11,"MIT","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Freviewer\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[5,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"frontend","review","spec","telemetry","code","report","compliance","Bash","review code","quality","Rules","grep","read","version","backend","2026-11-10 10:12:30",false,"---\ndescription: \"[ADD v{{VERSION}}] Review code for spec compliance and quality — produces review report\"\nargument-hint: \"specs\u002F{feature}.md [--scope backend|frontend|full]\"\nallowed-tools: [Read, Glob, Grep, Bash]\nreferences: [\"skill-epilogue.md\", \"rules\u002Ftelemetry.md\"]\n---\n\n# ADD Reviewer Skill v{{VERSION}}\n\nConduct a comprehensive code review focused on specification compliance, code quality, and ADD methodology adherence. This is a READ-ONLY skill that produces a detailed structured review report.\n\n\u003C!-- cache-discipline: non-dispatching skill — no STABLE\u002FVOLATILE markers required per rules\u002Fcache-discipline.md. Invoked AS a sub-agent by \u002Fadd:tdd-cycle, which owns the cache-aware prompt layout. -->\n\n## Overview\n\nThe Reviewer analyzes implementation against the spec and quality standards without modifying code. It checks:\n- **Spec Compliance**: Every acceptance criterion has a corresponding passing test\n- **Code Quality**: Readability, maintainability, style adherence\n- **Test Coverage**: Edge cases, error conditions, user scenarios\n- **Architecture**: Separation of concerns, dependency management\n- **Error Handling**: Validation, exception handling, error messages\n- **Documentation**: Comments, docstrings, API clarity\n- **ADD Adherence**: Test coverage, traceability, naming conventions\n\n## Pre-Flight Checks\n\n1. **Verify spec file exists**\n   - Read spec at provided path\n   - Extract feature name, acceptance criteria, user test cases\n   - Identify scope (backend, frontend, or full system)\n\n2. **Verify implementation exists**\n   - Locate implementation files from spec or config\n   - Verify code files are readable\n   - Check for completeness (no placeholder files)\n\n3. **Verify tests exist and pass**\n   - Locate test files (tests\u002F or __tests__\u002F)\n   - Read test mapping file if available\n   - Run tests to confirm all passing: `npm test` or `python -m pytest`\n   - Halt if tests not passing (code not GREEN)\n\n4. **Load configuration**\n   - Read .add\u002Fconfig.json for:\n     - Code style rules\n     - Test coverage thresholds\n     - Quality standards\n     - Naming conventions\n\n5. **Determine review scope**\n   - Use --scope flag or infer from config\n   - backend: Server, API, database code\n   - frontend: UI, components, client code\n   - full: Everything\n\n6. **Check for session handoff** — per the Session-Handoff Preflight in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`\n\n## Execution Steps\n\n### Step 1: Spec Compliance Check\n\nFor each acceptance criterion:\n1. **Find corresponding test(s)**\n   - Search test files for test_AC_NNN_* pattern\n   - Verify test exists and has clear name mapping\n   - Check test mapping file for complete AC coverage\n\n2. **Verify test passes**\n   - Run the specific test to confirm it passes\n   - Check no tests are skipped or marked as pending\n\n3. **Examine test quality**\n   - Does it properly verify the AC requirement?\n   - Are assertions clear and specific?\n   - Does it test happy path AND error cases?\n\n4. **Find implementation code**\n   - Trace from test to code being tested\n   - Verify implementation code exists and matches test expectations\n   - Check function\u002Fclass names match test imports\n\n5. **Compare implementation to AC**\n   - Does implementation fulfill the acceptance criterion?\n   - All requirements met?\n   - Behavior matches specification?\n\nDocument findings:\n```\nAC-001: User can submit form with valid data\n  ✓ Test exists: test_AC_001_submit_valid_data\n  ✓ Test passes\n  ✓ Implementation found: submitForm() in src\u002Fform.ts\n  ✓ Behavior matches specification\n  Note: Good error message when validation fails\n```\n\n### Step 2: Code Quality Review\n\nExamine code for quality across dimensions:\n\n**Readability**\n- Are variable\u002Ffunction names clear and descriptive?\n- Is nesting depth reasonable (max 3-4 levels)?\n- Are long functions broken into smaller ones?\n- Is whitespace used effectively?\n- Example findings:\n  ```\n  ✓ Function names are clear (submitForm, validateEmail)\n  ✓ Variables well-named (userEmail, isValid)\n  ⚠ Long function parseFormData (120 lines) could be split\n  ```\n\n**Maintainability**\n- Is code DRY (Don't Repeat Yourself)?\n- Are there magic numbers or strings (should be constants)?\n- Is structure logical and easy to navigate?\n- Can code be extended without rewriting?\n- Example findings:\n  ```\n  ⚠ Email validation regex appears 3 times (use constant)\n  ⚠ API endpoint \"\u002Fapi\u002Fsubmit\" hard-coded in 2 places\n  ✓ Class structure is clear\n  ```\n\n**Style Adherence**\n- Does code follow .add\u002Fconfig.json conventions?\n- Consistent indentation, naming case, spacing?\n- Imports organized and sorted?\n- Example findings:\n  ```\n  ✓ Follows camelCase naming convention\n  ✓ Consistent 2-space indentation\n  ⚠ Missing trailing semicolons (config requires them)\n  ✓ Imports alphabetically sorted\n  ```\n\n**Error Handling**\n- Are inputs validated?\n- Are error messages helpful?\n- Are exceptions appropriate?\n- Is error recovery possible?\n- Example findings:\n  ```\n  ✓ Email input validated before submission\n  ⚠ Generic \"Error\" message instead of \"Invalid email format\"\n  ✓ Network error handled with retry logic\n  ```\n\n**Comments & Documentation**\n- Are complex sections commented?\n- Do public APIs have docstrings?\n- Are assumptions documented?\n- Are gotchas explained?\n- Example findings:\n  ```\n  ✓ Public functions have JSDoc comments\n  ⚠ Complex validation logic lacks explanation\n  ✓ Workaround for IE11 bug well-documented\n  ```\n\n### Step 3: Test Coverage Analysis\n\n1. **Coverage metrics**\n   - Check line coverage (default min 80%)\n   - Check branch coverage\n   - Check function coverage\n   - Report any below-threshold areas\n\n2. **AC-to-Test mapping**\n   - Verify every AC has at least one test\n   - Verify every UT is covered\n   - Identify orphaned test cases\n\n3. **Edge case coverage**\n   - Are error conditions tested?\n   - Are boundary values tested?\n   - Are invalid inputs tested?\n   - Example findings:\n     ```\n     ✓ Happy path tested\n     ✓ Network timeout tested\n     ⚠ Empty string input not tested\n     ✓ Maximum form size tested\n     ```\n\n4. **Test quality**\n   - Are tests independent (can run in any order)?\n   - Do tests have clear assertions?\n   - Are setup\u002Fteardown proper?\n   - Do tests test behavior, not implementation?\n\n### Step 4: Architecture & Design Review\n\n1. **Separation of concerns**\n   - Is business logic separated from UI\u002FAPI?\n   - Are cross-cutting concerns (logging, error handling) centralized?\n   - Are modules focused and single-purpose?\n\n2. **Dependency management**\n   - Are dependencies injected or hard-coded?\n   - Is module coupling loose?\n   - Are circular dependencies avoided?\n\n3. **Data structures**\n   - Are types\u002Finterfaces used properly?\n   - Is data validation centralized?\n   - Are models well-designed?\n\n4. **API design**\n   - Are public interfaces clean and intuitive?\n   - Are parameters well-named?\n   - Are return types appropriate?\n\n### Step 5: ADD Methodology Adherence\n\n1. **Test naming**\n   - Do tests follow `test_AC_NNN_description` pattern?\n   - Are test names descriptive?\n   - Can ACs be traced from test names?\n\n2. **Implementation traceability**\n   - Can tests be mapped to code?\n   - Can code be mapped back to ACs?\n   - Is traceability documented (mapping file)?\n\n3. **Spec-Test-Code alignment**\n   - Does code match spec requirements?\n   - Do tests verify code against spec?\n   - Is the chain unbroken?\n\n4. **Minimal implementation**\n   - Is code minimal (no over-engineering)?\n   - Are there unused code paths?\n   - Is there premature optimization?\n\n### Step 6: Security Review\n\nDepth scales with maturity level (read from `.add\u002Fconfig.json`):\n- **Alpha**: Spot-check — scan for obvious issues only\n- **Beta**: Systematic — full review, findings are advisory\n- **GA**: Comprehensive — full review, findings are blocking\n\n**Checks:**\n\n1. **Injection scanning**\n   - Search for unsanitized user input in SQL queries, shell commands, template literals, HTML output\n   - Use Grep to find patterns: `exec(`, `eval(`, raw SQL string concatenation, `innerHTML =`, `dangerouslySetInnerHTML`\n   - Check for parameterized queries \u002F prepared statements\n\n2. **Auth pattern review** (Beta+)\n   - Verify authentication checks on protected routes\u002Fendpoints\n   - Check for constant-time password\u002Ftoken comparison\n   - Verify session management (expiry, rotation, invalidation)\n   - Check JWT validation (signature, expiry, audience)\n\n3. **Data handling** (Beta+)\n   - Scan for PII logged to console or files (emails, passwords, tokens, SSNs)\n   - Verify sensitive data encrypted at rest and in transit\n   - Check for hardcoded credentials, API keys, connection strings\n   - Verify input validation on all external-facing boundaries\n\n4. **Dependency review** (Beta+)\n   - Check for known CVEs in dependencies (`npm audit` \u002F `pip audit` \u002F `cargo audit`)\n   - Flag outdated packages with known security patches\n   - Review new dependency additions for trustworthiness\n\n5. **Infrastructure** (GA)\n   - Verify rate limiting on public endpoints\n   - Check for secure headers (CORS, CSP, HSTS, X-Frame-Options)\n   - Verify HTTPS enforcement\n   - Check error responses don't leak internal details\n\n**Score**: X\u002F10 based on findings count and severity\n\n```\n## 6. SECURITY REVIEW ({maturity} depth)\n\nScore: 8\u002F10\n\n### Injection Scanning\n- ✓ No raw SQL concatenation found\n- ✓ All user input sanitized before template usage\n- ⚠ src\u002Fapi.ts:34 — input used in template literal without escaping\n\n### Auth Patterns (Beta+)\n- ✓ Protected routes have auth middleware\n- ✓ JWT validated with signature + expiry check\n- ⚠ src\u002Fauth.ts:89 — password comparison not constant-time\n\n### Data Handling (Beta+)\n- ✓ No PII in log statements\n- ✓ No hardcoded credentials\n- ✓ Input validation on all API endpoints\n\n### Dependencies (Beta+)\n- ✓ No known CVEs (npm audit clean)\n- ✓ All dependencies on latest patch versions\n```\n\n### Step 7: Performance Review\n\nOnly executed at **Beta and above**. At Alpha, this step is skipped entirely.\n- **Beta**: All checks advisory\n- **GA**: All checks blocking, performance tests and response time baselines required\n\n**Checks:**\n\n1. **N+1 query detection**\n   - Search for database queries inside loops (e.g., `for` \u002F `forEach` \u002F `map` containing query calls)\n   - Use Grep to find patterns: ORM calls (`.find(`, `.query(`, `.get(`) inside loop bodies\n   - Flag any query-per-iteration patterns\n\n2. **Blocking async detection**\n   - Search for synchronous I\u002FO in async contexts (`readFileSync`, `execSync`, blocking HTTP calls)\n   - Check for `await` inside loops where `Promise.all` could be used\n   - Flag CPU-intensive operations on the main thread \u002F event loop\n\n3. **Memory patterns**\n   - Check for unbounded caches or collections (growing arrays\u002Fmaps without eviction)\n   - Flag event listeners added without cleanup (missing `removeEventListener` \u002F `unsubscribe`)\n   - Check for closures holding large objects unnecessarily\n\n4. **Bundle size** (if applicable)\n   - Run `npm run build` or equivalent and check output size\n   - Flag unusually large bundles or missing tree-shaking\n   - Check for large dependencies that could be replaced with lighter alternatives\n\n5. **Performance tests** (GA only)\n   - Verify performance test suite exists\n   - Check for response time baseline definitions\n   - Verify benchmarks run and pass within thresholds\n\n**Score**: X\u002F10 based on findings count and severity\n\n```\n## 7. PERFORMANCE REVIEW (Beta+ only)\n\nScore: 9\u002F10\n\n### N+1 Detection\n- ✓ No queries inside loops found\n- ✓ Batch loading used for related entities\n\n### Async Patterns\n- ✓ No synchronous I\u002FO in async contexts\n- ⚠ src\u002Fbatch.ts:45 — sequential await in loop, consider Promise.all\n\n### Memory Patterns\n- ✓ Event listeners cleaned up in teardown\n- ✓ No unbounded collections detected\n\n### Bundle Size\n- ✓ Build output: 142KB gzipped (threshold: 500KB)\n- ✓ Tree-shaking active, no dead code detected\n```\n\n## Review Report Format\n\nGenerate a comprehensive structured report:\n\n```\n# Code Review Report\n\n## Feature\n{feature-name} v{spec-version}\n\n## Review Scope\nBackend [or Frontend or Full System]\n\n## Executive Summary\nOverall quality: {Excellent \u002F Good \u002F Fair \u002F Needs Work}\nSpec compliance: {percentage}%\nTest coverage: {percentage}%\nCode quality score: {N}\u002F10\nSecurity score: {N}\u002F10\nPerformance score: {N}\u002F10 (Beta+ only)\n\n---\n\n## 1. SPEC COMPLIANCE ✓\u002F{total}\n\n### Acceptance Criteria Coverage\n| AC ID | Description | Test | Status | Notes |\n|-------|-------------|------|--------|-------|\n| AC-001 | requirement | test_AC_001_* | ✓ Pass | Implementation aligns well |\n| AC-002 | requirement | test_AC_002_* | ✓ Pass | Edge case handled properly |\n\n### User Test Cases Coverage\n| UT ID | Scenario | Test | Status | Notes |\n|-------|----------|------|--------|-------|\n| UT-001 | user scenario | test_UT_001_* | ✓ Pass | Clear test naming |\n\n### Findings\n- ✓ All acceptance criteria have passing tests\n- ✓ All user test cases are covered\n- ⚠ [If any issues] AC-003 missing edge case test for empty input\n\n---\n\n## 2. CODE QUALITY\n\n### Readability\n- ✓ Function names are clear and descriptive\n- ✓ Variables use meaningful names\n- ✓ Code structure is logical\n- ⚠ [Issue] parseFormData() function is 120 lines, consider splitting\n- ⚠ [Issue] Magic string \"\u002Fapi\u002Fsubmit\" appears 3 times\n\n### Maintainability\n- ✓ DRY principle followed (no significant duplication)\n- ✓ Classes are focused and single-purpose\n- ⚠ [Issue] Email regex hard-coded in validator, should be constant\n\n### Style Adherence\n- ✓ Follows camelCase naming convention\n- ✓ Consistent indentation (2 spaces)\n- ✓ Imports alphabetically sorted\n- ⚠ [Issue] Missing trailing semicolons (config requires them)\n\n### Error Handling\n- ✓ Input validation on all entry points\n- ✓ Network errors handled with retry\n- ⚠ [Issue] Error messages are generic (\"Error\") instead of specific\n- ⚠ [Issue] Missing validation for email format\n\n### Documentation\n- ✓ Public functions have JSDoc comments\n- ✓ Complex logic commented\n- ⚠ [Issue] API endpoint contracts not documented\n- ⚠ [Issue] Missing README for module\n\n---\n\n## 3. TEST COVERAGE\n\n### Coverage Metrics\n- Line Coverage: 87% (target: 80%) ✓\n- Branch Coverage: 82% (target: 80%) ✓\n- Function Coverage: 100% ✓\n\n### Coverage Gaps\n- [If any] Lines 45-52 in form.ts not covered (error path)\n- [If any] Branch for IE11 workaround not tested\n\n### Edge Cases\n- ✓ Network timeout tested\n- ✓ Invalid email tested\n- ⚠ [Issue] Empty string input not tested\n- ✓ Maximum form size tested\n- ✓ Concurrent submissions tested\n\n### Test Quality\n- ✓ Tests are independent (pass in any order)\n- ✓ Setup\u002Fteardown properly isolated\n- ✓ Assertions are specific and clear\n- ✓ Tests verify behavior, not implementation\n\n---\n\n## 4. ARCHITECTURE & DESIGN\n\n### Separation of Concerns\n- ✓ Business logic separated from UI\n- ✓ API layer distinct from business logic\n- ✓ Validation centralized in one module\n\n### Dependency Management\n- ✓ Dependencies injected via constructors\n- ✓ No circular dependencies detected\n- ✓ Coupling is loose and appropriate\n\n### Data Structures\n- ✓ TypeScript interfaces used effectively\n- ✓ Models are well-defined\n- ✓ Type safety enforced\n\n### API Design\n- ✓ Public API is clean and intuitive\n- ✓ Parameters well-named and documented\n- ✓ Return types are appropriate\n\n---\n\n## 6. SECURITY REVIEW ({maturity} depth)\n\nScore: {N}\u002F10\n\n### Injection Scanning\n- {findings}\n\n### Auth Patterns (Beta+)\n- {findings}\n\n### Data Handling (Beta+)\n- {findings}\n\n### Dependencies (Beta+)\n- {findings}\n\n---\n\n## 7. PERFORMANCE REVIEW (Beta+ only)\n\nScore: {N}\u002F10\n\n### N+1 Detection\n- {findings}\n\n### Async Patterns\n- {findings}\n\n### Memory Patterns\n- {findings}\n\n### Bundle Size\n- {findings}\n\n---\n\n## 5. ADD METHODOLOGY\n\n### Test Naming & Traceability\n- ✓ Tests follow AC naming pattern (test_AC_NNN_*)\n- ✓ Test mapping file exists and is accurate\n- ✓ Can trace test → code → spec\n\n### Implementation Quality\n- ✓ Minimal viable implementation (no over-engineering)\n- ✓ No unused code paths\n- ✓ No premature optimization\n\n### Documentation\n- ✓ Test mapping file present and complete\n- ⚠ [If missing] No plan document (docs\u002Fplans\u002F{feature}-plan.md)\n\n---\n\n## ISSUES & RECOMMENDATIONS\n\n### Critical Issues (Must Fix)\n1. [Issue description] - Severity: High\n   - Location: {file}:{line}\n   - Impact: {explanation}\n   - Recommendation: {fix}\n\n### Major Issues (Should Fix)\n2. [Issue description] - Severity: Medium\n   - Location: {file}:{line}\n   - Recommendation: {fix}\n\n### Minor Issues (Nice to Have)\n3. [Issue description] - Severity: Low\n   - Location: {file}:{line}\n   - Recommendation: {fix}\n\n---\n\n## APPROVAL STATUS\n\n- [✓] Spec Compliance: All ACs implemented and tested\n- [✓] Test Coverage: Above minimum threshold\n- [✓] Code Quality: Acceptable for production\n- [✓] Security Review: No blocking findings\n- [✓] Performance Review: No blocking findings (Beta+ only)\n- [⚠] Ready for Production: [Yes \u002F Needs Fixes]\n\n---\n\n## Next Steps\n\n1. [Fix critical issues if any]\n2. Run \u002Fadd:tdd-cycle REFACTOR phase to address findings\n3. Re-review after fixes\n4. Proceed to staging deployment\n```\n\n## Notes on Review Approach\n\n1. **READ-ONLY**: This skill never modifies files\n2. **Objective**: Focus on facts (tests pass\u002Ffail, code exists\u002Fmissing)\n3. **Constructive**: Frame issues as opportunities for improvement\n4. **Actionable**: Provide specific recommendations\n5. **Evidence-based**: Cite line numbers, file paths, test results\n\n## Progress Tracking\n\n**Tasks to create** (mechanics per `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`):\n\n| Phase | Subject | activeForm |\n|-------|---------|------------|\n| Load | Loading spec and config | Loading spec and config... |\n| Spec compliance | Checking spec compliance | Checking spec compliance... |\n| Code quality | Reviewing code quality | Reviewing code quality... |\n| Test coverage | Analyzing test coverage | Analyzing test coverage... |\n| Architecture | Reviewing architecture | Reviewing architecture... |\n| Security | Running security review | Running security review... |\n| Performance | Running performance review | Running performance review... |\n| Report | Generating review report | Generating review report... |\n\n## Error Handling\n\n**Tests are not passing**\n- Halt review\n- Report which tests fail\n- Ask user to run \u002Fadd:tdd-cycle GREEN phase first\n\n**Spec file is incomplete**\n- Halt review\n- Report missing AC or UT definitions\n- Ask user to complete spec\n\n**Implementation files missing**\n- Halt review\n- Report which files are missing\n- Ask user to generate implementation\n\n**Code cannot be parsed**\n- Report syntax error\n- Provide file and line number\n- Ask user to fix syntax\n\n## Integration with TDD Cycle\n\n- This skill is invoked during REFACTOR phase of \u002Fadd:tdd-cycle\n- Input: Implementation files and passing tests\n- Output: Review report (conversation output only)\n- No file modifications\n- Report guides REFACTOR improvements\n\nEnd-of-skill epilogue: follow `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md` (observation + learning checkpoint + progress tracking). Note: this skill is READ-ONLY with respect to project code — the epilogue's observation line and learning entry are the only writes it makes.\n","# ADD Reviewer Skill v{{VERSION}}\n\nConduct a comprehensive code review focused on specification compliance, code quality, and ADD methodology adherence. This is a READ-ONLY skill that produces a detailed structured review report.\n\n\u003C!-- cache-discipline: non-dispatching skill — no STABLE\u002FVOLATILE markers required per rules\u002Fcache-discipline.md. Invoked AS a sub-agent by \u002Fadd:tdd-cycle, which owns the cache-aware prompt layout. -->\n\n## Overview\n\nThe Reviewer analyzes implementation against the spec and quality standards without modifying code. It checks:\n- **Spec Compliance**: Every acceptance criterion has a corresponding passing test\n- **Code Quality**: Readability, maintainability, style adherence\n- **Test Coverage**: Edge cases, error conditions, user scenarios\n- **Architecture**: Separation of concerns, dependency management\n- **Error Handling**: Validation, exception handling, error messages\n- **Documentation**: Comments, docstrings, API clarity\n- **ADD Adherence**: Test coverage, traceability, naming conventions\n\n## Pre-Flight Checks\n\n1. **Verify spec file exists**\n   - Read spec at provided path\n   - Extract feature name, acceptance criteria, user test cases\n   - Identify scope (backend, frontend, or full system)\n\n2. **Verify implementation exists**\n   - Locate implementation files from spec or config\n   - Verify code files are readable\n   - Check for completeness (no placeholder files)\n\n3. **Verify tests exist and pass**\n   - Locate test files (tests\u002F or __tests__\u002F)\n   - Read test mapping file if available\n   - Run tests to confirm all passing: `npm test` or `python -m pytest`\n   - Halt if tests not passing (code not GREEN)\n\n4. **Load configuration**\n   - Read .add\u002Fconfig.json for:\n     - Code style rules\n     - Test coverage thresholds\n     - Quality standards\n     - Naming conventions\n\n5. **Determine review scope**\n   - Use --scope flag or infer from config\n   - backend: Server, API, database code\n   - frontend: UI, components, client code\n   - full: Everything\n\n6. **Check for session handoff** — per the Session-Handoff Preflight in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`\n\n## Execution Steps\n\n### Step 1: Spec Compliance Check\n\nFor each acceptance criterion:\n1. **Find corresponding test(s)**\n   - Search test files for test_AC_NNN_* pattern\n   - Verify test exists and has clear name mapping\n   - Check test mapping file for complete AC coverage\n\n2. **Verify test passes**\n   - Run the specific test to confirm it passes\n   - Check no tests are skipped or marked as pending\n\n3. **Examine test quality**\n   - Does it properly verify the AC requirement?\n   - Are assertions clear and specific?\n   - Does it test happy path AND error cases?\n\n4. **Find implementation code**\n   - Trace from test to code being tested\n   - Verify implementation code exists and matches test expectations\n   - Check function\u002Fclass names match test imports\n\n5. **Compare implementation to AC**\n   - Does implementation fulfill the acceptance criterion?\n   - All requirements met?\n   - Behavior matches specification?\n\nDocument findings:\n```\nAC-001: User can submit form with valid data\n  ✓ Test exists: test_AC_001_submit_valid_data\n  ✓ Test passes\n  ✓ Implementation found: submitForm() in src\u002Fform.ts\n  ✓ Behavior matches specification\n  Note: Good error message when validation fails\n```\n\n### Step 2: Code Quality Review\n\nExamine code for quality across dimensions:\n\n**Readability**\n- Are variable\u002Ffunction names clear and descriptive?\n- Is nesting depth reasonable (max 3-4 levels)?\n- Are long functions broken into smaller ones?\n- Is whitespace used effectively?\n- Example findings:\n  ```\n  ✓ Function names are clear (submitForm, validateEmail)\n  ✓ Variables well-named (userEmail, isValid)\n  ⚠ Long function parseFormData (120 lines) could be split\n  ```\n\n**Maintainability**\n- Is code DRY (Don't Repeat Yourself)?\n- Are there magic numbers or strings (should be constants)?\n- Is structure logical and easy to navigate?\n- Can code be extended without rewriting?\n- Example findings:\n  ```\n  ⚠ Email validation regex appears 3 times (use constant)\n  ⚠ API endpoint \"\u002Fapi\u002Fsubmit\" hard-coded in 2 places\n  ✓ Class structure is clear\n  ```\n\n**Style Adherence**\n- Does code follow .add\u002Fconfig.json conventions?\n- Consistent indentation, naming case, spacing?\n- Imports organized and sorted?\n- Example findings:\n  ```\n  ✓ Follows camelCase naming convention\n  ✓ Consistent 2-space indentation\n  ⚠ Missing trailing semicolons (config requires them)\n  ✓ Imports alphabetically sorted\n  ```\n\n**Error Handling**\n- Are inputs validated?\n- Are error messages helpful?\n- Are exceptions appropriate?\n- Is error recovery possible?\n- Example findings:\n  ```\n  ✓ Email input validated before submission\n  ⚠ Generic \"Error\" message instead of \"Invalid email format\"\n  ✓ Network error handled with retry logic\n  ```\n\n**Comments & Documentation**\n- Are complex sections commented?\n- Do public APIs have docstrings?\n- Are assumptions documented?\n- Are gotchas explained?\n- Example findings:\n  ```\n  ✓ Public functions have JSDoc comments\n  ⚠ Complex validation logic lacks explanation\n  ✓ Workaround for IE11 bug well-documented\n  ```\n\n### Step 3: Test Coverage Analysis\n\n1. **Coverage metrics**\n   - Check line coverage (default min 80%)\n   - Check branch coverage\n   - Check function coverage\n   - Report any below-threshold areas\n\n2. **AC-to-Test mapping**\n   - Verify every AC has at least one test\n   - Verify every UT is covered\n   - Identify orphaned test cases\n\n3. **Edge case coverage**\n   - Are error conditions tested?\n   - Are boundary values tested?\n   - Are invalid inputs tested?\n   - Example findings:\n     ```\n     ✓ Happy path tested\n     ✓ Network timeout tested\n     ⚠ Empty string input not tested\n     ✓ Maximum form size tested\n     ```\n\n4. **Test quality**\n   - Are tests independent (can run in any order)?\n   - Do tests have clear assertions?\n   - Are setup\u002Fteardown proper?\n   - Do tests test behavior, not implementation?\n\n### Step 4: Architecture & Design Review\n\n1. **Separation of concerns**\n   - Is business logic separated from UI\u002FAPI?\n   - Are cross-cutting concerns (logging, error handling) centralized?\n   - Are modules focused and single-purpose?\n\n2. **Dependency management**\n   - Are dependencies injected or hard-coded?\n   - Is module coupling loose?\n   - Are circular dependencies avoided?\n\n3. **Data structures**\n   - Are types\u002Finterfaces used properly?\n   - Is data validation centralized?\n   - Are models well-designed?\n\n4. **API design**\n   - Are public interfaces clean and intuitive?\n   - Are parameters well-named?\n   - Are return types appropriate?\n\n### Step 5: ADD Methodology Adherence\n\n1. **Test naming**\n   - Do tests follow `test_AC_NNN_description` pattern?\n   - Are test names descriptive?\n   - Can ACs be traced from test names?\n\n2. **Implementation traceability**\n   - Can tests be mapped to code?\n   - Can code be mapped back to ACs?\n   - Is traceability documented (mapping file)?\n\n3. **Spec-Test-Code alignment**\n   - Does code match spec requirements?\n   - Do tests verify code against spec?\n   - Is the chain unbroken?\n\n4. **Minimal implementation**\n   - Is code minimal (no over-engineering)?\n   - Are there unused code paths?\n   - Is there premature optimization?\n\n### Step 6: Security Review\n\nDepth scales with maturity level (read from `.add\u002Fconfig.json`):\n- **Alpha**: Spot-check — scan for obvious issues only\n- **Beta**: Systematic — full review, findings are advisory\n- **GA**: Comprehensive — full review, findings are blocking\n\n**Checks:**\n\n1. **Injection scanning**\n   - Search for unsanitized user input in SQL queries, shell commands, template literals, HTML output\n   - Use Grep to find patterns: `exec(`, `eval(`, raw SQL string concatenation, `innerHTML =`, `dangerouslySetInnerHTML`\n   - Check for parameterized queries \u002F prepared statements\n\n2. **Auth pattern review** (Beta+)\n   - Verify authentication checks on protected routes\u002Fendpoints\n   - Check for constant-time password\u002Ftoken comparison\n   - Verify session management (expiry, rotation, invalidation)\n   - Check JWT validation (signature, expiry, audience)\n\n3. **Data handling** (Beta+)\n   - Scan for PII logged to console or files (emails, passwords, tokens, SSNs)\n   - Verify sensitive data encrypted at rest and in transit\n   - Check for hardcoded credentials, API keys, connection strings\n   - Verify input validation on all external-facing boundaries\n\n4. **Dependency review** (Beta+)\n   - Check for known CVEs in dependencies (`npm audit` \u002F `pip audit` \u002F `cargo audit`)\n   - Flag outdated packages with known security patches\n   - Review new dependency additions for trustworthiness\n\n5. **Infrastructure** (GA)\n   - Verify rate limiting on public endpoints\n   - Check for secure headers (CORS, CSP, HSTS, X-Frame-Options)\n   - Verify HTTPS enforcement\n   - Check error responses don't leak internal details\n\n**Score**: X\u002F10 based on findings count and severity\n\n```\n## 6. SECURITY REVIEW ({maturity} depth)\n\nScore: 8\u002F10\n\n### Injection Scanning\n- ✓ No raw SQL concatenation found\n- ✓ All user input sanitized before template usage\n- ⚠ src\u002Fapi.ts:34 — input used in template literal without escaping\n\n### Auth Patterns (Beta+)\n- ✓ Protected routes have auth middleware\n- ✓ JWT validated with signature + expiry check\n- ⚠ src\u002Fauth.ts:89 — password comparison not constant-time\n\n### Data Handling (Beta+)\n- ✓ No PII in log statements\n- ✓ No hardcoded credentials\n- ✓ Input validation on all API endpoints\n\n### Dependencies (Beta+)\n- ✓ No known CVEs (npm audit clean)\n- ✓ All dependencies on latest patch versions\n```\n\n### Step 7: Performance Review\n\nOnly executed at **Beta and above**. At Alpha, this step is skipped entirely.\n- **Beta**: All checks advisory\n- **GA**: All checks blocking, performance tests and response time baselines required\n\n**Checks:**\n\n1. **N+1 query detection**\n   - Search for database queries inside loops (e.g., `for` \u002F `forEach` \u002F `map` containing query calls)\n   - Use Grep to find patterns: ORM calls (`.find(`, `.query(`, `.get(`) inside loop bodies\n   - Flag any query-per-iteration patterns\n\n2. **Blocking async detection**\n   - Search for synchronous I\u002FO in async contexts (`readFileSync`, `execSync`, blocking HTTP calls)\n   - Check for `await` inside loops where `Promise.all` could be used\n   - Flag CPU-intensive operations on the main thread \u002F event loop\n\n3. **Memory patterns**\n   - Check for unbounded caches or collections (growing arrays\u002Fmaps without eviction)\n   - Flag event listeners added without cleanup (missing `removeEventListener` \u002F `unsubscribe`)\n   - Check for closures holding large objects unnecessarily\n\n4. **Bundle size** (if applicable)\n   - Run `npm run build` or equivalent and check output size\n   - Flag unusually large bundles or missing tree-shaking\n   - Check for large dependencies that could be replaced with lighter alternatives\n\n5. **Performance tests** (GA only)\n   - Verify performance test suite exists\n   - Check for response time baseline definitions\n   - Verify benchmarks run and pass within thresholds\n\n**Score**: X\u002F10 based on findings count and severity\n\n```\n## 7. PERFORMANCE REVIEW (Beta+ only)\n\nScore: 9\u002F10\n\n### N+1 Detection\n- ✓ No queries inside loops found\n- ✓ Batch loading used for related entities\n\n### Async Patterns\n- ✓ No synchronous I\u002FO in async contexts\n- ⚠ src\u002Fbatch.ts:45 — sequential await in loop, consider Promise.all\n\n### Memory Patterns\n- ✓ Event listeners cleaned up in teardown\n- ✓ No unbounded collections detected\n\n### Bundle Size\n- ✓ Build output: 142KB gzipped (threshold: 500KB)\n- ✓ Tree-shaking active, no dead code detected\n```\n\n## Review Report Format\n\nGenerate a comprehensive structured report:\n\n```\n# Code Review Report\n\n## Feature\n{feature-name} v{spec-version}\n\n## Review Scope\nBackend [or Frontend or Full System]\n\n## Executive Summary\nOverall quality: {Excellent \u002F Good \u002F Fair \u002F Needs Work}\nSpec compliance: {percentage}%\nTest coverage: {percentage}%\nCode quality score: {N}\u002F10\nSecurity score: {N}\u002F10\nPerformance score: {N}\u002F10 (Beta+ only)\n\n---\n\n## 1. SPEC COMPLIANCE ✓\u002F{total}\n\n### Acceptance Criteria Coverage\n| AC ID | Description | Test | Status | Notes |\n|-------|-------------|------|--------|-------|\n| AC-001 | requirement | test_AC_001_* | ✓ Pass | Implementation aligns well |\n| AC-002 | requirement | test_AC_002_* | ✓ Pass | Edge case handled properly |\n\n### User Test Cases Coverage\n| UT ID | Scenario | Test | Status | Notes |\n|-------|----------|------|--------|-------|\n| UT-001 | user scenario | test_UT_001_* | ✓ Pass | Clear test naming |\n\n### Findings\n- ✓ All acceptance criteria have passing tests\n- ✓ All user test cases are covered\n- ⚠ [If any issues] AC-003 missing edge case test for empty input\n\n---\n\n## 2. CODE QUALITY\n\n### Readability\n- ✓ Function names are clear and descriptive\n- ✓ Variables use meaningful names\n- ✓ Code structure is logical\n- ⚠ [Issue] parseFormData() function is 120 lines, consider splitting\n- ⚠ [Issue] Magic string \"\u002Fapi\u002Fsubmit\" appears 3 times\n\n### Maintainability\n- ✓ DRY principle followed (no significant duplication)\n- ✓ Classes are focused and single-purpose\n- ⚠ [Issue] Email regex hard-coded in validator, should be constant\n\n### Style Adherence\n- ✓ Follows camelCase naming convention\n- ✓ Consistent indentation (2 spaces)\n- ✓ Imports alphabetically sorted\n- ⚠ [Issue] Missing trailing semicolons (config requires them)\n\n### Error Handling\n- ✓ Input validation on all entry points\n- ✓ Network errors handled with retry\n- ⚠ [Issue] Error messages are generic (\"Error\") instead of specific\n- ⚠ [Issue] Missing validation for email format\n\n### Documentation\n- ✓ Public functions have JSDoc comments\n- ✓ Complex logic commented\n- ⚠ [Issue] API endpoint contracts not documented\n- ⚠ [Issue] Missing README for module\n\n---\n\n## 3. TEST COVERAGE\n\n### Coverage Metrics\n- Line Coverage: 87% (target: 80%) ✓\n- Branch Coverage: 82% (target: 80%) ✓\n- Function Coverage: 100% ✓\n\n### Coverage Gaps\n- [If any] Lines 45-52 in form.ts not covered (error path)\n- [If any] Branch for IE11 workaround not tested\n\n### Edge Cases\n- ✓ Network timeout tested\n- ✓ Invalid email tested\n- ⚠ [Issue] Empty string input not tested\n- ✓ Maximum form size tested\n- ✓ Concurrent submissions tested\n\n### Test Quality\n- ✓ Tests are independent (pass in any order)\n- ✓ Setup\u002Fteardown properly isolated\n- ✓ Assertions are specific and clear\n- ✓ Tests verify behavior, not implementation\n\n---\n\n## 4. ARCHITECTURE & DESIGN\n\n### Separation of Concerns\n- ✓ Business logic separated from UI\n- ✓ API layer distinct from business logic\n- ✓ Validation centralized in one module\n\n### Dependency Management\n- ✓ Dependencies injected via constructors\n- ✓ No circular dependencies detected\n- ✓ Coupling is loose and appropriate\n\n### Data Structures\n- ✓ TypeScript interfaces used effectively\n- ✓ Models are well-defined\n- ✓ Type safety enforced\n\n### API Design\n- ✓ Public API is clean and intuitive\n- ✓ Parameters well-named and documented\n- ✓ Return types are appropriate\n\n---\n\n## 6. SECURITY REVIEW ({maturity} depth)\n\nScore: {N}\u002F10\n\n### Injection Scanning\n- {findings}\n\n### Auth Patterns (Beta+)\n- {findings}\n\n### Data Handling (Beta+)\n- {findings}\n\n### Dependencies (Beta+)\n- {findings}\n\n---\n\n## 7. PERFORMANCE REVIEW (Beta+ only)\n\nScore: {N}\u002F10\n\n### N+1 Detection\n- {findings}\n\n### Async Patterns\n- {findings}\n\n### Memory Patterns\n- {findings}\n\n### Bundle Size\n- {findings}\n\n---\n\n## 5. ADD METHODOLOGY\n\n### Test Naming & Traceability\n- ✓ Tests follow AC naming pattern (test_AC_NNN_*)\n- ✓ Test mapping file exists and is accurate\n- ✓ Can trace test → code → spec\n\n### Implementation Quality\n- ✓ Minimal viable implementation (no over-engineering)\n- ✓ No unused code paths\n- ✓ No premature optimization\n\n### Documentation\n- ✓ Test mapping file present and complete\n- ⚠ [If missing] No plan document (docs\u002Fplans\u002F{feature}-plan.md)\n\n---\n\n## ISSUES & RECOMMENDATIONS\n\n### Critical Issues (Must Fix)\n1. [Issue description] - Severity: High\n   - Location: {file}:{line}\n   - Impact: {explanation}\n   - Recommendation: {fix}\n\n### Major Issues (Should Fix)\n2. [Issue description] - Severity: Medium\n   - Location: {file}:{line}\n   - Recommendation: {fix}\n\n### Minor Issues (Nice to Have)\n3. [Issue description] - Severity: Low\n   - Location: {file}:{line}\n   - Recommendation: {fix}\n\n---\n\n## APPROVAL STATUS\n\n- [✓] Spec Compliance: All ACs implemented and tested\n- [✓] Test Coverage: Above minimum threshold\n- [✓] Code Quality: Acceptable for production\n- [✓] Security Review: No blocking findings\n- [✓] Performance Review: No blocking findings (Beta+ only)\n- [⚠] Ready for Production: [Yes \u002F Needs Fixes]\n\n---\n\n## Next Steps\n\n1. [Fix critical issues if any]\n2. Run \u002Fadd:tdd-cycle REFACTOR phase to address findings\n3. Re-review after fixes\n4. Proceed to staging deployment\n```\n\n## Notes on Review Approach\n\n1. **READ-ONLY**: This skill never modifies files\n2. **Objective**: Focus on facts (tests pass\u002Ffail, code exists\u002Fmissing)\n3. **Constructive**: Frame issues as opportunities for improvement\n4. **Actionable**: Provide specific recommendations\n5. **Evidence-based**: Cite line numbers, file paths, test results\n\n## Progress Tracking\n\n**Tasks to create** (mechanics per `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`):\n\n| Phase | Subject | activeForm |\n|-------|---------|------------|\n| Load | Loading spec and config | Loading spec and config... |\n| Spec compliance | Checking spec compliance | Checking spec compliance... |\n| Code quality | Reviewing code quality | Reviewing code quality... |\n| Test coverage | Analyzing test coverage | Analyzing test coverage... |\n| Architecture | Reviewing architecture | Reviewing architecture... |\n| Security | Running security review | Running security review... |\n| Performance | Running performance review | Running performance review... |\n| Report | Generating review report | Generating review report... |\n\n## Error Handling\n\n**Tests are not passing**\n- Halt review\n- Report which tests fail\n- Ask user to run \u002Fadd:tdd-cycle GREEN phase first\n\n**Spec file is incomplete**\n- Halt review\n- Report missing AC or UT definitions\n- Ask user to complete spec\n\n**Implementation files missing**\n- Halt review\n- Report which files are missing\n- Ask user to generate implementation\n\n**Code cannot be parsed**\n- Report syntax error\n- Provide file and line number\n- Ask user to fix syntax\n\n## Integration with TDD Cycle\n\n- This skill is invoked during REFACTOR phase of \u002Fadd:tdd-cycle\n- Input: Implementation files and passing tests\n- Output: Review report (conversation output only)\n- No file modifications\n- Report guides REFACTOR improvements\n\nEnd-of-skill epilogue: follow `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md` (observation + learning checkpoint + progress tracking). Note: this skill is READ-ONLY with respect to project code — the epilogue's observation line and learning entry are the only writes it makes.\n",{"references":51,"description":7,"allowed-tools":54,"argument-hint":58},[52,53],"skill-epilogue.md","rules\u002Ftelemetry.md",[55,56,57,38],"Read","Glob","Grep","specs\u002F{feature}.md [--scope backend|frontend|full]","main","e335248c85d50f73919320bc138766eb413c5ee3","core\u002Fskills\u002Freviewer",6,"https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd","https:\u002F\u002Fgetadd.dev","https:\u002F\u002Fgithub.com\u002FMountainUnicorn","2026-10-31 22:03:50",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add MountainUnicorn\u002Fadd --skill reviewer",{"tool":73,"command":74},"bunx","bunx skills add MountainUnicorn\u002Fadd --skill reviewer",{"tool":76,"command":77},"pnpm","pnpm dlx skills add MountainUnicorn\u002Fadd --skill reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Freviewer\u002FSKILL.md",true,[81,87,91,95,99],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"roles\u002Farchitecture.md","REFERENCE","参考文档",2657,"https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002Froles\u002Farchitecture.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"roles\u002Finstructions.md",2993,"https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002Froles\u002Finstructions.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"roles\u002Fproject.md",2515,"https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002Froles\u002Fproject.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"roles\u002Froadmap.md",2112,"https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002Froles\u002Froadmap.md",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"roles\u002Fverification.md",2424,"https:\u002F\u002Fgithub.com\u002Ftbeack\u002Ffsad_playbook\u002Fblob\u002Fmain\u002Fskills\u002Fplan\u002Froles\u002Fverification.md",[104,112,117,122,132,153],{"skillNo":105,"name":106,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":46},"01M6CHXN68ZCGNXE9Q0K2T2RKX","add-verify","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-modified\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[110,111],"add verify","verify",{"skillNo":113,"name":106,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":46},"01M6CHXJY4ZXKTNP0235A9KTNH","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-missing\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[110,111],{"skillNo":118,"name":106,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":46},"01M6CHXG6NV1DBMWT2N6XE5555","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fhealthy\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[110,111],{"skillNo":123,"name":44,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":46},"01M6CHXDZFPEFBZ79GHP48S1BB","[ADD v0.11.0] Show installed version, project version, and upgrade status","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fversion\u002FSKILL.md",[],[44,42,128,34,38,41,129,43,130,131],"status","check","v0","show",{"skillNo":133,"name":111,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":142,"publishedAt":46},"01M6CHXB5XG415PP88E0GACHP8","[ADD v0.11.0] Run quality gates — lint, types, tests, coverage, spec compliance","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fverify\u002FSKILL.md",[137,140,141],{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},[111,42,43,143,144,130,145,146,41,34,33,147,148,149,150,37,151,38,152,40],"coverage","fix","smoke","gate","quality gates","run","lint","ci","secrets","learning",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":166,"publishedAt":46},"01M6CHX8JF3M3J8BKTBW604D37","ux","[ADD v0.11.0] Iterate on UI\u002FUX design before implementation — wireframes, flow validation, and design sign-off","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fux\u002FSKILL.md",[159,162,163],{"categoryNo":160,"categoryName":161,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":164,"categoryName":165,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师",[155,167,168,169,170,34,33,38,171,41,42,43,172,173,130,174,175,176,177],"ui","file","figma","validation","system","write","edit","design-system","implementation","flow","design"]