[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QE3S8F38CFHSSETFACNBJ4":3,"skill-same:01M6QE3S8F38CFHSSETFACNBJ4":72},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":71},"01M6QE3S8F38CFHSSETFACNBJ4","speckit-tasks",null,"Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.","opencue\u002Fgitguardex","opencue","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F271874627?v=4","01M6QDWWMZFB8A08PDTA8D0VJ3","Opencue - Personal Ai Profiles for every job ","01M6QDWWSJGBEGVPMCEJFWVACT",28,"MIT","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"tasks","speckit","speckit tasks","structure","for","true","kit","actionable","false","feature","commands","project","design","task","dependency","specify","artifacts","generate","project structure","directory","2026-11-10 10:12:30",false,"---\nname: \"speckit-tasks\"\ndescription: \"Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.\"\nargument-hint: \"Optional task generation constraints\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Ftasks.md\"\nuser-invocable: true\ndisable-model-invocation: false\n---\n\n\n## User Input\n\n```text\n$ARGUMENTS\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Pre-Execution Checks\n\n**Check for extension hooks (before tasks generation)**:\n- Check if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.before_tasks` key\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n  - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n- For each executable hook, output the following based on its `optional` flag:\n  - **Optional hook** (`optional: true`):\n    ```\n    ## Extension Hooks\n\n    **Optional Pre-Hook**: {extension}\n    Command: `\u002F{command}`\n    Description: {description}\n\n    Prompt: {prompt}\n    To execute: `\u002F{command}`\n    ```\n  - **Mandatory hook** (`optional: false`):\n    ```\n    ## Extension Hooks\n\n    **Automatic Pre-Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n    \n    Wait for the result of the hook command before proceeding to the Outline.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Outline\n\n1. **Setup**: Run `.specify\u002Fscripts\u002Fbash\u002Fsetup-tasks.sh --json` from repo root and parse FEATURE_DIR, TASKS_TEMPLATE, and AVAILABLE_DOCS list. `FEATURE_DIR` and `TASKS_TEMPLATE` must be absolute paths when provided. `AVAILABLE_DOCS` is a list of document names\u002Frelative paths available under `FEATURE_DIR` (for example `research.md` or `contracts\u002F`). For single quotes in args like \"I'm Groot\", use escape syntax: e.g 'I'\\''m Groot' (or double-quote if possible: \"I'm Groot\").\n\n2. **Load design documents**: Read from FEATURE_DIR:\n   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)\n   - **Optional**: data-model.md (entities), contracts\u002F (interface contracts), research.md (decisions), quickstart.md (test scenarios)\n   - Note: Not all projects have all documents. Generate tasks based on what's available.\n\n3. **Execute task generation workflow**:\n   - Load plan.md and extract tech stack, libraries, project structure\n   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)\n   - If data-model.md exists: Extract entities and map to user stories\n   - If contracts\u002F exists: Map interface contracts to user stories\n   - If research.md exists: Extract decisions for setup tasks\n   - Generate tasks organized by user story (see Task Generation Rules below)\n   - Generate dependency graph showing user story completion order\n   - Create parallel execution examples per user story\n   - Validate task completeness (each user story has all needed tasks, independently testable)\n\n4. **Generate tasks.md**: Read the tasks template from TASKS_TEMPLATE (from the JSON output above) and use it as structure. If TASKS_TEMPLATE is empty, fall back to `.specify\u002Ftemplates\u002Ftasks-template.md`. Fill with:\n   - Correct feature name from plan.md\n   - Phase 1: Setup tasks (project initialization)\n   - Phase 2: Foundational tasks (blocking prerequisites for all user stories)\n   - Phase 3+: One phase per user story (in priority order from spec.md)\n   - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks\n   - Final Phase: Polish & cross-cutting concerns\n   - All tasks must follow the strict checklist format (see Task Generation Rules below)\n   - Clear file paths for each task\n   - Dependencies section showing story completion order\n   - Parallel execution examples per story\n   - Implementation strategy section (MVP first, incremental delivery)\n\n5. **Report**: Output path to generated tasks.md and summary:\n   - Total task count\n   - Task count per user story\n   - Parallel opportunities identified\n   - Independent test criteria for each story\n   - Suggested MVP scope (typically just User Story 1)\n   - Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)\n\n6. **Check for extension hooks**: After tasks.md is generated, check if `.specify\u002Fextensions.yml` exists in the project root.\n   - If it exists, read it and look for entries under the `hooks.after_tasks` key\n   - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n   - Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n   - For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n     - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n     - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n   - When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n   - For each executable hook, output the following based on its `optional` flag:\n     - **Optional hook** (`optional: true`):\n       ```\n       ## Extension Hooks\n\n       **Optional Hook**: {extension}\n       Command: `\u002F{command}`\n       Description: {description}\n\n       Prompt: {prompt}\n       To execute: `\u002F{command}`\n       ```\n     - **Mandatory hook** (`optional: false`):\n       ```\n       ## Extension Hooks\n\n       **Automatic Hook**: {extension}\n       Executing: `\u002F{command}`\n       EXECUTE_COMMAND: {command}\n       ```\n   - If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\nContext for task generation: $ARGUMENTS\n\nThe tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.\n\n## Task Generation Rules\n\n**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.\n\n**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.\n\n### Checklist Format (REQUIRED)\n\nEvery task MUST strictly follow this format:\n\n```text\n- [ ] [TaskID] [P?] [Story?] Description with file path\n```\n\n**Format Components**:\n\n1. **Checkbox**: ALWAYS start with `- [ ]` (markdown checkbox)\n2. **Task ID**: Sequential number (T001, T002, T003...) in execution order\n3. **[P] marker**: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)\n4. **[Story] label**: REQUIRED for user story phase tasks only\n   - Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)\n   - Setup phase: NO story label\n   - Foundational phase: NO story label  \n   - User Story phases: MUST have story label\n   - Polish phase: NO story label\n5. **Description**: Clear action with exact file path\n\n**Examples**:\n\n- ✅ CORRECT: `- [ ] T001 Create project structure per implementation plan`\n- ✅ CORRECT: `- [ ] T005 [P] Implement authentication middleware in src\u002Fmiddleware\u002Fauth.py`\n- ✅ CORRECT: `- [ ] T012 [P] [US1] Create User model in src\u002Fmodels\u002Fuser.py`\n- ✅ CORRECT: `- [ ] T014 [US1] Implement UserService in src\u002Fservices\u002Fuser_service.py`\n- ❌ WRONG: `- [ ] Create User model` (missing ID and Story label)\n- ❌ WRONG: `T001 [US1] Create model` (missing checkbox)\n- ❌ WRONG: `- [ ] [US1] Create User model` (missing Task ID)\n- ❌ WRONG: `- [ ] T001 [US1] Create model` (missing file path)\n\n### Task Organization\n\n1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:\n   - Each user story (P1, P2, P3...) gets its own phase\n   - Map all related components to their story:\n     - Models needed for that story\n     - Services needed for that story\n     - Interfaces\u002FUI needed for that story\n     - If tests requested: Tests specific to that story\n   - Mark story dependencies (most stories should be independent)\n\n2. **From Contracts**:\n   - Map each interface contract → to the user story it serves\n   - If tests requested: Each interface contract → contract test task [P] before implementation in that story's phase\n\n3. **From Data Model**:\n   - Map each entity to the user story(ies) that need it\n   - If entity serves multiple stories: Put in earliest story or Setup phase\n   - Relationships → service layer tasks in appropriate story phase\n\n4. **From Setup\u002FInfrastructure**:\n   - Shared infrastructure → Setup phase (Phase 1)\n   - Foundational\u002Fblocking tasks → Foundational phase (Phase 2)\n   - Story-specific setup → within that story's phase\n\n### Phase Structure\n\n- **Phase 1**: Setup (project initialization)\n- **Phase 2**: Foundational (blocking prerequisites - MUST complete before user stories)\n- **Phase 3+**: User Stories in priority order (P1, P2, P3...)\n  - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration\n  - Each phase should be a complete, independently testable increment\n- **Final Phase**: Polish & Cross-Cutting Concerns\n","## User Input\n\n```text\n$ARGUMENTS\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Pre-Execution Checks\n\n**Check for extension hooks (before tasks generation)**:\n- Check if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.before_tasks` key\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n  - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n- For each executable hook, output the following based on its `optional` flag:\n  - **Optional hook** (`optional: true`):\n    ```\n    ## Extension Hooks\n\n    **Optional Pre-Hook**: {extension}\n    Command: `\u002F{command}`\n    Description: {description}\n\n    Prompt: {prompt}\n    To execute: `\u002F{command}`\n    ```\n  - **Mandatory hook** (`optional: false`):\n    ```\n    ## Extension Hooks\n\n    **Automatic Pre-Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n    \n    Wait for the result of the hook command before proceeding to the Outline.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Outline\n\n1. **Setup**: Run `.specify\u002Fscripts\u002Fbash\u002Fsetup-tasks.sh --json` from repo root and parse FEATURE_DIR, TASKS_TEMPLATE, and AVAILABLE_DOCS list. `FEATURE_DIR` and `TASKS_TEMPLATE` must be absolute paths when provided. `AVAILABLE_DOCS` is a list of document names\u002Frelative paths available under `FEATURE_DIR` (for example `research.md` or `contracts\u002F`). For single quotes in args like \"I'm Groot\", use escape syntax: e.g 'I'\\''m Groot' (or double-quote if possible: \"I'm Groot\").\n\n2. **Load design documents**: Read from FEATURE_DIR:\n   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)\n   - **Optional**: data-model.md (entities), contracts\u002F (interface contracts), research.md (decisions), quickstart.md (test scenarios)\n   - Note: Not all projects have all documents. Generate tasks based on what's available.\n\n3. **Execute task generation workflow**:\n   - Load plan.md and extract tech stack, libraries, project structure\n   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)\n   - If data-model.md exists: Extract entities and map to user stories\n   - If contracts\u002F exists: Map interface contracts to user stories\n   - If research.md exists: Extract decisions for setup tasks\n   - Generate tasks organized by user story (see Task Generation Rules below)\n   - Generate dependency graph showing user story completion order\n   - Create parallel execution examples per user story\n   - Validate task completeness (each user story has all needed tasks, independently testable)\n\n4. **Generate tasks.md**: Read the tasks template from TASKS_TEMPLATE (from the JSON output above) and use it as structure. If TASKS_TEMPLATE is empty, fall back to `.specify\u002Ftemplates\u002Ftasks-template.md`. Fill with:\n   - Correct feature name from plan.md\n   - Phase 1: Setup tasks (project initialization)\n   - Phase 2: Foundational tasks (blocking prerequisites for all user stories)\n   - Phase 3+: One phase per user story (in priority order from spec.md)\n   - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks\n   - Final Phase: Polish & cross-cutting concerns\n   - All tasks must follow the strict checklist format (see Task Generation Rules below)\n   - Clear file paths for each task\n   - Dependencies section showing story completion order\n   - Parallel execution examples per story\n   - Implementation strategy section (MVP first, incremental delivery)\n\n5. **Report**: Output path to generated tasks.md and summary:\n   - Total task count\n   - Task count per user story\n   - Parallel opportunities identified\n   - Independent test criteria for each story\n   - Suggested MVP scope (typically just User Story 1)\n   - Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)\n\n6. **Check for extension hooks**: After tasks.md is generated, check if `.specify\u002Fextensions.yml` exists in the project root.\n   - If it exists, read it and look for entries under the `hooks.after_tasks` key\n   - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n   - Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n   - For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n     - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n     - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n   - When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n   - For each executable hook, output the following based on its `optional` flag:\n     - **Optional hook** (`optional: true`):\n       ```\n       ## Extension Hooks\n\n       **Optional Hook**: {extension}\n       Command: `\u002F{command}`\n       Description: {description}\n\n       Prompt: {prompt}\n       To execute: `\u002F{command}`\n       ```\n     - **Mandatory hook** (`optional: false`):\n       ```\n       ## Extension Hooks\n\n       **Automatic Hook**: {extension}\n       Executing: `\u002F{command}`\n       EXECUTE_COMMAND: {command}\n       ```\n   - If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\nContext for task generation: $ARGUMENTS\n\nThe tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.\n\n## Task Generation Rules\n\n**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.\n\n**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.\n\n### Checklist Format (REQUIRED)\n\nEvery task MUST strictly follow this format:\n\n```text\n- [ ] [TaskID] [P?] [Story?] Description with file path\n```\n\n**Format Components**:\n\n1. **Checkbox**: ALWAYS start with `- [ ]` (markdown checkbox)\n2. **Task ID**: Sequential number (T001, T002, T003...) in execution order\n3. **[P] marker**: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)\n4. **[Story] label**: REQUIRED for user story phase tasks only\n   - Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)\n   - Setup phase: NO story label\n   - Foundational phase: NO story label  \n   - User Story phases: MUST have story label\n   - Polish phase: NO story label\n5. **Description**: Clear action with exact file path\n\n**Examples**:\n\n- ✅ CORRECT: `- [ ] T001 Create project structure per implementation plan`\n- ✅ CORRECT: `- [ ] T005 [P] Implement authentication middleware in src\u002Fmiddleware\u002Fauth.py`\n- ✅ CORRECT: `- [ ] T012 [P] [US1] Create User model in src\u002Fmodels\u002Fuser.py`\n- ✅ CORRECT: `- [ ] T014 [US1] Implement UserService in src\u002Fservices\u002Fuser_service.py`\n- ❌ WRONG: `- [ ] Create User model` (missing ID and Story label)\n- ❌ WRONG: `T001 [US1] Create model` (missing checkbox)\n- ❌ WRONG: `- [ ] [US1] Create User model` (missing Task ID)\n- ❌ WRONG: `- [ ] T001 [US1] Create model` (missing file path)\n\n### Task Organization\n\n1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:\n   - Each user story (P1, P2, P3...) gets its own phase\n   - Map all related components to their story:\n     - Models needed for that story\n     - Services needed for that story\n     - Interfaces\u002FUI needed for that story\n     - If tests requested: Tests specific to that story\n   - Mark story dependencies (most stories should be independent)\n\n2. **From Contracts**:\n   - Map each interface contract → to the user story it serves\n   - If tests requested: Each interface contract → contract test task [P] before implementation in that story's phase\n\n3. **From Data Model**:\n   - Map each entity to the user story(ies) that need it\n   - If entity serves multiple stories: Put in earliest story or Setup phase\n   - Relationships → service layer tasks in appropriate story phase\n\n4. **From Setup\u002FInfrastructure**:\n   - Shared infrastructure → Setup phase (Phase 1)\n   - Foundational\u002Fblocking tasks → Foundational phase (Phase 2)\n   - Story-specific setup → within that story's phase\n\n### Phase Structure\n\n- **Phase 1**: Setup (project initialization)\n- **Phase 2**: Foundational (blocking prerequisites - MUST complete before user stories)\n- **Phase 3+**: User Stories in priority order (P1, P2, P3...)\n  - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration\n  - Each phase should be a complete, independently testable increment\n- **Final Phase**: Polish & Cross-Cutting Concerns\n",{"name":5,"metadata":44,"description":7,"argument-hint":47,"compatibility":48,"user-invocable":49,"disable-model-invocation":40},{"author":45,"source":46},"github-spec-kit","templates\u002Fcommands\u002Ftasks.md","Optional task generation constraints","Requires spec-kit project structure with .specify\u002F directory",true,"main","7546eb50cf658dad033c5a047a7ec89c9d1ee7f4",".agents\u002Fskills\u002Fspeckit-tasks",4,"https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex","https:\u002F\u002Fgitguardex.com\u002F","https:\u002F\u002Fgithub.com\u002Fopencue","Building in the open. From AI-powered workflows and developer tools to web experiences, automation, and e-commerce — practical software for real-world problems.","2026-11-12 18:11:01",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":49},[61,64,67],{"tool":62,"command":63},"npx","npx skills add opencue\u002Fgitguardex --skill speckit-tasks",{"tool":65,"command":66},"bunx","bunx skills add opencue\u002Fgitguardex --skill speckit-tasks",{"tool":68,"command":69},"pnpm","pnpm dlx skills add opencue\u002Fgitguardex --skill speckit-tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[73,91,116,141,159,174],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":39},"01M6QEBH0VSDT0T2HX5XE3VW5F","opensrc","Fetch exact dependency or external repository source before inspecting internals. Use for package implementation, upstream behavior, or external GitHub source lookup.","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002Ftemplates\u002Fcodex\u002Fskills\u002Fopensrc\u002FSKILL.md",[],[75,80,23,81,82,33,83,84,85,86,87,88,89,90],"lookup","upstream","implementation","use","fetch","behavior","Bash","repository","package","github","source",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":102,"publishedAt":39},"01M6QEBDNSWK5R390QHGFWP601","gx-act","Run GitHub Actions workflows locally with nektos\u002Fact before pushing, so CI failures are caught on the laptop and the PR can be squash-merged on the first remote run.","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002Ftemplates\u002Fcodex\u002Fskills\u002Fgx-act\u002FSKILL.md",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[103,104,105,106,89,107,108,109,110,111,112,113,114,115],"gx act","act","pr","workflows","run","actions","first","ci","can","with","remote","squash","github actions",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":125,"publishedAt":39},"01M6QEBAQ8HA4ZGNDS03AB25Y7","guardex-merge-skills-to-dev","Use when you need to merge SKILL.md updates from agent branches\u002Fworktrees into the local base branch (default: dev) with the multiagent-safety flow.","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002Ftemplates\u002Fcodex\u002Fskills\u002Fguardex-merge-skills-to-dev\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000023","Skill与智能体开发",[126,127,128,129,112,130,131,132,133,134,135,136,83,137,138,139,140],"guardex merge skills to dev","guardex","merge","dev","updates","you","local","branches","base","default","worktrees","branch","Safety","flow","multiagent",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":39},"01M6QEB1MG3NCEZ9DP310AAANC","gitguardex","Use for GitGuardex branch\u002Fworktree safety, agent or subagent collision avoidance, file ownership, and gated PR finishing. Not for code-quality review.","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002Ftemplates\u002Fcodex\u002Fskills\u002Fgitguardex\u002FSKILL.md",[147],{"categoryNo":123,"categoryName":124,"taxonomyType":100,"taxonomyTypeDesc":101},[143,149,23,150,151,152,83,137,153,154,138,155,156,157,105,158],"subagent","ownership","quality review","gated","quality","code-quality","file","worktree","code","review",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":39},"01M6QEAYMVDN8RZCVHQS7YNCBJ","pr-lens","Generate local PR Lens architecture and data-flow diagrams alongside a GitGuardex Codex or Claude PR review.","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002Fskills\u002Fpr-lens\u002FSKILL.md",[],[105,166,167,168,169,139,36,170,171,172,158,173,143,132],"lens","pr lens","data-flow","data","pr review","architecture","codex","diagrams",{"skillNo":175,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":39},"01M6QEAVDZQRKP05NHQ2AWR3MY","https:\u002F\u002Fgithub.com\u002Fopencue\u002Fgitguardex\u002Fblob\u002Fmain\u002Fskills\u002Fgx-act\u002FSKILL.md",[178],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},[104,103,89,112,111,113,114,109,115,110,108,107,105,106]]