[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79PKBDS0WFY7YFK810PBYJ6":3,"skill-same:01M79PKBDS0WFY7YFK810PBYJ6":50},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":14,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":35,"install":36,"resources":49},"01M79PKBDS0WFY7YFK810PBYJ6","openspec-sync-specs",null,"Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.","behindthedash\u002Fworktrail","behindthedash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F30299179?v=4","01M79PHT5395GJXDSNP7MYP63D","OC","01M79PHT68KHMYHPS9D9RCYFJZ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fopenspec-sync-specs\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: openspec-sync-specs\ndescription: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.\nallowed-tools: Bash(openspec:*)\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n  author: openspec\n  version: \"1.0\"\n  generatedBy: \"1.6.0\"\n---\n\nSync delta specs from a change to main specs.\n\nThis is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).\n\n**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store \u003Cid>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec\u002F` root.\n\n**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **If no change name provided, prompt for selection**\n\n   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.\n\n   Show changes that have delta specs (under `specs\u002F` directory).\n\n   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.\n\n2. **Resolve change context**\n\n   Run:\n   ```bash\n   openspec status --change \"\u003Cname>\" --json\n   ```\n\n3. **Find delta specs**\n\n   Use `artifactPaths.specs.existingOutputPaths` from the status JSON as the list of delta spec files.\n\n   Each delta spec file contains sections like:\n   - `## ADDED Requirements` - New requirements to add\n   - `## MODIFIED Requirements` - Changes to existing requirements\n   - `## REMOVED Requirements` - Requirements to remove\n   - `## RENAMED Requirements` - Requirements to rename (FROM:\u002FTO: format)\n\n   If no delta specs found, inform user and stop.\n\n4. **For each delta spec, apply changes to main specs**\n\n   For each repo-local capability delta spec path returned by the CLI:\n\n   a. **Read the delta spec** to understand the intended changes\n\n   b. **Read the main spec** at `openspec\u002Fspecs\u002F\u003Ccapability>\u002Fspec.md` (may not exist yet)\n\n   c. **Apply changes intelligently**:\n\n      **ADDED Requirements:**\n      - If requirement doesn't exist in main spec → add it\n      - If requirement already exists → update it to match (treat as implicit MODIFIED)\n\n      **MODIFIED Requirements:**\n      - Find the requirement in main spec\n      - Apply the changes - this can be:\n        - Adding new scenarios (don't need to copy existing ones)\n        - Modifying existing scenarios\n        - Changing the requirement description\n      - Preserve scenarios\u002Fcontent not mentioned in the delta\n\n      **REMOVED Requirements:**\n      - Remove the entire requirement block from main spec\n\n      **RENAMED Requirements:**\n      - Find the FROM requirement, rename to TO\n\n   d. **Create new main spec** if capability doesn't exist yet:\n      - Create `openspec\u002Fspecs\u002F\u003Ccapability>\u002Fspec.md`\n      - Start the file with the title line `# \u003Ccapability> Specification` (using the\n        capability's directory name) followed by a blank line — a main spec is not a\n        delta and `openspec validate` requires this line\n      - Add Purpose section (can be brief, mark as TBD)\n      - Add a `## Requirements` header — **not** the delta's `## ADDED Requirements`\n        header, which is delta-only syntax and fails `openspec validate` on a main\n        spec — followed by the ADDED requirements verbatim\n\n5. **Show summary**\n\n   After applying all changes, summarize:\n   - Which capabilities were updated\n   - What changes were made (requirements added\u002Fmodified\u002Fremoved\u002Frenamed)\n\n**Delta Spec Format Reference**\n\n```markdown\n## ADDED Requirements\n\n### Requirement: New Feature\nThe system SHALL do something new.\n\n#### Scenario: Basic case\n- **WHEN** user does X\n- **THEN** system does Y\n\n## MODIFIED Requirements\n\n### Requirement: Existing Feature\n#### Scenario: New scenario to add\n- **WHEN** user does A\n- **THEN** system does B\n\n## REMOVED Requirements\n\n### Requirement: Deprecated Feature\n\n## RENAMED Requirements\n\n- FROM: `### Requirement: Old Name`\n- TO: `### Requirement: New Name`\n```\n\n**Key Principle: Intelligent Merging**\n\nUnlike programmatic merging, you can apply **partial updates**:\n- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios\n- The delta represents *intent*, not a wholesale replacement\n- Use your judgment to merge changes sensibly\n\n**Output On Success**\n\n```\n## Specs Synced: \u003Cchange-name>\n\nUpdated main specs:\n\n**\u003Ccapability-1>**:\n- Added requirement: \"New Feature\"\n- Modified requirement: \"Existing Feature\" (added 1 scenario)\n\n**\u003Ccapability-2>**:\n- Created new spec file\n- Added requirement: \"Another Feature\"\n\nMain specs are now updated. The change remains active - archive when implementation is complete.\n```\n\n**Guardrails**\n- Read both delta and main specs before making changes\n- Preserve existing content not mentioned in delta\n- If something is unclear, ask for clarification\n- Show what you're changing as you go\n- The operation should be idempotent - running twice should give same result\n- After creating or modifying a main spec, run `openspec validate \u003Ccapability> --json`\n  (or `--all` for the whole batch) and fix any reported issues before summarizing —\n  a spec missing its title line or still carrying a delta-only `## ADDED Requirements`\n  header fails validation\n","Sync delta specs from a change to main specs.\n\nThis is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).\n\n**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store \u003Cid>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec\u002F` root.\n\n**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **If no change name provided, prompt for selection**\n\n   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.\n\n   Show changes that have delta specs (under `specs\u002F` directory).\n\n   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.\n\n2. **Resolve change context**\n\n   Run:\n   ```bash\n   openspec status --change \"\u003Cname>\" --json\n   ```\n\n3. **Find delta specs**\n\n   Use `artifactPaths.specs.existingOutputPaths` from the status JSON as the list of delta spec files.\n\n   Each delta spec file contains sections like:\n   - `## ADDED Requirements` - New requirements to add\n   - `## MODIFIED Requirements` - Changes to existing requirements\n   - `## REMOVED Requirements` - Requirements to remove\n   - `## RENAMED Requirements` - Requirements to rename (FROM:\u002FTO: format)\n\n   If no delta specs found, inform user and stop.\n\n4. **For each delta spec, apply changes to main specs**\n\n   For each repo-local capability delta spec path returned by the CLI:\n\n   a. **Read the delta spec** to understand the intended changes\n\n   b. **Read the main spec** at `openspec\u002Fspecs\u002F\u003Ccapability>\u002Fspec.md` (may not exist yet)\n\n   c. **Apply changes intelligently**:\n\n      **ADDED Requirements:**\n      - If requirement doesn't exist in main spec → add it\n      - If requirement already exists → update it to match (treat as implicit MODIFIED)\n\n      **MODIFIED Requirements:**\n      - Find the requirement in main spec\n      - Apply the changes - this can be:\n        - Adding new scenarios (don't need to copy existing ones)\n        - Modifying existing scenarios\n        - Changing the requirement description\n      - Preserve scenarios\u002Fcontent not mentioned in the delta\n\n      **REMOVED Requirements:**\n      - Remove the entire requirement block from main spec\n\n      **RENAMED Requirements:**\n      - Find the FROM requirement, rename to TO\n\n   d. **Create new main spec** if capability doesn't exist yet:\n      - Create `openspec\u002Fspecs\u002F\u003Ccapability>\u002Fspec.md`\n      - Start the file with the title line `# \u003Ccapability> Specification` (using the\n        capability's directory name) followed by a blank line — a main spec is not a\n        delta and `openspec validate` requires this line\n      - Add Purpose section (can be brief, mark as TBD)\n      - Add a `## Requirements` header — **not** the delta's `## ADDED Requirements`\n        header, which is delta-only syntax and fails `openspec validate` on a main\n        spec — followed by the ADDED requirements verbatim\n\n5. **Show summary**\n\n   After applying all changes, summarize:\n   - Which capabilities were updated\n   - What changes were made (requirements added\u002Fmodified\u002Fremoved\u002Frenamed)\n\n**Delta Spec Format Reference**\n\n```markdown\n## ADDED Requirements\n\n### Requirement: New Feature\nThe system SHALL do something new.\n\n#### Scenario: Basic case\n- **WHEN** user does X\n- **THEN** system does Y\n\n## MODIFIED Requirements\n\n### Requirement: Existing Feature\n#### Scenario: New scenario to add\n- **WHEN** user does A\n- **THEN** system does B\n\n## REMOVED Requirements\n\n### Requirement: Deprecated Feature\n\n## RENAMED Requirements\n\n- FROM: `### Requirement: Old Name`\n- TO: `### Requirement: New Name`\n```\n\n**Key Principle: Intelligent Merging**\n\nUnlike programmatic merging, you can apply **partial updates**:\n- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios\n- The delta represents *intent*, not a wholesale replacement\n- Use your judgment to merge changes sensibly\n\n**Output On Success**\n\n```\n## Specs Synced: \u003Cchange-name>\n\nUpdated main specs:\n\n**\u003Ccapability-1>**:\n- Added requirement: \"New Feature\"\n- Modified requirement: \"Existing Feature\" (added 1 scenario)\n\n**\u003Ccapability-2>**:\n- Created new spec file\n- Added requirement: \"Another Feature\"\n\nMain specs are now updated. The change remains active - archive when implementation is complete.\n```\n\n**Guardrails**\n- Read both delta and main specs before making changes\n- Preserve existing content not mentioned in delta\n- If something is unclear, ask for clarification\n- Show what you're changing as you go\n- The operation should be idempotent - running twice should give same result\n- After creating or modifying a main spec, run `openspec validate \u003Ccapability> --json`\n  (or `--all` for the whole batch) and fix any reported issues before summarizing —\n  a spec missing its title line or still carrying a delta-only `## ADDED Requirements`\n  header fails validation\n",{"name":5,"license":15,"metadata":24,"description":7,"allowed-tools":28,"compatibility":29},{"author":25,"version":26,"generatedBy":27},"openspec","1.0","1.6.0","Bash(openspec:*)","Requires openspec CLI.","main","db448e94704b506e1a5a0665d349fc422611fe9e","skills\u002Fopenspec-sync-specs","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail","https:\u002F\u002Fgithub.com\u002Fbehindthedash","2026-11-14 18:34:42",{"source":8,"skillName":5,"commands":37,"prompt":47,"zipAvailable":48},[38,41,44],{"tool":39,"command":40},"npx","npx skills add behindthedash\u002Fworktrail --skill openspec-sync-specs",{"tool":42,"command":43},"bunx","bunx skills add behindthedash\u002Fworktrail --skill openspec-sync-specs",{"tool":45,"command":46},"pnpm","pnpm dlx skills add behindthedash\u002Fworktrail --skill openspec-sync-specs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fopenspec-sync-specs\u002FSKILL.md",true,[],[51,58,65,72,79,86],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":19},"01M79PMY53NKDHVZ2AFSGNNJH7","worktrail-sdd-workflow","Internal SDD workflow executor invoked by \u002Fgo only. Do not call directly. Executes classified routes A–J: feature planning, implementation (parallel orchestration, PR generation), defect repair, refactoring, spec changes, investigation, and workflow evolution.","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fworktrail-sdd-workflow\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M79PMKBE8SYW0ZP14AEJDM5D","worktrail-routing-config","Configure Worktrail's agent routing table (`~\u002F.worktrail\u002Frouting.yaml`, or a repo-local `routing:` policy block) — which harness\u002Fmodel executes each role and tier, and how fallback between them works. Use when the operator wants to add or remove a harness\u002Fadapter (claude\u002Fcodex\u002Fopencode), add a model to an existing harness (e.g. adding a DeepSeek model to opencode), pin or change who does code review, add a new tier or purpose mapping, change the default tier, or is confused about which harness actually served a spawn (e.g. \"why did this use Codex when I only configured Claude\"). Trigger phrases: \"routing.yaml\", \"add a harness\", \"disable a harness\", \"add an adapter\", \"remove an adapter\", \"add a model\", \"add deepseek to opencode\", \"change the reviewer\", \"pin the reviewer\", \"routing tiers\", \"routing targets\", \"default_tier\", \"independent reviewer\", \"why did codex get called\". This skill is about *editing the config file*; it does not cover `\u002Fgo`'s own dispatch mechanics (see `worktrail-go`'s SKILL.md Phase 7 for how `tier_for()`\u002F`select_cell()` resolve it at runtime).","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fworktrail-routing-config\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M79PMB24YTZTZVVAKA4A4R38","worktrail-repo-init","Bootstrap a new repo, or migrate an existing single-branch repo, onto the workspace's repo-standards doctrine (~\u002Frules\u002FCLAUDE.repo.md): the AGENTS.md-is-truth\u002FCLAUDE.md-imports-it split, a dev\u002Fprd, dev\u002Fstg\u002Fprd, or main-only (trunk) branch model with matching GitHub rulesets, an OpenSpec scaffold, an auto-merge workflow, and a seeded .worktrail\u002Fpolicy.yaml. Trigger phrases: \"onboard this repo\", \"apply repo standards\", \"initialize repo standards\", \"set up this repo like the rest of the fleet\", \"bring this repo into line with the repo standards doctrine\".","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fworktrail-repo-init\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M79PM54RFP51Q2JPQGE13ZP8","worktrail-help","Show the Worktrail front-door commands and accepted positional arguments. Use when the user asks how to invoke worktrail-go, wants the available handoff, spec, pr, repo, or route forms, invokes worktrail-go with help or with a bare noun, or asks how to answer a filed product decision (worktrail-decision).","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fworktrail-help\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M79PKVZVBF4VFT5XEPCPNM9S","worktrail-handoff","Capture a discovered problem, gap, tech debt, or deferred work into a local work queue so a future agent session can pick it up cold. Use mid-session whenever you set work aside instead of doing it now — a fix you judge out of scope for this PR, work that belongs in a follow-up or a separate\u002Flater PR, an item you're deferring, or something worth fixing you won't tackle now — so the outstanding item isn't lost without derailing current work; can be called multiple times per session. Trigger phrases: \"defer this\", \"item deferred\", \"out of scope for this PR\", \"follow-up work\", \"leave for another PR\", \"capture for later\", \"outstanding item\". This skill captures only. Picking a brief back up is the front door's job: worktrail-go \u003Cbrief-id>.","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fworktrail-handoff\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M79PKJZD9MPN7Q8GWR01KX0J","worktrail-go","Use when the user invokes worktrail-go, asks to pick up queued work, resume active specs, implement or fix a spec, route engineering work, or orient across repositories. Renders the orientation dashboard, classifies free-text requests, claims\u002Fresumes handoff briefs, and dispatches SDD work without requiring the user to know sdd-workflow. Grammar: worktrail-go [REPO] \u003Cnoun> \u003Cverb>, nouns handoff \u002F spec \u002F pr \u002F decision. Triggers: worktrail-go, worktrail-go help, worktrail-go spec fix, worktrail-go spec implement, worktrail-go spec route F, worktrail-go handoff new, worktrail-go handoff auto, worktrail-go decision answer, worktrail-go BRIEF-ID, bare worktrail-go, multi-repo orientation.","https:\u002F\u002Fgithub.com\u002Fbehindthedash\u002Fworktrail\u002Fblob\u002Fmain\u002Fskills\u002Fworktrail-go\u002FSKILL.md",[],[]]