[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JTANE4XT8JRNHJ7TFHD2B1":3,"skill-same:01M6JTANE4XT8JRNHJ7TFHD2B1":84},{"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":26,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M6JTANE4XT8JRNHJ7TFHD2B1","run-work",null,"Execute a work unit end-to-end: sequence tasks by dependency, implement, test between tasks, commit, and track progress. Use to deliver a complete feature in one session. Invoked as \u002Fagiflow:run-work \u003Cwork-unit>. Uses get_work_unit, list_tasks, update_task, get_work_unit_progress.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAgiFlow\u002Fai-plugin\u002Fskills\u002Frun-work\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"run","run work","work","get","deliver","track","sequence","unit","complete","progress","as","end","feature","MCP","dependency","session","list","api","execution","update","tasks","commit","2026-11-10 10:12:30",false,"---\nname: run-work\ndescription: \"Execute a work unit end-to-end: sequence tasks by dependency, implement, test between tasks, commit, and track progress. Use to deliver a complete feature in one session. Invoked as \u002Fagiflow:run-work \u003Cwork-unit>. Uses get_work_unit, list_tasks, update_task, get_work_unit_progress.\"\ntags:\n  - agiflow\n  - mcp\n  - execution\n  - work-unit\nmetadata:\n  mirrors: backend\u002Fapis\u002Fagiflow-api ...\u002Fprompts\u002Fwork.md\n---\n\n> Invoked as `\u002Fagiflow:run-work`. In hosts without slash-prompts, this skill is triggered by matching intent and drives AgiFlow via its MCP tools.\n\n**Usage**:\n\n- `\u002Fagiflow:run-work \u003Cwork-unit-slug-or-id>` - Execute specific work unit\n- `\u002Fagiflow:run-work` - List and select from available work units\n\n**Examples**:\n\n- `\u002Fagiflow:run-work DXX-WU-1` (using slug)\n- `\u002Fagiflow:run-work 01K8FABMNEJG1XTA9JGHSNFV40` (using ID)\n- `\u002Fagiflow:run-work` (interactive selection)\n\n---\n\n**Guardrails**\n\n- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.\n- Keep changes tightly scoped to the requested outcome within the work unit scope.\n- A work unit represents a cohesive feature\u002Fepic that can be completed in one Claude Code session.\n\nIf a work unit slug\u002Fid is provided, load it with `get_work_unit`; otherwise list available work units with `list_work_units` for selection.\n\n---\n\n## AgiFlow Project Management Guidelines\n\nFollow the shared AgiFlow project-management guidelines in [`references\u002Fagiflow-agents.md`](..\u002F..\u002Freferences\u002Fagiflow-agents.md) — agent assignment, the task status workflow and transitions, work-unit best practices, and the tags strategy apply to this workflow.\n\n\n---\n\n**Task Status Workflow (per task)**\nEach task moves individually through: `Todo → In Progress → Testing → Review`\nThe work unit stays `in_progress` until all tasks reach `Review` or `Done`.\nIf any task hits `Blocked`, consider setting the work unit to `blocked` too.\n\n**IMPORTANT: Planning Status Guard**\nThis skill ONLY executes tasks in \"Todo\" or later status. Tasks in \"Planning\" have NOT been groomed and are NOT ready for execution. Use `backlog-grooming` to promote Planning tasks to Todo first.\n\n**Steps**\nTrack these steps as TODOs and complete them one by one.\n\n## 1. Work Unit Selection & Loading\n\n**If work unit slug\u002Fid NOT provided:**\n\n1. Use `list_work_units` MCP tool to show available work units:\n   - Filter by `status: \"in_progress\"` for active work, or work units with tasks in \"Todo\"\n   - Do NOT pick up work units where all tasks are still in \"Planning\" status\n   - Display: slug, title, type, priority, task count, status\n2. Ask user to select which work unit to work on.\n3. Once user selects, proceed with the selected work unit slug\u002Fid.\n\n**If work unit slug\u002Fid IS provided:** 4. Use `get_work_unit` MCP tool with the provided slug\u002Fid to retrieve:\n\n- Work unit: title, description, goals, type, priority, status, dates, devInfo\n- Tasks: All tasks associated with this work unit (already included in response)\n- Note: `get_work_unit` returns tasks automatically - no separate `list_tasks` call needed\n\n5. Review the work unit and all its tasks to understand:\n   - Complete feature scope and deliverables\n   - Task dependencies and execution order\n   - Acceptance criteria across all tasks\n\n**5b. PLANNING STATUS GUARD (MANDATORY):**\n\n- Check all tasks in the work unit\n- If ANY task has status \"Planning\": **REFUSE to execute**\n- Report: \"Cannot execute: N task(s) are still in Planning status. Use **backlog-grooming** to promote them to Todo first.\"\n- List the Planning tasks by title\n- **STOP execution** — do not proceed\n\n## 2. Start Work Unit Execution\n\n6. If work unit status is \"planning\":\n   - First verify ALL tasks are in \"Todo\" or later status (not \"Planning\")\n   - If verified, use `update_work_unit` MCP tool to set status to \"in_progress\"\n   - If any tasks are in \"Planning\", REFUSE and suggest `backlog-grooming`\n7. Create a TODO list of all tasks in execution order (use TodoWrite tool).\n8. Document execution plan in work unit via `update_work_unit` devInfo:\n   ```typescript\n   devInfo: {\n     executionPlan: \"Backend API → Frontend UI → Tests → Documentation\",\n     sessionId: \"\u003Ccurrent-session-id>\",\n     startedAt: \"\u003Ctimestamp>\"\n   }\n   ```\n\n## 3. Execute Tasks Sequentially\n\n9. For each task in the work unit (in dependency order from the tasks array):\n   - Review task details: title, description, acceptance criteria, assignee\n   - Use `update_task` MCP tool to set status to \"In Progress\"\n   - **BEFORE editing any code**: Use `architect` MCP `get_file_design_pattern` (MANDATORY)\n   - Implement the task following acceptance criteria\n   - **AFTER editing code**: Use `architect` MCP `review_code_change` (MANDATORY)\n   - Update task `devInfo` with implementation notes:\n     ```typescript\n     devInfo: {\n       filesChanged: [\"path\u002Fto\u002Ffile.ts:42\"],\n       testResults: { passed: true, coverage: \"85%\" },\n       notes: \"Implementation notes here\"\n     }\n     ```\n   - Mark acceptance criteria as checked via `update_task`\n\n   **Testing phase for each task:**\n   - Use `update_task` to move status to \"Testing\"\n   - Run unit tests, integration tests, type check and lint for affected code\n   - **If tests PASS**: proceed to move task to \"Review\"\n   - **If tests FAIL**:\n     - Increment `retryCount` in devInfo\n     - If `retryCount >= maxRetries` (default: 2): move task to \"Blocked\", set work unit to \"blocked\", stop\n     - If `retryCount \u003C maxRetries`: move task back to \"Todo\", document failure, continue to next task or stop session\n   - Use `update_task` to set status to \"Review\" when tests pass\n\n   - Update your TODO list (mark task as completed)\n\n10. Between tasks:\n    - Commit changes with meaningful commit messages\n    - Run tests to ensure no regressions\n    - Update work unit progress in devInfo\n\n## 4. Work Unit Progress Tracking\n\n11. The work unit tasks array automatically updates as tasks are completed.\n    - Use `get_work_unit` to check current state and task statuses\n    - Track: How many tasks in Review or Done vs. total?\n    - Monitor: Are we on track for target date?\n    - Work unit stays `in_progress` until all tasks reach `Review` or `Done`\n\n12. Update work unit `devInfo` as you progress via `update_work_unit`:\n    ```typescript\n    devInfo: {\n      executionPlan: \"...\",\n      sessionId: \"\u003Csession-id>\",\n      startedAt: \"\u003Ctimestamp>\",\n      progress: {\n        completedTasks: 3,\n        totalTasks: 8,\n        lastTaskCompleted: \"Implement cart API\",\n        currentTask: \"Add cart UI component\"\n      },\n      testResults: {\n        unitTests: \"passing\",\n        integrationTests: \"passing\",\n        coverage: \"85%\"\n      },\n      blockers: [] \u002F\u002F or list any blockers encountered\n    }\n    ```\n\n## 5. Work Unit Completion\n\n13. When ALL tasks in work unit are in \"Review\" or \"Done\":\n    - Verify all tasks have status \"Review\" or \"Done\"\n    - Verify all acceptance criteria across all tasks are met\n    - Run full test suite for the feature\n    - Review all files changed (use git diff)\n\n14. Draft a PR description for the work unit (DO NOT create the PR yet - just draft the text):\n    - Title format: `[WORK-UNIT-SLUG] Work unit title` (e.g., `[DXX-WU-1] Shopping cart feature`)\n    - Body should include:\n      - Work unit reference and summary\n      - List of tasks completed\n      - Summary of all changes across tasks\n      - Files modified (use `file.ts:42` format)\n      - Test results\n\n15. Use `update_work_unit` to set status to \"completed\" and save draft PR text and commit message:\n\n    ```typescript\n    {\n      status: \"completed\",\n      completedAt: new Date(),\n      devInfo: {\n        ...existing,\n        draftCommitMessage: \"feat(cart): implement shopping cart feature\\n\\n- Add cart API endpoints\\n- Add cart UI components\\n- Add integration tests\\n\\nCloses: DXX-WU-1\",\n        draftPr: {\n          title: \"[DXX-WU-1] Shopping cart feature\",\n          body: \"## Summary\\n\\nImplemented shopping cart feature.\\n\\n## Tasks Completed\\n\\n- [DXX-1] Add cart API\\n- [DXX-2] Add cart UI\\n- [DXX-3] Add cart tests\\n\\n## Changes\\n\\n- Added cart endpoints\\n- Added cart components\\n- Added integration tests\\n\\n## Files Modified\\n\\n- src\u002Fapi\u002Fcart.ts:42\\n- src\u002Fcomponents\u002FCart.tsx:15\\n- tests\u002Fcart.test.ts:1\\n\\n## Test Results\\n\\nAll tests passing. Coverage: 85%\"\n        },\n        finalNotes: \"All tasks completed. Files changed: [...]. Tests passing.\",\n        completedBy: \"\u003Cmember-id>\",\n        totalDuration: \"3.5 hours\"\n      }\n    }\n    ```\n\n    **Note on draftCommitMessage**: Write a conventional commit message that will be used for the final git commit. Format: `type(scope): description` with optional body listing changes.\n\n16. Create final summary comment documenting:\n    - Work unit scope and goals achieved\n    - All files created\u002Fmodified (use `file.ts:42` format)\n    - Test coverage and results\n    - Any follow-up work needed\n    - Performance or architectural notes\n\n## 6. Handle Blockers or Scope Changes\n\n17. If blocked on a task:\n    - Use `update_task` to set task status to \"Blocked\"\n    - Use `update_work_unit` to set status to \"blocked\"\n    - Document blocker in work unit devInfo\n    - Use `create_task_comment` on blocked task with details explaining what human intervention is needed\n    - Consider creating follow-up tasks for blockers\n\n18. If scope changes during execution:\n    - Use `create_task` to add new tasks to work unit\n    - Update work unit description\u002Fgoals if needed\n    - Communicate scope change in work unit comments\n\n**Common Mistakes to Avoid**\n\n- ❌ Starting without reviewing all tasks in work unit (lack of context)\n- ❌ Working on tasks in wrong order (missing dependencies)\n- ❌ Skipping vibe-lint MCP validation (MANDATORY for every file)\n- ❌ Not tracking work unit-level progress in devInfo\n- ❌ Completing tasks in isolation without considering work unit goals\n- ❌ Not running integration tests between tasks\n- ❌ Moving task to \"Review\" without first going through \"Testing\"\n- ❌ Marking work unit complete when tasks are still in \"In Progress\" or \"Testing\"\n- ❌ Not documenting scope changes or blockers\n- ❌ Forgetting to commit between tasks (losing incremental progress)\n- ❌ Not updating work unit status when blocked\n- ❌ Setting work unit to \"completed\" before all tasks reach \"Review\" or \"Done\"\n- ❌ Executing tasks that are still in \"Planning\" status (must be promoted to \"Todo\" via `backlog-grooming` first)\n","> Invoked as `\u002Fagiflow:run-work`. In hosts without slash-prompts, this skill is triggered by matching intent and drives AgiFlow via its MCP tools.\n\n**Usage**:\n\n- `\u002Fagiflow:run-work \u003Cwork-unit-slug-or-id>` - Execute specific work unit\n- `\u002Fagiflow:run-work` - List and select from available work units\n\n**Examples**:\n\n- `\u002Fagiflow:run-work DXX-WU-1` (using slug)\n- `\u002Fagiflow:run-work 01K8FABMNEJG1XTA9JGHSNFV40` (using ID)\n- `\u002Fagiflow:run-work` (interactive selection)\n\n---\n\n**Guardrails**\n\n- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.\n- Keep changes tightly scoped to the requested outcome within the work unit scope.\n- A work unit represents a cohesive feature\u002Fepic that can be completed in one Claude Code session.\n\nIf a work unit slug\u002Fid is provided, load it with `get_work_unit`; otherwise list available work units with `list_work_units` for selection.\n\n---\n\n## AgiFlow Project Management Guidelines\n\nFollow the shared AgiFlow project-management guidelines in [`references\u002Fagiflow-agents.md`](..\u002F..\u002Freferences\u002Fagiflow-agents.md) — agent assignment, the task status workflow and transitions, work-unit best practices, and the tags strategy apply to this workflow.\n\n\n---\n\n**Task Status Workflow (per task)**\nEach task moves individually through: `Todo → In Progress → Testing → Review`\nThe work unit stays `in_progress` until all tasks reach `Review` or `Done`.\nIf any task hits `Blocked`, consider setting the work unit to `blocked` too.\n\n**IMPORTANT: Planning Status Guard**\nThis skill ONLY executes tasks in \"Todo\" or later status. Tasks in \"Planning\" have NOT been groomed and are NOT ready for execution. Use `backlog-grooming` to promote Planning tasks to Todo first.\n\n**Steps**\nTrack these steps as TODOs and complete them one by one.\n\n## 1. Work Unit Selection & Loading\n\n**If work unit slug\u002Fid NOT provided:**\n\n1. Use `list_work_units` MCP tool to show available work units:\n   - Filter by `status: \"in_progress\"` for active work, or work units with tasks in \"Todo\"\n   - Do NOT pick up work units where all tasks are still in \"Planning\" status\n   - Display: slug, title, type, priority, task count, status\n2. Ask user to select which work unit to work on.\n3. Once user selects, proceed with the selected work unit slug\u002Fid.\n\n**If work unit slug\u002Fid IS provided:** 4. Use `get_work_unit` MCP tool with the provided slug\u002Fid to retrieve:\n\n- Work unit: title, description, goals, type, priority, status, dates, devInfo\n- Tasks: All tasks associated with this work unit (already included in response)\n- Note: `get_work_unit` returns tasks automatically - no separate `list_tasks` call needed\n\n5. Review the work unit and all its tasks to understand:\n   - Complete feature scope and deliverables\n   - Task dependencies and execution order\n   - Acceptance criteria across all tasks\n\n**5b. PLANNING STATUS GUARD (MANDATORY):**\n\n- Check all tasks in the work unit\n- If ANY task has status \"Planning\": **REFUSE to execute**\n- Report: \"Cannot execute: N task(s) are still in Planning status. Use **backlog-grooming** to promote them to Todo first.\"\n- List the Planning tasks by title\n- **STOP execution** — do not proceed\n\n## 2. Start Work Unit Execution\n\n6. If work unit status is \"planning\":\n   - First verify ALL tasks are in \"Todo\" or later status (not \"Planning\")\n   - If verified, use `update_work_unit` MCP tool to set status to \"in_progress\"\n   - If any tasks are in \"Planning\", REFUSE and suggest `backlog-grooming`\n7. Create a TODO list of all tasks in execution order (use TodoWrite tool).\n8. Document execution plan in work unit via `update_work_unit` devInfo:\n   ```typescript\n   devInfo: {\n     executionPlan: \"Backend API → Frontend UI → Tests → Documentation\",\n     sessionId: \"\u003Ccurrent-session-id>\",\n     startedAt: \"\u003Ctimestamp>\"\n   }\n   ```\n\n## 3. Execute Tasks Sequentially\n\n9. For each task in the work unit (in dependency order from the tasks array):\n   - Review task details: title, description, acceptance criteria, assignee\n   - Use `update_task` MCP tool to set status to \"In Progress\"\n   - **BEFORE editing any code**: Use `architect` MCP `get_file_design_pattern` (MANDATORY)\n   - Implement the task following acceptance criteria\n   - **AFTER editing code**: Use `architect` MCP `review_code_change` (MANDATORY)\n   - Update task `devInfo` with implementation notes:\n     ```typescript\n     devInfo: {\n       filesChanged: [\"path\u002Fto\u002Ffile.ts:42\"],\n       testResults: { passed: true, coverage: \"85%\" },\n       notes: \"Implementation notes here\"\n     }\n     ```\n   - Mark acceptance criteria as checked via `update_task`\n\n   **Testing phase for each task:**\n   - Use `update_task` to move status to \"Testing\"\n   - Run unit tests, integration tests, type check and lint for affected code\n   - **If tests PASS**: proceed to move task to \"Review\"\n   - **If tests FAIL**:\n     - Increment `retryCount` in devInfo\n     - If `retryCount >= maxRetries` (default: 2): move task to \"Blocked\", set work unit to \"blocked\", stop\n     - If `retryCount \u003C maxRetries`: move task back to \"Todo\", document failure, continue to next task or stop session\n   - Use `update_task` to set status to \"Review\" when tests pass\n\n   - Update your TODO list (mark task as completed)\n\n10. Between tasks:\n    - Commit changes with meaningful commit messages\n    - Run tests to ensure no regressions\n    - Update work unit progress in devInfo\n\n## 4. Work Unit Progress Tracking\n\n11. The work unit tasks array automatically updates as tasks are completed.\n    - Use `get_work_unit` to check current state and task statuses\n    - Track: How many tasks in Review or Done vs. total?\n    - Monitor: Are we on track for target date?\n    - Work unit stays `in_progress` until all tasks reach `Review` or `Done`\n\n12. Update work unit `devInfo` as you progress via `update_work_unit`:\n    ```typescript\n    devInfo: {\n      executionPlan: \"...\",\n      sessionId: \"\u003Csession-id>\",\n      startedAt: \"\u003Ctimestamp>\",\n      progress: {\n        completedTasks: 3,\n        totalTasks: 8,\n        lastTaskCompleted: \"Implement cart API\",\n        currentTask: \"Add cart UI component\"\n      },\n      testResults: {\n        unitTests: \"passing\",\n        integrationTests: \"passing\",\n        coverage: \"85%\"\n      },\n      blockers: [] \u002F\u002F or list any blockers encountered\n    }\n    ```\n\n## 5. Work Unit Completion\n\n13. When ALL tasks in work unit are in \"Review\" or \"Done\":\n    - Verify all tasks have status \"Review\" or \"Done\"\n    - Verify all acceptance criteria across all tasks are met\n    - Run full test suite for the feature\n    - Review all files changed (use git diff)\n\n14. Draft a PR description for the work unit (DO NOT create the PR yet - just draft the text):\n    - Title format: `[WORK-UNIT-SLUG] Work unit title` (e.g., `[DXX-WU-1] Shopping cart feature`)\n    - Body should include:\n      - Work unit reference and summary\n      - List of tasks completed\n      - Summary of all changes across tasks\n      - Files modified (use `file.ts:42` format)\n      - Test results\n\n15. Use `update_work_unit` to set status to \"completed\" and save draft PR text and commit message:\n\n    ```typescript\n    {\n      status: \"completed\",\n      completedAt: new Date(),\n      devInfo: {\n        ...existing,\n        draftCommitMessage: \"feat(cart): implement shopping cart feature\\n\\n- Add cart API endpoints\\n- Add cart UI components\\n- Add integration tests\\n\\nCloses: DXX-WU-1\",\n        draftPr: {\n          title: \"[DXX-WU-1] Shopping cart feature\",\n          body: \"## Summary\\n\\nImplemented shopping cart feature.\\n\\n## Tasks Completed\\n\\n- [DXX-1] Add cart API\\n- [DXX-2] Add cart UI\\n- [DXX-3] Add cart tests\\n\\n## Changes\\n\\n- Added cart endpoints\\n- Added cart components\\n- Added integration tests\\n\\n## Files Modified\\n\\n- src\u002Fapi\u002Fcart.ts:42\\n- src\u002Fcomponents\u002FCart.tsx:15\\n- tests\u002Fcart.test.ts:1\\n\\n## Test Results\\n\\nAll tests passing. Coverage: 85%\"\n        },\n        finalNotes: \"All tasks completed. Files changed: [...]. Tests passing.\",\n        completedBy: \"\u003Cmember-id>\",\n        totalDuration: \"3.5 hours\"\n      }\n    }\n    ```\n\n    **Note on draftCommitMessage**: Write a conventional commit message that will be used for the final git commit. Format: `type(scope): description` with optional body listing changes.\n\n16. Create final summary comment documenting:\n    - Work unit scope and goals achieved\n    - All files created\u002Fmodified (use `file.ts:42` format)\n    - Test coverage and results\n    - Any follow-up work needed\n    - Performance or architectural notes\n\n## 6. Handle Blockers or Scope Changes\n\n17. If blocked on a task:\n    - Use `update_task` to set task status to \"Blocked\"\n    - Use `update_work_unit` to set status to \"blocked\"\n    - Document blocker in work unit devInfo\n    - Use `create_task_comment` on blocked task with details explaining what human intervention is needed\n    - Consider creating follow-up tasks for blockers\n\n18. If scope changes during execution:\n    - Use `create_task` to add new tasks to work unit\n    - Update work unit description\u002Fgoals if needed\n    - Communicate scope change in work unit comments\n\n**Common Mistakes to Avoid**\n\n- ❌ Starting without reviewing all tasks in work unit (lack of context)\n- ❌ Working on tasks in wrong order (missing dependencies)\n- ❌ Skipping vibe-lint MCP validation (MANDATORY for every file)\n- ❌ Not tracking work unit-level progress in devInfo\n- ❌ Completing tasks in isolation without considering work unit goals\n- ❌ Not running integration tests between tasks\n- ❌ Moving task to \"Review\" without first going through \"Testing\"\n- ❌ Marking work unit complete when tasks are still in \"In Progress\" or \"Testing\"\n- ❌ Not documenting scope changes or blockers\n- ❌ Forgetting to commit between tasks (losing incremental progress)\n- ❌ Not updating work unit status when blocked\n- ❌ Setting work unit to \"completed\" before all tasks reach \"Review\" or \"Done\"\n- ❌ Executing tasks that are still in \"Planning\" status (must be promoted to \"Todo\" via `backlog-grooming` first)\n",{"name":5,"tags":54,"metadata":58,"description":7},[55,56,45,57],"agiflow","mcp","work-unit",{"mirrors":59},"backend\u002Fapis\u002Fagiflow-api ...\u002Fprompts\u002Fwork.md","main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FAgiFlow\u002Fai-plugin\u002Fskills\u002Frun-work",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill run-work",{"tool":76,"command":77},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill run-work",{"tool":79,"command":80},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill run-work","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAgiFlow\u002Fai-plugin\u002Fskills\u002Frun-work\u002FSKILL.md",true,[],[85,93,100,107,134,157],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":92},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":92},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":92},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":49},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":49},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[141,142,143,129,144,145,146,147,148,149,150,151,152,153,119,154,155,42,38,156],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","reflection",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":168,"publishedAt":49},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[163,166,167],{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[159,169,170,171,172,173,174,155,175,120,176,177,40,178,125,179,180,181,44,182],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","song","image","mcp server","schedule","publish"]