[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FREVCBF0YX1FX8WNAQTGP":3,"skill-same:01M70FREVCBF0YX1FX8WNAQTGP":60},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":13,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M70FREVCBF0YX1FX8WNAQTGP","docs-refresh",null,"Generates and maintains living documentation from the current codebase state. Reads a project-local manifest (.claude\u002Fdocs-refresh.yml) that declares doc targets, sections, source inventories, and refresh boundaries. Uses marker blocks in docs to safely regenerate content without trampling manual prose.","SirTheOracle\u002Fforge-toolkit","SirTheOracle","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F264051384?v=4","01M70FNRYMQR4XHVN77S3NJPAW","01M70FNRZAGW58XJ1CC6JRY1PA",0,"MIT","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fdocs-refresh\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"docs refresh","docs","refresh","marker","content","source","prose","doc","blocks","codebase","targets","state","documentation","manifest","local","manual","project","2026-11-10 10:12:30",false,"---\nname: docs-refresh\ndescription: >\n  Generates and maintains living documentation from the current codebase state.\n  Reads a project-local manifest (.claude\u002Fdocs-refresh.yml) that declares doc\n  targets, sections, source inventories, and refresh boundaries. Uses marker\n  blocks in docs to safely regenerate content without trampling manual prose.\n---\n\n# Docs Refresh Skill\n\n## Hard Constraints\n\n1. Never auto-commit — write files only, let the user review via `git diff`\n2. Never overwrite text outside marker blocks — manual prose is sacred\n3. Never invent facts — every claim must trace to a source file you actually read\n4. Never scan the entire codebase — only read files declared in the manifest's source inventories\n5. Never silently resolve conflicts between sources — surface contradictions as visible TODOs\n6. Always read the manifest before generating anything\n7. Always preserve existing marker block boundaries — never merge, split, or relocate them\n\n## Required Reads\n\nBefore generating anything, read these files in order:\n\n1. `.claude\u002Fdocs-refresh.yml` — the project manifest (required)\n2. `CLAUDE.md` — project context (if exists)\n3. Each source inventory file declared in the manifest\n\nIf `.claude\u002Fdocs-refresh.yml` does not exist:\n```\nDOCS-REFRESH ERROR: No .claude\u002Fdocs-refresh.yml found.\nCreate a manifest with doc targets and source inventories before running this skill.\nSee ~\u002F.claude\u002Fskills\u002Fdocs-refresh\u002FSKILL.md for the manifest format.\n```\n\n## Manifest Format\n\nThe project-local manifest at `.claude\u002Fdocs-refresh.yml` declares what to generate.\n\n```yaml\nversion: 1\n\n# Source inventory aliases — map logical names to file paths\u002Franges\nsources:\n  project.identity:\n    - CLAUDE.md\n    - .claude\u002Fforge-project.yml\n  runtime.services:\n    - docker-compose.yml\n  backend.routes:\n    - backend\u002Fsrc\u002Fapp\u002Fmain.py\n    - backend\u002Fsrc\u002Fapp\u002Fapi\u002F*.py\n  backend.models:\n    - backend\u002Fsrc\u002Fapp\u002Fmodels\u002F__init__.py\n    - backend\u002Fsrc\u002Fapp\u002Fmodels\u002F*.py\n  backend.enums:\n    - backend\u002Fsrc\u002Fapp\u002Fmodels\u002Fenums.py\n  backend.migrations:\n    - backend\u002Falembic\u002Fversions\u002F*\n  frontend.routes:\n    - frontend\u002Fsrc\u002FApp.tsx\n  frontend.navigation:\n    - frontend\u002Fsrc\u002Fconfig\u002FappNavigation.ts\n  frontend.shell:\n    - frontend\u002Fsrc\u002Fcomponents\u002FLayout.tsx\n  workflows.core:\n    - .claude\u002Fforge-project.yml\n\n# Document targets\ntargets:\n  - id: product-guide\n    path: docs\u002Fproduct-guide.md\n    sections:\n      - id: overview\n        sources: [project.identity]\n      - id: pipeline-walkthrough\n        sources: [project.identity, backend.enums, workflows.core]\n      - id: screen-map\n        sources: [frontend.routes, frontend.navigation, frontend.shell]\n      - id: glossary\n        sources: [backend.enums, backend.models]\n\n  - id: technical-reference\n    path: docs\u002Ftechnical-reference.md\n    sections:\n      - id: architecture\n        sources: [project.identity, runtime.services]\n      - id: runtime-topology\n        sources: [runtime.services]\n      - id: api-endpoints\n        sources: [backend.routes]\n      - id: data-models\n        sources: [backend.models, backend.enums, backend.migrations]\n      - id: frontend-structure\n        sources: [frontend.routes, frontend.navigation, frontend.shell]\n      - id: dev-test-ops\n        sources: [workflows.core, project.identity]\n      - id: conventions\n        sources: [project.identity]\n```\n\n## Invocation\n\n```\n\u002Fdocs-refresh                           # refresh all targets\n\u002Fdocs-refresh technical-reference       # refresh one target\n```\n\n## Phase 0: Manifest Loading and Validation\n\n1. Read `.claude\u002Fdocs-refresh.yml`\n2. Validate:\n   - Every `target.id` is unique\n   - Every `section.id` is unique within its target\n   - Every source alias referenced by a section exists in the `sources` map\n   - Every source file path exists on disk (glob patterns are resolved)\n3. If validation fails, report clearly and stop:\n   ```\n   DOCS-REFRESH VALIDATION ERROR:\n   - Section \"api-endpoints\" references unknown source \"backend.controllers\"\n   - Source \"frontend.routes\" path \"frontend\u002Fsrc\u002FApp.tsx\" not found\n   ```\n\n## Phase 1: Build Source Inventories\n\nFor each source alias needed by the target(s) being refreshed:\n\n1. Read the declared files\n2. Extract structured facts into an inventory:\n\n| Source Alias | What to Extract |\n|---|---|\n| `project.identity` | Project name, description, overview, port numbers |\n| `runtime.services` | Service names, images, ports, dependencies, health checks |\n| `backend.routes` | Router registrations from main.py, then for each route file: prefix, tags, auth dependencies, endpoint methods\u002Fpaths |\n| `backend.models` | Model class names from `__init__.py`, key columns and relationships from individual model files |\n| `backend.enums` | Enum classes and their values (status transitions, pipeline phases) |\n| `backend.migrations` | Migration filenames and descriptions (version history) |\n| `frontend.routes` | Route paths, component mappings, parameterized routes, layout nesting |\n| `frontend.navigation` | Nav items with key, label, segment, isIndex, adminOnly, showBadgePlaceholder |\n| `frontend.shell` | Layout structure, sidebar behavior, badge rendering, mobile support |\n| `workflows.core` | Test commands, dev commands, smoke pages, core workflows |\n\n### Source Tier Policy\n\nWhen sources disagree, prefer the higher tier:\n\n1. **Code\u002Fruntime surfaces** — routers, models, route tree, compose services (highest authority)\n2. **Structured config\u002Fmanifests** — forge-project.yml, appNavigation.ts\n3. **Curated prose** — CLAUDE.md, existing docs (lowest authority for facts)\n\nIf a lower-tier source contradicts a higher-tier source:\n- Use the higher-tier fact in generated content\n- Add a visible note: `\u003C!-- TODO: CLAUDE.md says X but code shows Y — verify and update -->`\n\n### Frontend Merge Rules\n\nFrontend screen documentation requires merging three sources:\n\n- `frontend.routes` (App.tsx) — authoritative for reachable routes and parameterized pages\n- `frontend.navigation` (appNavigation.ts) — authoritative for nav labels, order, adminOnly\n- `frontend.shell` (Layout.tsx) — augments with visibility behavior, badges, mobile\n\nHidden-but-reachable routes (in App.tsx but not in navigation) must be documented separately, not silently dropped.\n\n## Phase 2: Generate Content\n\nFor each target being refreshed, for each section:\n\n1. Check if the target doc file exists\n2. If it exists, read it and locate the marker blocks\n3. If it doesn't exist, create it with all section headers and empty marker blocks\n\n### Marker Block Format\n\n```md\n## Section Heading\n\nOptional manual framing text here — never touched by the skill.\n\n\u003C!-- docs-refresh:start section=section-id -->\n...generated content goes here...\n\u003C!-- docs-refresh:end section=section-id -->\n\nMore manual text can follow — also never touched.\n```\n\n### Generation Rules\n\n- Only write content inside marker blocks\n- Everything outside markers is preserved exactly as-is\n- Generated content should be clear, accurate, and sourced from the inventories built in Phase 1\n- Use markdown tables for structured data (API endpoints, model summaries, service topology)\n- Use prose for narrative sections (overview, architecture, conventions)\n- Keep language appropriate to the target audience:\n  - `product-guide`: non-technical, stakeholder-friendly, plain language\n  - `technical-reference`: developer-oriented, specific, with code references\n\n### Section Content Guidelines\n\n#### Product Guide Sections\n\n| Section | Content |\n|---|---|\n| `overview` | One-paragraph product summary, who built it, what it does |\n| `pipeline-walkthrough` | The content pipeline phases explained in plain language with what happens at each step |\n| `screen-map` | Every UI screen with what it does and its workflow context |\n| `glossary` | Key terms with plain-language definitions |\n\n#### Technical Reference Sections\n\n| Section | Content |\n|---|---|\n| `architecture` | Backend\u002Ffrontend\u002Fdatabase architecture, how they connect, key design decisions |\n| `runtime-topology` | Every service from docker-compose with ports, images, dependencies |\n| `api-endpoints` | Table: method, path, auth requirement, description. Grouped by router |\n| `data-models` | Table: model, key columns, relationships. Plus enum values and migration history summary |\n| `frontend-structure` | Route tree, navigation manifest, component hierarchy, state management |\n| `dev-test-ops` | Commands for running locally, testing, migrations, seeding, Docker |\n| `conventions` | Key patterns: async SQLAlchemy, enum strategy, testing approach, import conventions |\n\n## Phase 3: Write and Report\n\n1. Write the updated doc files\n2. Report what was done:\n   ```\n   DOCS-REFRESH COMPLETE\n   Targets refreshed: product-guide, technical-reference\n   Sections updated: 11\n   Source files read: 24\n   Conflicts found: 1 (see TODO comments in docs)\n\n   Files written:\n   - docs\u002Fproduct-guide.md\n   - docs\u002Ftechnical-reference.md\n\n   Review with: git diff docs\u002F\n   ```\n\n## Marker Safety Rules\n\nBefore writing any file:\n\n1. Verify every section declared in the manifest has a matching marker pair in the doc\n2. If a marker is missing, add it (with the section heading) at the end of the document\n3. If a marker is malformed (mismatched start\u002Fend, duplicate section IDs), stop and report:\n   ```\n   DOCS-REFRESH MARKER ERROR in docs\u002Ftechnical-reference.md:\n   - Line 45: start marker for \"api-endpoints\" has no matching end marker\n   - Line 89: duplicate start marker for \"data-models\"\n   ```\n4. Never create nested markers\n5. Never move existing markers to a different position in the document\n\n## Creating Docs From Scratch\n\nWhen a target doc file does not exist yet:\n\n1. Create the file with a title heading (`# Product Guide` or `# Technical Reference`)\n2. For each section in the manifest (in order):\n   - Add a `## Section Heading` (derive from section ID: `api-endpoints` -> `## API Endpoints`)\n   - Add the marker block pair\n   - Generate the initial content inside the markers\n3. This produces a complete document with markers already in place\n\n## Error Handling\n\n| Error | Action |\n|---|---|\n| Manifest not found | Stop, report with setup instructions |\n| Manifest validation fails | Stop, report all errors |\n| Source file not found | Warn, skip that source, note in report |\n| Marker error in existing doc | Stop, report the specific marker issue |\n| Source tier conflict | Generate from higher tier, add TODO comment |\n| Target directory doesn't exist | Create it (e.g., `mkdir -p docs\u002F`) |\n\n## What This Skill Does NOT Do\n\n- Does not auto-commit (user reviews first)\n- Does not scan files beyond what the manifest declares\n- Does not edit CLAUDE.md or any source files\n- Does not manage build-unit mapping\n- Does not integrate with forge-coder or other pipeline skills (deferred)\n- Does not generate changelogs or ADRs (separate concerns)\n\n## Extending to New Documents\n\nTo add a new document target:\n\n1. Add a new entry under `targets` in `.claude\u002Fdocs-refresh.yml`\n2. Define its sections and source mappings\n3. Run `\u002Fdocs-refresh` — the skill creates the new file with markers automatically\n\nNo skill code changes required. The manifest drives everything.\n","# Docs Refresh Skill\n\n## Hard Constraints\n\n1. Never auto-commit — write files only, let the user review via `git diff`\n2. Never overwrite text outside marker blocks — manual prose is sacred\n3. Never invent facts — every claim must trace to a source file you actually read\n4. Never scan the entire codebase — only read files declared in the manifest's source inventories\n5. Never silently resolve conflicts between sources — surface contradictions as visible TODOs\n6. Always read the manifest before generating anything\n7. Always preserve existing marker block boundaries — never merge, split, or relocate them\n\n## Required Reads\n\nBefore generating anything, read these files in order:\n\n1. `.claude\u002Fdocs-refresh.yml` — the project manifest (required)\n2. `CLAUDE.md` — project context (if exists)\n3. Each source inventory file declared in the manifest\n\nIf `.claude\u002Fdocs-refresh.yml` does not exist:\n```\nDOCS-REFRESH ERROR: No .claude\u002Fdocs-refresh.yml found.\nCreate a manifest with doc targets and source inventories before running this skill.\nSee ~\u002F.claude\u002Fskills\u002Fdocs-refresh\u002FSKILL.md for the manifest format.\n```\n\n## Manifest Format\n\nThe project-local manifest at `.claude\u002Fdocs-refresh.yml` declares what to generate.\n\n```yaml\nversion: 1\n\n# Source inventory aliases — map logical names to file paths\u002Franges\nsources:\n  project.identity:\n    - CLAUDE.md\n    - .claude\u002Fforge-project.yml\n  runtime.services:\n    - docker-compose.yml\n  backend.routes:\n    - backend\u002Fsrc\u002Fapp\u002Fmain.py\n    - backend\u002Fsrc\u002Fapp\u002Fapi\u002F*.py\n  backend.models:\n    - backend\u002Fsrc\u002Fapp\u002Fmodels\u002F__init__.py\n    - backend\u002Fsrc\u002Fapp\u002Fmodels\u002F*.py\n  backend.enums:\n    - backend\u002Fsrc\u002Fapp\u002Fmodels\u002Fenums.py\n  backend.migrations:\n    - backend\u002Falembic\u002Fversions\u002F*\n  frontend.routes:\n    - frontend\u002Fsrc\u002FApp.tsx\n  frontend.navigation:\n    - frontend\u002Fsrc\u002Fconfig\u002FappNavigation.ts\n  frontend.shell:\n    - frontend\u002Fsrc\u002Fcomponents\u002FLayout.tsx\n  workflows.core:\n    - .claude\u002Fforge-project.yml\n\n# Document targets\ntargets:\n  - id: product-guide\n    path: docs\u002Fproduct-guide.md\n    sections:\n      - id: overview\n        sources: [project.identity]\n      - id: pipeline-walkthrough\n        sources: [project.identity, backend.enums, workflows.core]\n      - id: screen-map\n        sources: [frontend.routes, frontend.navigation, frontend.shell]\n      - id: glossary\n        sources: [backend.enums, backend.models]\n\n  - id: technical-reference\n    path: docs\u002Ftechnical-reference.md\n    sections:\n      - id: architecture\n        sources: [project.identity, runtime.services]\n      - id: runtime-topology\n        sources: [runtime.services]\n      - id: api-endpoints\n        sources: [backend.routes]\n      - id: data-models\n        sources: [backend.models, backend.enums, backend.migrations]\n      - id: frontend-structure\n        sources: [frontend.routes, frontend.navigation, frontend.shell]\n      - id: dev-test-ops\n        sources: [workflows.core, project.identity]\n      - id: conventions\n        sources: [project.identity]\n```\n\n## Invocation\n\n```\n\u002Fdocs-refresh                           # refresh all targets\n\u002Fdocs-refresh technical-reference       # refresh one target\n```\n\n## Phase 0: Manifest Loading and Validation\n\n1. Read `.claude\u002Fdocs-refresh.yml`\n2. Validate:\n   - Every `target.id` is unique\n   - Every `section.id` is unique within its target\n   - Every source alias referenced by a section exists in the `sources` map\n   - Every source file path exists on disk (glob patterns are resolved)\n3. If validation fails, report clearly and stop:\n   ```\n   DOCS-REFRESH VALIDATION ERROR:\n   - Section \"api-endpoints\" references unknown source \"backend.controllers\"\n   - Source \"frontend.routes\" path \"frontend\u002Fsrc\u002FApp.tsx\" not found\n   ```\n\n## Phase 1: Build Source Inventories\n\nFor each source alias needed by the target(s) being refreshed:\n\n1. Read the declared files\n2. Extract structured facts into an inventory:\n\n| Source Alias | What to Extract |\n|---|---|\n| `project.identity` | Project name, description, overview, port numbers |\n| `runtime.services` | Service names, images, ports, dependencies, health checks |\n| `backend.routes` | Router registrations from main.py, then for each route file: prefix, tags, auth dependencies, endpoint methods\u002Fpaths |\n| `backend.models` | Model class names from `__init__.py`, key columns and relationships from individual model files |\n| `backend.enums` | Enum classes and their values (status transitions, pipeline phases) |\n| `backend.migrations` | Migration filenames and descriptions (version history) |\n| `frontend.routes` | Route paths, component mappings, parameterized routes, layout nesting |\n| `frontend.navigation` | Nav items with key, label, segment, isIndex, adminOnly, showBadgePlaceholder |\n| `frontend.shell` | Layout structure, sidebar behavior, badge rendering, mobile support |\n| `workflows.core` | Test commands, dev commands, smoke pages, core workflows |\n\n### Source Tier Policy\n\nWhen sources disagree, prefer the higher tier:\n\n1. **Code\u002Fruntime surfaces** — routers, models, route tree, compose services (highest authority)\n2. **Structured config\u002Fmanifests** — forge-project.yml, appNavigation.ts\n3. **Curated prose** — CLAUDE.md, existing docs (lowest authority for facts)\n\nIf a lower-tier source contradicts a higher-tier source:\n- Use the higher-tier fact in generated content\n- Add a visible note: `\u003C!-- TODO: CLAUDE.md says X but code shows Y — verify and update -->`\n\n### Frontend Merge Rules\n\nFrontend screen documentation requires merging three sources:\n\n- `frontend.routes` (App.tsx) — authoritative for reachable routes and parameterized pages\n- `frontend.navigation` (appNavigation.ts) — authoritative for nav labels, order, adminOnly\n- `frontend.shell` (Layout.tsx) — augments with visibility behavior, badges, mobile\n\nHidden-but-reachable routes (in App.tsx but not in navigation) must be documented separately, not silently dropped.\n\n## Phase 2: Generate Content\n\nFor each target being refreshed, for each section:\n\n1. Check if the target doc file exists\n2. If it exists, read it and locate the marker blocks\n3. If it doesn't exist, create it with all section headers and empty marker blocks\n\n### Marker Block Format\n\n```md\n## Section Heading\n\nOptional manual framing text here — never touched by the skill.\n\n\u003C!-- docs-refresh:start section=section-id -->\n...generated content goes here...\n\u003C!-- docs-refresh:end section=section-id -->\n\nMore manual text can follow — also never touched.\n```\n\n### Generation Rules\n\n- Only write content inside marker blocks\n- Everything outside markers is preserved exactly as-is\n- Generated content should be clear, accurate, and sourced from the inventories built in Phase 1\n- Use markdown tables for structured data (API endpoints, model summaries, service topology)\n- Use prose for narrative sections (overview, architecture, conventions)\n- Keep language appropriate to the target audience:\n  - `product-guide`: non-technical, stakeholder-friendly, plain language\n  - `technical-reference`: developer-oriented, specific, with code references\n\n### Section Content Guidelines\n\n#### Product Guide Sections\n\n| Section | Content |\n|---|---|\n| `overview` | One-paragraph product summary, who built it, what it does |\n| `pipeline-walkthrough` | The content pipeline phases explained in plain language with what happens at each step |\n| `screen-map` | Every UI screen with what it does and its workflow context |\n| `glossary` | Key terms with plain-language definitions |\n\n#### Technical Reference Sections\n\n| Section | Content |\n|---|---|\n| `architecture` | Backend\u002Ffrontend\u002Fdatabase architecture, how they connect, key design decisions |\n| `runtime-topology` | Every service from docker-compose with ports, images, dependencies |\n| `api-endpoints` | Table: method, path, auth requirement, description. Grouped by router |\n| `data-models` | Table: model, key columns, relationships. Plus enum values and migration history summary |\n| `frontend-structure` | Route tree, navigation manifest, component hierarchy, state management |\n| `dev-test-ops` | Commands for running locally, testing, migrations, seeding, Docker |\n| `conventions` | Key patterns: async SQLAlchemy, enum strategy, testing approach, import conventions |\n\n## Phase 3: Write and Report\n\n1. Write the updated doc files\n2. Report what was done:\n   ```\n   DOCS-REFRESH COMPLETE\n   Targets refreshed: product-guide, technical-reference\n   Sections updated: 11\n   Source files read: 24\n   Conflicts found: 1 (see TODO comments in docs)\n\n   Files written:\n   - docs\u002Fproduct-guide.md\n   - docs\u002Ftechnical-reference.md\n\n   Review with: git diff docs\u002F\n   ```\n\n## Marker Safety Rules\n\nBefore writing any file:\n\n1. Verify every section declared in the manifest has a matching marker pair in the doc\n2. If a marker is missing, add it (with the section heading) at the end of the document\n3. If a marker is malformed (mismatched start\u002Fend, duplicate section IDs), stop and report:\n   ```\n   DOCS-REFRESH MARKER ERROR in docs\u002Ftechnical-reference.md:\n   - Line 45: start marker for \"api-endpoints\" has no matching end marker\n   - Line 89: duplicate start marker for \"data-models\"\n   ```\n4. Never create nested markers\n5. Never move existing markers to a different position in the document\n\n## Creating Docs From Scratch\n\nWhen a target doc file does not exist yet:\n\n1. Create the file with a title heading (`# Product Guide` or `# Technical Reference`)\n2. For each section in the manifest (in order):\n   - Add a `## Section Heading` (derive from section ID: `api-endpoints` -> `## API Endpoints`)\n   - Add the marker block pair\n   - Generate the initial content inside the markers\n3. This produces a complete document with markers already in place\n\n## Error Handling\n\n| Error | Action |\n|---|---|\n| Manifest not found | Stop, report with setup instructions |\n| Manifest validation fails | Stop, report all errors |\n| Source file not found | Warn, skip that source, note in report |\n| Marker error in existing doc | Stop, report the specific marker issue |\n| Source tier conflict | Generate from higher tier, add TODO comment |\n| Target directory doesn't exist | Create it (e.g., `mkdir -p docs\u002F`) |\n\n## What This Skill Does NOT Do\n\n- Does not auto-commit (user reviews first)\n- Does not scan files beyond what the manifest declares\n- Does not edit CLAUDE.md or any source files\n- Does not manage build-unit mapping\n- Does not integrate with forge-coder or other pipeline skills (deferred)\n- Does not generate changelogs or ADRs (separate concerns)\n\n## Extending to New Documents\n\nTo add a new document target:\n\n1. Add a new entry under `targets` in `.claude\u002Fdocs-refresh.yml`\n2. Define its sections and source mappings\n3. Run `\u002Fdocs-refresh` — the skill creates the new file with markers automatically\n\nNo skill code changes required. The manifest drives everything.\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","skills\u002Fdocs-refresh","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit","https:\u002F\u002Fgithub.com\u002FSirTheOracle","2026-10-20 00:50:37",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add SirTheOracle\u002Fforge-toolkit --skill docs-refresh",{"tool":52,"command":53},"bunx","bunx skills add SirTheOracle\u002Fforge-toolkit --skill docs-refresh",{"tool":55,"command":56},"pnpm","pnpm dlx skills add SirTheOracle\u002Fforge-toolkit --skill docs-refresh","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fdocs-refresh\u002FSKILL.md",true,[],[61,87,111,130,151,174],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":35},"01M70FS350DG1MT6NBPYRPBFBQ","forge-orchestrator","tmux-based orchestrator for multi-agent building. Coordinates work across Claude Code and two Codex workers via forge-bridge. Translates user requests into dispatched tasks with structured audit logging. Replaces forge-dispatch, forge-state.yml, and stage-routing-map.yml.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fforge-orchestrator\u002FSKILL.md",[],[68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,29],"forge","orchestrator","forge orchestrator","bridge","map","code","tasks","across","work","audit","multi-agent","logging","tmux","for","audit logging","workers","stage","with","multi",{"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":93,"publishedAt":35},"01M70FRYFZC51YWHVNNS3862PY","forge-fix-runner","Drain the GitHub `forge-fix` issue queue through the forge fix pipeline, one service at a time. Tallies actionable issues worst-first, scouts a service into a routing plan (clusters + quick\u002Ffull tiers), gets human approval, then dispatches fixes (quick = dispatched fix-code; full = forge-pipeline), gating every `Closes #N` on per-issue verification. Trigger when the user wants to fix triaged QA issues, \"work the forge-fix queue\", or \"run the fix runner\".","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fforge-fix-runner\u002FSKILL.md",[],[94,95,68,96,97,98,99,100,101,102,103,104,73,105,76,106,107,108,109,110],"runner","fix","forge fix runner","quick","pipeline","actionable","time","issues","qa","gating","when","verification","plan","human","run","at","issue",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":35},"01M70FRVVW3JAGQQK3FFR2VYRC","forge-coder","Procedural coding skill. Reads implementation.md, validates diffs against the codebase, applies changes in execution order, runs tests after each commit group, and produces a coder-report.md artifact.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fforge-coder\u002FSKILL.md",[],[68,118,119,120,121,122,123,124,125,126,127,27,128,129],"forge coder","coder","diffs","tests","execution","commit","changes","artifact","procedural","report","implementation","coding",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":35},"01M70FRRYF6E22ECC8AGYYJEQ7","fix-reproducer","Optional first stage of the fix-pipeline. Verifies a reported bug is reproducible and captures deterministic repro steps, environment state, and evidence. Single procedural executor — does not spawn sub-agents and does not diagnose. Branches by environment: dev path runs the bug locally; prod path gathers observational evidence from the deployed environment. Always writes repro.md, even on NOT REPRODUCED. Trigger when the user invokes a fix-pipeline with the reproduce step enabled.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-reproducer\u002FSKILL.md",[],[137,138,95,139,140,141,142,98,143,144,145,146,147,148,149,104,84,85,29,150],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":35},"01M70FRN8THYBT2DJVX99XQ3CM","fix-plan-reviewer","Single-agent adversarial reviewer for fix plans. Reads diagnosis.md and fix-plan.md, verifies the plan actually addresses the diagnosed cause, attacks the plan from multiple angles (cause coverage, defense adequacy, scope correctness, regression risk, rollback integrity, test plan integrity, risk honesty), and produces fix-review.md with severity-rated issues. Does NOT propose fixes for the issues — that is the revise mode of adversarial-fix-plan. Does NOT re-investigate the diagnosis. Trigger as the review stage of a fix-pipeline, after adversarial-fix-plan has produced fix-plan.md.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-plan-reviewer\u002FSKILL.md",[],[158,95,159,106,160,161,162,163,98,164,165,101,166,167,168,169,170,171,172,173],"fix plan reviewer","reviewer","plan reviewer","coverage","scope","regression","re","mode","review","diagnosis","defense","integrity","addresses","revise","attacks","as",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":35},"01M70FRHGG6HN0VW483NDKX161","fix-coder","Mechanical single-executor that applies a vetted fix plan to the codebase. Reads fix-plan.md (the Changes, Defenses, and Test Plan sections), translates file-level changes into concrete diffs, applies them, runs the test plan, validates that the bug is no longer reproducible (dev) or that the test exercising the failing path passes (prod), and produces a single fix commit. Stays strictly in scope: does NOT modify the plan, does NOT re-investigate, does NOT touch files outside the plan. Always writes fix-coder-report.md, even on failure. Trigger as the implementation stage of a fix-pipeline, after fix-plan-reviewer has approved fix-plan.md.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-coder\u002FSKILL.md",[],[95,181,119,141,162,98,164,182,183,120,184,123,159,106,185,186,173,187,143,145],"fix coder","failing","mechanical","files","bug","path","test plan"]