[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M719BZAT0GADPE6J5DMF3RFG":3,"skill-same:01M719BZAT0GADPE6J5DMF3RFG":66},{"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":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M719BZAT0GADPE6J5DMF3RFG","architectural-review",null,"How to review PRs for architectural quality — module boundaries, dependency direction, export surface, pattern consistency","DeDuva\u002Fsquad","DeDuva","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F8153108?v=4","01M719BQB25861D0TKS3RVHMN2","01M719BQBSWR380PSYDD5M9YD4",1,"MIT","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002F.copilot\u002Fskills\u002Farchitectural-review\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"review","architectural review","patterns","conventions","export","pattern","codebase","quality","instructions","dependency","how","review prs","architecture","module","how to","prs","copilot","for","direction","consistency","2026-11-10 10:12:30",false,"---\nname: \"architectural-review\"\ndescription: \"How to review PRs for architectural quality — module boundaries, dependency direction, export surface, pattern consistency\"\ndomain: \"architecture\"\nconfidence: \"medium\"\nsource: \"extracted from copilot-instructions.md patterns and codebase conventions\"\n---\n\n## Context\n\nWhen reviewing a PR that touches core architecture, the reviewer must verify that structural invariants are preserved. This skill covers **reviewing existing PRs** for architectural quality — not writing proposals (see `architectural-proposals\u002FSKILL.md` for that).\n\nUse this skill when a PR includes any of:\n- New modules, packages, or directories\n- Dependency changes (`package.json`, `import` additions across package boundaries)\n- API surface changes (new or modified exports from `index.ts` barrel files)\n- Cross-package imports (anything crossing the SDK\u002FCLI boundary)\n- New abstractions (interfaces, base classes, registries, factories)\n- Sweeping refactors (file renames, pattern migrations, bulk conversions)\n\n## Patterns\n\n### 1. Module Boundary Enforcement\n\nThe Squad codebase has two core packages with a strict dependency direction:\n\n```\nsquad-cli → depends on → squad-sdk\nsquad-sdk → NEVER depends on → squad-cli\n```\n\n**Check every new `import` statement in the PR:**\n- CLI files may import from SDK (`@bradygaster\u002Fsquad-sdk`)\n- SDK files must NEVER import from CLI\n- If a PR adds an SDK import that pulls in CLI code, reject it\n\n### 2. Zero-Dependency Bootstrap Contract\n\nThe CLI has **protected bootstrap files** that must use ONLY Node.js built-in modules (`node:fs`, `node:path`, `node:child_process`, `node:util`). These files run before the SDK is loaded.\n\n**Protected files (authoritative list from copilot-instructions.md):**\n\n| File | Purpose |\n|------|---------|\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Fdetect-squad-dir.ts` | Finds `.squad\u002F` at startup |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Ferrors.ts` | Error classes (`SquadError`, `fatal()`) |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Fgh-cli.ts` | GitHub CLI wrapper |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Foutput.ts` | Color\u002Femoji console output |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Fhistory-split.ts` | Portable knowledge separator |\n\n**Review checklist for bootstrap files:**\n- ❌ No new `import` or `require` of anything outside `node:*`\n- ❌ No conversion to `FSStorageProvider`, `StorageProvider`, or SDK abstractions\n- ✅ Look for `— zero dependencies` markers in file headers\n- ✅ If the PR adds a new bootstrap utility, it must be added to this table and have a zero-dependency regression test\n\n### 3. Export Surface Safety\n\nChanges to barrel files (`index.ts`) have downstream impact. Barrel files define the public API of a package.\n\n**Review checklist:**\n- **Adding exports:** Is the new export intentional? Does it expose implementation details that should stay internal?\n- **Removing exports:** Are downstream consumers accounted for? Removing an export is a breaking change.\n- **Renaming exports:** Same as remove + add — breaks anyone using the old name. Look for typos (e.g., `FSStorageProvidr` vs. `FSStorageProvider`).\n- **Re-exports:** If the PR adds `export * from '.\u002Finternal-module'`, verify that the internal module doesn't accidentally expose private types.\n\n### 4. Sweeping Refactor Safety\n\nWhen a PR applies a codebase-wide pattern change (e.g., \"convert all `fs` calls to `StorageProvider`\"), verify the 5-step checklist from project instructions:\n\n1. **Protected Files checked** — None of the protected bootstrap files were converted\n2. **Zero-dependency markers scanned** — Files with `— zero dependencies` headers were skipped\n3. **Imports resolve** — Every `import { X } from '@bradygaster\u002Fsquad-sdk'` references an export that actually exists in the SDK barrel file\n4. **Not blindly applied** — File-specific constraints were respected\n5. **Batched testing** — Changes were tested in logical groups, not all 30 files at once\n\n### 5. Template Sync Awareness\n\nTemplate files exist in **four locations** and must stay consistent:\n\n```\ntemplates\u002F                          # Source of truth\n.squad-templates\u002F                   # Local project templates\npackages\u002Fsquad-cli\u002Ftemplates\u002F       # CLI-bundled templates\n.github\u002Fworkflows\u002F                  # Workflow templates\n```\n\nIf a PR modifies a template in one location, check:\n- Was the change mirrored to other locations where the same template exists?\n- Does `TEMPLATE_MANIFEST` in `templates.ts` still correctly map files to agents?\n- Were any new templates added to the manifest?\n\n### 6. `.squad\u002F` Leakage Check\n\n`.squad\u002F` files (team config, decisions, agent charters) must NOT leak into feature PRs that are about code changes.\n\n**Check:**\n- If the PR is labeled as a feature or bugfix, it should not modify `.squad\u002Fteam.md`, `.squad\u002Fdecisions.md`, `.squad\u002Frouting.md`, or agent charters — unless the issue specifically calls for it\n- `.squad\u002Fdecisions\u002Finbox\u002F` files are acceptable if the PR documents a decision made during implementation\n- `.squad-templates\u002F` changes are acceptable only if the PR is about template functionality\n\n### 7. Pattern Consistency\n\nNew code should follow established patterns in the codebase. Look for:\n- **Naming conventions:** Does the new module follow existing naming? (e.g., `kebab-case` file names, `PascalCase` classes)\n- **Error handling:** Does the new code use `SquadError` and `fatal()` from `errors.ts`, or does it invent its own error patterns?\n- **Storage abstraction:** Does the new code use `StorageProvider` for file I\u002FO (except in protected bootstrap files)?\n- **Test patterns:** Does the PR include tests that follow the existing test structure?\n\n### 8. Dependency Direction in `core\u002F`\n\nThe `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002F` directory contains a **mix** of:\n- Early-startup bootstrap utilities (zero external deps — protected)\n- Later SDK-dependent modules (may import from SDK)\n\nWhen reviewing changes to `core\u002F` files:\n- Verify the file is not in the protected list before accepting SDK imports\n- Confirm the SDK is loaded at the point where the file runs in the startup sequence\n- Watch for new files added to `core\u002F` — determine if they are bootstrap or post-SDK and document accordingly\n\n## Examples\n\n**Example 1: Reject — SDK import in bootstrap file**\n```\nPR adds to detect-squad-dir.ts:\n  import { FSStorageProvider } from '@bradygaster\u002Fsquad-sdk';\n\nFinding: REJECT — detect-squad-dir.ts is a protected bootstrap file.\nIt runs before the SDK is loaded. This import will crash the CLI at startup.\nRecommendation: Use node:fs directly. See Protected Files table.\n```\n\n**Example 2: Reject — Reverse dependency**\n```\nPR adds to packages\u002Fsquad-sdk\u002Fsrc\u002Fstorage.ts:\n  import { detectSquadDir } from '@bradygaster\u002Fsquad-cli';\n\nFinding: REJECT — SDK must never depend on CLI. Dependency direction is\nCLI → SDK, not reverse. Move the shared logic to SDK or extract to a\nshared utility within the SDK package.\n```\n\n**Example 3: Approve with note — Template change in one location**\n```\nPR modifies templates\u002Fsquad.agent.md but not .squad-templates\u002Fsquad.agent.md\n\nFinding: APPROVE with note — Template was updated in templates\u002F but the\nsame file in .squad-templates\u002F was not synced. Verify whether .squad-templates\u002F\nshould match or if it intentionally diverges.\n```\n\n**Example 4: Reject — Sweeping refactor hits protected file**\n```\nPR titled \"Convert all fs calls to StorageProvider\" modifies 15 files,\nincluding packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Foutput.ts\n\nFinding: REJECT — output.ts is a protected zero-dependency bootstrap file.\nThe PR must skip this file. See Sweeping Refactor Rules step 1.\n```\n\n**Example 5: Flag — Mass file deletion**\n```\nPR deletes 25 files as part of \"cleanup unused modules\"\n\nFinding: FLAG — More than 20 files deleted. This exceeds the red flag\nthreshold. Verify each deletion is intentional and no downstream imports\nare broken. Recommend splitting into smaller PRs.\n```\n\n## Review Output Format\n\nStructure your architectural review as:\n\n```\n## Architectural Review\n\n**Verdict:** APPROVE | APPROVE WITH NOTES | REQUEST CHANGES | REJECT\n\n### Findings\n\n1. [severity: critical|high|medium|low] — description\n   - File(s): path\u002Fto\u002Ffile.ts\n   - Recommendation: what to fix\n\n2. [severity: ...] — ...\n\n### Summary\nBrief explanation of architectural impact and any required follow-ups.\n```\n\n## Anti-Patterns\n\n- ❌ Approving SDK imports in protected bootstrap files (\"it's just one import\")\n- ❌ Ignoring barrel file changes (\"it's just adding an export\")\n- ❌ Skipping template sync check (\"they probably know about the other locations\")\n- ❌ Accepting sweeping refactors without verifying the 5-step checklist\n- ❌ Allowing `.squad\u002F` config changes in feature PRs without justification\n- ❌ Approving reverse dependencies (SDK importing from CLI) for \"convenience\"\n- ❌ Letting new `core\u002F` files slip in without classifying them as bootstrap vs. post-SDK\n- ❌ Rubber-stamping PRs that delete >20 files without line-by-line deletion review\n","## Context\n\nWhen reviewing a PR that touches core architecture, the reviewer must verify that structural invariants are preserved. This skill covers **reviewing existing PRs** for architectural quality — not writing proposals (see `architectural-proposals\u002FSKILL.md` for that).\n\nUse this skill when a PR includes any of:\n- New modules, packages, or directories\n- Dependency changes (`package.json`, `import` additions across package boundaries)\n- API surface changes (new or modified exports from `index.ts` barrel files)\n- Cross-package imports (anything crossing the SDK\u002FCLI boundary)\n- New abstractions (interfaces, base classes, registries, factories)\n- Sweeping refactors (file renames, pattern migrations, bulk conversions)\n\n## Patterns\n\n### 1. Module Boundary Enforcement\n\nThe Squad codebase has two core packages with a strict dependency direction:\n\n```\nsquad-cli → depends on → squad-sdk\nsquad-sdk → NEVER depends on → squad-cli\n```\n\n**Check every new `import` statement in the PR:**\n- CLI files may import from SDK (`@bradygaster\u002Fsquad-sdk`)\n- SDK files must NEVER import from CLI\n- If a PR adds an SDK import that pulls in CLI code, reject it\n\n### 2. Zero-Dependency Bootstrap Contract\n\nThe CLI has **protected bootstrap files** that must use ONLY Node.js built-in modules (`node:fs`, `node:path`, `node:child_process`, `node:util`). These files run before the SDK is loaded.\n\n**Protected files (authoritative list from copilot-instructions.md):**\n\n| File | Purpose |\n|------|---------|\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Fdetect-squad-dir.ts` | Finds `.squad\u002F` at startup |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Ferrors.ts` | Error classes (`SquadError`, `fatal()`) |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Fgh-cli.ts` | GitHub CLI wrapper |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Foutput.ts` | Color\u002Femoji console output |\n| `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Fhistory-split.ts` | Portable knowledge separator |\n\n**Review checklist for bootstrap files:**\n- ❌ No new `import` or `require` of anything outside `node:*`\n- ❌ No conversion to `FSStorageProvider`, `StorageProvider`, or SDK abstractions\n- ✅ Look for `— zero dependencies` markers in file headers\n- ✅ If the PR adds a new bootstrap utility, it must be added to this table and have a zero-dependency regression test\n\n### 3. Export Surface Safety\n\nChanges to barrel files (`index.ts`) have downstream impact. Barrel files define the public API of a package.\n\n**Review checklist:**\n- **Adding exports:** Is the new export intentional? Does it expose implementation details that should stay internal?\n- **Removing exports:** Are downstream consumers accounted for? Removing an export is a breaking change.\n- **Renaming exports:** Same as remove + add — breaks anyone using the old name. Look for typos (e.g., `FSStorageProvidr` vs. `FSStorageProvider`).\n- **Re-exports:** If the PR adds `export * from '.\u002Finternal-module'`, verify that the internal module doesn't accidentally expose private types.\n\n### 4. Sweeping Refactor Safety\n\nWhen a PR applies a codebase-wide pattern change (e.g., \"convert all `fs` calls to `StorageProvider`\"), verify the 5-step checklist from project instructions:\n\n1. **Protected Files checked** — None of the protected bootstrap files were converted\n2. **Zero-dependency markers scanned** — Files with `— zero dependencies` headers were skipped\n3. **Imports resolve** — Every `import { X } from '@bradygaster\u002Fsquad-sdk'` references an export that actually exists in the SDK barrel file\n4. **Not blindly applied** — File-specific constraints were respected\n5. **Batched testing** — Changes were tested in logical groups, not all 30 files at once\n\n### 5. Template Sync Awareness\n\nTemplate files exist in **four locations** and must stay consistent:\n\n```\ntemplates\u002F                          # Source of truth\n.squad-templates\u002F                   # Local project templates\npackages\u002Fsquad-cli\u002Ftemplates\u002F       # CLI-bundled templates\n.github\u002Fworkflows\u002F                  # Workflow templates\n```\n\nIf a PR modifies a template in one location, check:\n- Was the change mirrored to other locations where the same template exists?\n- Does `TEMPLATE_MANIFEST` in `templates.ts` still correctly map files to agents?\n- Were any new templates added to the manifest?\n\n### 6. `.squad\u002F` Leakage Check\n\n`.squad\u002F` files (team config, decisions, agent charters) must NOT leak into feature PRs that are about code changes.\n\n**Check:**\n- If the PR is labeled as a feature or bugfix, it should not modify `.squad\u002Fteam.md`, `.squad\u002Fdecisions.md`, `.squad\u002Frouting.md`, or agent charters — unless the issue specifically calls for it\n- `.squad\u002Fdecisions\u002Finbox\u002F` files are acceptable if the PR documents a decision made during implementation\n- `.squad-templates\u002F` changes are acceptable only if the PR is about template functionality\n\n### 7. Pattern Consistency\n\nNew code should follow established patterns in the codebase. Look for:\n- **Naming conventions:** Does the new module follow existing naming? (e.g., `kebab-case` file names, `PascalCase` classes)\n- **Error handling:** Does the new code use `SquadError` and `fatal()` from `errors.ts`, or does it invent its own error patterns?\n- **Storage abstraction:** Does the new code use `StorageProvider` for file I\u002FO (except in protected bootstrap files)?\n- **Test patterns:** Does the PR include tests that follow the existing test structure?\n\n### 8. Dependency Direction in `core\u002F`\n\nThe `packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002F` directory contains a **mix** of:\n- Early-startup bootstrap utilities (zero external deps — protected)\n- Later SDK-dependent modules (may import from SDK)\n\nWhen reviewing changes to `core\u002F` files:\n- Verify the file is not in the protected list before accepting SDK imports\n- Confirm the SDK is loaded at the point where the file runs in the startup sequence\n- Watch for new files added to `core\u002F` — determine if they are bootstrap or post-SDK and document accordingly\n\n## Examples\n\n**Example 1: Reject — SDK import in bootstrap file**\n```\nPR adds to detect-squad-dir.ts:\n  import { FSStorageProvider } from '@bradygaster\u002Fsquad-sdk';\n\nFinding: REJECT — detect-squad-dir.ts is a protected bootstrap file.\nIt runs before the SDK is loaded. This import will crash the CLI at startup.\nRecommendation: Use node:fs directly. See Protected Files table.\n```\n\n**Example 2: Reject — Reverse dependency**\n```\nPR adds to packages\u002Fsquad-sdk\u002Fsrc\u002Fstorage.ts:\n  import { detectSquadDir } from '@bradygaster\u002Fsquad-cli';\n\nFinding: REJECT — SDK must never depend on CLI. Dependency direction is\nCLI → SDK, not reverse. Move the shared logic to SDK or extract to a\nshared utility within the SDK package.\n```\n\n**Example 3: Approve with note — Template change in one location**\n```\nPR modifies templates\u002Fsquad.agent.md but not .squad-templates\u002Fsquad.agent.md\n\nFinding: APPROVE with note — Template was updated in templates\u002F but the\nsame file in .squad-templates\u002F was not synced. Verify whether .squad-templates\u002F\nshould match or if it intentionally diverges.\n```\n\n**Example 4: Reject — Sweeping refactor hits protected file**\n```\nPR titled \"Convert all fs calls to StorageProvider\" modifies 15 files,\nincluding packages\u002Fsquad-cli\u002Fsrc\u002Fcli\u002Fcore\u002Foutput.ts\n\nFinding: REJECT — output.ts is a protected zero-dependency bootstrap file.\nThe PR must skip this file. See Sweeping Refactor Rules step 1.\n```\n\n**Example 5: Flag — Mass file deletion**\n```\nPR deletes 25 files as part of \"cleanup unused modules\"\n\nFinding: FLAG — More than 20 files deleted. This exceeds the red flag\nthreshold. Verify each deletion is intentional and no downstream imports\nare broken. Recommend splitting into smaller PRs.\n```\n\n## Review Output Format\n\nStructure your architectural review as:\n\n```\n## Architectural Review\n\n**Verdict:** APPROVE | APPROVE WITH NOTES | REQUEST CHANGES | REJECT\n\n### Findings\n\n1. [severity: critical|high|medium|low] — description\n   - File(s): path\u002Fto\u002Ffile.ts\n   - Recommendation: what to fix\n\n2. [severity: ...] — ...\n\n### Summary\nBrief explanation of architectural impact and any required follow-ups.\n```\n\n## Anti-Patterns\n\n- ❌ Approving SDK imports in protected bootstrap files (\"it's just one import\")\n- ❌ Ignoring barrel file changes (\"it's just adding an export\")\n- ❌ Skipping template sync check (\"they probably know about the other locations\")\n- ❌ Accepting sweeping refactors without verifying the 5-step checklist\n- ❌ Allowing `.squad\u002F` config changes in feature PRs without justification\n- ❌ Approving reverse dependencies (SDK importing from CLI) for \"convenience\"\n- ❌ Letting new `core\u002F` files slip in without classifying them as bootstrap vs. post-SDK\n- ❌ Rubber-stamping PRs that delete >20 files without line-by-line deletion review\n",{"name":5,"domain":30,"source":43,"confidence":44,"description":7},"extracted from copilot-instructions.md patterns and codebase conventions","medium","dev","4ffda80d1bb1043d9169688cf161e53097345c72",".copilot\u002Fskills\u002Farchitectural-review",0,"https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad","https:\u002F\u002Fgithub.com\u002FDeDuva","2026-11-09 20:24:44",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add DeDuva\u002Fsquad --skill architectural-review",{"tool":58,"command":59},"bunx","bunx skills add DeDuva\u002Fsquad --skill architectural-review",{"tool":61,"command":62},"pnpm","pnpm dlx skills add DeDuva\u002Fsquad --skill architectural-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002F.copilot\u002Fskills\u002Farchitectural-review\u002FSKILL.md",true,[],[67,83,91,105,126,141],{"skillNo":68,"name":69,"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":70,"categories":71,"keywords":77,"publishedAt":38},"01M719NE6ZPZT80MKVWFDECJZ3","My Skill","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002Ftest-fixtures\u002Fskills-test-abb30454\u002Fmy-skill\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[78,79,80,81,82],"my","my skill","testing","vitest","tester",{"skillNo":84,"name":85,"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":86,"categories":87,"keywords":88,"publishedAt":38},"01M719NDJAMEWM8D9H355SCNA8","bad-skill","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002Ftest-fixtures\u002Fskills-test-abb30454\u002Fbad-skill\u002FSKILL.md",[],[89,90],"bad skill","bad",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":38},"01M719NCC1AZ02GHZ1V71YPEV7","squad-conventions","Core conventions and patterns used in the Squad codebase","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002Ftemplates\u002Fskills\u002Fsquad-conventions\u002FSKILL.md",[],[21,98,99,100,101,102,103,104,24,20],"squad","squad conventions","project-conventions","core","project","manual","high",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":38},"01M719NAYM17B7X8MGP681EHKQ","rework-rate","Measure and interpret PR rework rate — the emerging 5th DORA metric","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002Ftemplates\u002Fskills\u002Frework-rate\u002FSKILL.md",[],[112,113,114,115,104,116,25,117,98,118,119,120,121,103,33,122,123,124,125,18],"rate","rework rate","health","analyze","review efficiency","metric","metrics","efficiency","code quality","pr","when","code","team","code-review",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":38},"01M719NA136PDC3SQ10R4R88TH","nap","Context hygiene — compress, prune, archive .squad\u002F state","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002Ftemplates\u002Fskills\u002Fnap\u002FSKILL.md",[],[128,133,134,135,136,137,138,139,98,140],"prune","state","maintenance","context hygiene","archive","hygiene","compress","context",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":151,"publishedAt":38},"01M719N7B4PBQPNXW78TEJY4HQ","e2e-template-testing","End-to-end validation of coordinator and agent template changes","https:\u002F\u002Fgithub.com\u002FDeDuva\u002Fsquad\u002Fblob\u002Fdev\u002Ftemplates\u002Fskills\u002Fe2e-template-testing\u002FSKILL.md",[147,150],{"categoryNo":148,"categoryName":149,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[80,152,153,154,155,156,157,103,158,104,159],"e2e template testing","e2e","template","end","coordinator","development","changes","validation"]