[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GKKR3A5WRYCW35ES2A2F82":3,"skill-same:01M6GKKR3A5WRYCW35ES2A2F82":53},{"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":25,"linkOnly":26,"markdownContent":27,"markdownBody":28,"frontMatter":29,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":35,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6GKKR3A5WRYCW35ES2A2F82","implement",null,"Execute the implementation plan by processing and executing all tasks defined in tasks.md","akka\u002Fai-marketplace","akka","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1496237?v=4","01M6GKH3JJ5SR8SQ5BZRDFGZE2","Akka Project","01M6GKH3PK33JW3NNCJE2C1PZC",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fimplement\u002FSKILL.md",[],[5,19,20,21,22,23,24],"tasks","plan","execute","implementation","processing","implementation plan","2026-11-10 10:12:30",false,"---\nname: implement\ndescription: \"Execute the implementation plan by processing and executing all tasks defined in tasks.md\"\n---\n\n## User Input\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Outline\n\n1. Call the `akka_sdd_list_specs` MCP tool to find features. Verify that tasks.md exists for the target feature (has_tasks must be true). If tasks.md is missing, instruct the user to run `\u002Fakka:tasks` first. Read the tasks.md content from FEATURE_DIR. Also note which other artifacts are available (AVAILABLE_DOCS).\n\n2. **Create or check out the feature branch**:\n   - Read the spec.md from FEATURE_DIR and find the **Feature Branch** field (e.g. `001-counter-service`)\n   - Call `akka_git_status` to check the current branch\n   - If not already on the feature branch, call `akka_git_create_branch` with the branch name from the spec\n   - All implementation work must happen on the feature branch, not on `main`\n\n3. **Check checklists status** (if FEATURE_DIR\u002Fchecklists\u002F exists):\n   - Scan all checklist files in the checklists\u002F directory\n   - For each checklist, count:\n     - Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`\n     - Completed items: Lines matching `- [X]` or `- [x]`\n     - Incomplete items: Lines matching `- [ ]`\n   - Create a status table:\n\n     ```text\n     | Checklist | Total | Completed | Incomplete | Status |\n     |-----------|-------|-----------|------------|--------|\n     | ux.md     | 12    | 12        | 0          | ✓ PASS |\n     | test.md   | 8     | 5         | 3          | ✗ FAIL |\n     | security.md | 6   | 6         | 0          | ✓ PASS |\n     ```\n\n   - Calculate overall status:\n     - **PASS**: All checklists have 0 incomplete items\n     - **FAIL**: One or more checklists have incomplete items\n\n   - **If any checklist is incomplete**:\n     - Display the table with incomplete item counts\n     - **STOP** and ask: \"Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes\u002Fno)\"\n     - Wait for user response before continuing\n     - If user says \"no\" or \"wait\" or \"stop\", halt execution\n     - If user says \"yes\" or \"proceed\" or \"continue\", proceed to step 3\n\n   - **If all checklists are complete**:\n     - Display the table showing all checklists passed\n     - Automatically proceed to step 3\n\n4. Load and analyze the implementation context:\n   - **REQUIRED**: Read tasks.md for the complete task list and execution plan\n   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure — including the Component Architecture table, which fixes the Akka component for each domain concept\n   - **IF EXISTS**: Read data-model.md for entities and relationships\n   - **IF EXISTS**: Read contracts\u002F for API specifications and test requirements\n   - **IF EXISTS**: Read research.md for technical decisions and constraints\n   - **IF EXISTS**: Read quickstart.md for integration scenarios\n\n5. **Project Setup Verification**:\n   - **REQUIRED**: Create\u002Fverify ignore files based on actual project setup:\n\n   **Detection & Creation Logic**:\n   - Call `akka_git_status` to determine if the repository is a git repo (create\u002Fverify .gitignore if so)\n   - Check if Dockerfile* exists or Docker in plan.md → create\u002Fverify .dockerignore\n   - Check if .eslintrc* exists → create\u002Fverify .eslintignore\n   - Check if eslint.config.* exists → ensure the config's `ignores` entries cover required patterns\n   - Check if .prettierrc* exists → create\u002Fverify .prettierignore\n   - Check if .npmrc or package.json exists → create\u002Fverify .npmignore (if publishing)\n   - Check if terraform files (*.tf) exist → create\u002Fverify .terraformignore\n   - Check if .helmignore needed (helm charts present) → create\u002Fverify .helmignore\n\n   **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only\n   **If ignore file missing**: Create with full pattern set for detected technology\n\n   **Common Patterns by Technology** (from plan.md tech stack):\n   - **Node.js\u002FJavaScript\u002FTypeScript**: `node_modules\u002F`, `dist\u002F`, `build\u002F`, `*.log`, `.env*`\n   - **Python**: `__pycache__\u002F`, `*.pyc`, `.venv\u002F`, `venv\u002F`, `dist\u002F`, `*.egg-info\u002F`\n   - **Java**: `target\u002F`, `*.class`, `*.jar`, `.gradle\u002F`, `build\u002F`\n   - **C#\u002F.NET**: `bin\u002F`, `obj\u002F`, `*.user`, `*.suo`, `packages\u002F`\n   - **Go**: `*.exe`, `*.test`, `vendor\u002F`, `*.out`\n   - **Ruby**: `.bundle\u002F`, `log\u002F`, `tmp\u002F`, `*.gem`, `vendor\u002Fbundle\u002F`\n   - **PHP**: `vendor\u002F`, `*.log`, `*.cache`, `*.env`\n   - **Rust**: `target\u002F`, `debug\u002F`, `release\u002F`, `*.rs.bk`, `*.rlib`, `*.prof*`, `.idea\u002F`, `*.log`, `.env*`\n   - **Kotlin**: `build\u002F`, `out\u002F`, `.gradle\u002F`, `.idea\u002F`, `*.class`, `*.jar`, `*.iml`, `*.log`, `.env*`\n   - **C++**: `build\u002F`, `bin\u002F`, `obj\u002F`, `out\u002F`, `*.o`, `*.so`, `*.a`, `*.exe`, `*.dll`, `.idea\u002F`, `*.log`, `.env*`\n   - **C**: `build\u002F`, `bin\u002F`, `obj\u002F`, `out\u002F`, `*.o`, `*.a`, `*.so`, `*.exe`, `Makefile`, `config.log`, `.idea\u002F`, `*.log`, `.env*`\n   - **Swift**: `.build\u002F`, `DerivedData\u002F`, `*.swiftpm\u002F`, `Packages\u002F`\n   - **R**: `.Rproj.user\u002F`, `.Rhistory`, `.RData`, `.Ruserdata`, `*.Rproj`, `packrat\u002F`, `renv\u002F`\n   - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode\u002F`, `.idea\u002F`\n\n   **Tool-Specific Patterns**:\n   - **Docker**: `node_modules\u002F`, `.git\u002F`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage\u002F`\n   - **ESLint**: `node_modules\u002F`, `dist\u002F`, `build\u002F`, `coverage\u002F`, `*.min.js`\n   - **Prettier**: `node_modules\u002F`, `dist\u002F`, `build\u002F`, `coverage\u002F`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`\n   - **Terraform**: `.terraform\u002F`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl`\n   - **Kubernetes\u002Fk8s**: `*.secret.yaml`, `secrets\u002F`, `.kube\u002F`, `kubeconfig*`, `*.key`, `*.crt`\n\n6. Parse tasks.md structure and extract:\n   - **Task phases**: Setup, Tests, Core, Integration, Polish\n   - **Task dependencies**: Sequential vs parallel execution rules\n   - **Task details**: ID, description, file paths, parallel markers [P]\n   - **Execution flow**: Order and dependency requirements\n\n7. Execute implementation following the task plan:\n   - **Phase-by-phase execution**: Complete each phase before moving to the next\n   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together\n   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks\n   - **File-based coordination**: Tasks affecting the same files must run sequentially\n   - **Validation checkpoints**: Verify each phase completion before proceeding\n\n8. Implementation execution rules:\n   - **Component fidelity**: Implement components as mapped in plan.md's Component Architecture table. If a task needs a component not in the table, consult the \"Choosing a component type\" section of `akka-context\u002Fsdk\u002Fcomponents\u002Findex.html.md`, then record the addition (with the rejected alternative) in plan.md before coding\n   - **Setup first**: Initialize project structure, dependencies, configuration\n   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios\n   - **Core development**: Implement models, services, CLI commands, endpoints\n   - **Integration work**: Database connections, middleware, logging, external services\n   - **Polish and validation**: Unit tests, performance optimization, documentation\n\n9. Progress tracking and error handling:\n   - Report progress after each completed task\n   - Halt execution if any non-parallel task fails\n   - For parallel tasks [P], continue with successful tasks, report failed ones\n   - Provide clear error messages with context for debugging\n   - Suggest next steps if implementation cannot proceed\n   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.\n\n10. **Commit the implementation**:\n   - Call `akka_git_add` to stage all changes\n   - Call `akka_git_commit` with a descriptive message summarizing the implemented feature\n\n11. **Ask about merging to main**:\n   - Ask the user: \"Would you like to merge the feature branch back to main?\"\n   - If yes: call `akka_git_checkout` to switch to `main`, then `akka_git_merge` with the feature branch name\n   - If no: stay on the feature branch — the user may want to create a PR or continue iterating\n\n12. Completion validation:\n   - Verify all required tasks are completed\n   - Check that implemented features match the original specification\n   - Validate that tests pass and coverage meets requirements\n   - Confirm the implementation follows the technical plan\n   - Report final status with summary of completed work\n\nNote: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `\u002Fakka:tasks` first to regenerate the task list.\n\n## Done When\n\n- [ ] FEATURE_DIR and `tasks.md` were resolved via `akka_sdd_list_specs` with `has_tasks == true`.\n- [ ] The current git branch is the feature branch from spec.md (created via `akka_git_create_branch` if needed) — no implementation work happened on `main`.\n- [ ] The checklists status table was displayed; if any checklist had incomplete items, the user explicitly approved proceeding.\n- [ ] Every applicable ignore file (`.gitignore`, `.dockerignore`, `.eslintignore`\u002Feslint config, `.prettierignore`, `.npmignore`, `.terraformignore`, `.helmignore`) was created or verified with the correct patterns for the detected tech stack.\n- [ ] Tasks were executed phase-by-phase, respecting sequential dependencies and running `[P]` tasks in parallel where safe.\n- [ ] Every completed task in `tasks.md` was marked `[X]`; any failed task halted execution (or, for `[P]` tasks, was reported while continuing successful siblings).\n- [ ] All changes were staged via `akka_git_add` and committed via `akka_git_commit` with a descriptive message.\n- [ ] The user was asked whether to merge the feature branch to `main`; the answer was acted on (`akka_git_checkout` + `akka_git_merge` on yes, stay on feature branch on no).\n- [ ] The final report validates that implemented features match the spec, tests pass, and the implementation follows the plan.\n","## User Input\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Outline\n\n1. Call the `akka_sdd_list_specs` MCP tool to find features. Verify that tasks.md exists for the target feature (has_tasks must be true). If tasks.md is missing, instruct the user to run `\u002Fakka:tasks` first. Read the tasks.md content from FEATURE_DIR. Also note which other artifacts are available (AVAILABLE_DOCS).\n\n2. **Create or check out the feature branch**:\n   - Read the spec.md from FEATURE_DIR and find the **Feature Branch** field (e.g. `001-counter-service`)\n   - Call `akka_git_status` to check the current branch\n   - If not already on the feature branch, call `akka_git_create_branch` with the branch name from the spec\n   - All implementation work must happen on the feature branch, not on `main`\n\n3. **Check checklists status** (if FEATURE_DIR\u002Fchecklists\u002F exists):\n   - Scan all checklist files in the checklists\u002F directory\n   - For each checklist, count:\n     - Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`\n     - Completed items: Lines matching `- [X]` or `- [x]`\n     - Incomplete items: Lines matching `- [ ]`\n   - Create a status table:\n\n     ```text\n     | Checklist | Total | Completed | Incomplete | Status |\n     |-----------|-------|-----------|------------|--------|\n     | ux.md     | 12    | 12        | 0          | ✓ PASS |\n     | test.md   | 8     | 5         | 3          | ✗ FAIL |\n     | security.md | 6   | 6         | 0          | ✓ PASS |\n     ```\n\n   - Calculate overall status:\n     - **PASS**: All checklists have 0 incomplete items\n     - **FAIL**: One or more checklists have incomplete items\n\n   - **If any checklist is incomplete**:\n     - Display the table with incomplete item counts\n     - **STOP** and ask: \"Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes\u002Fno)\"\n     - Wait for user response before continuing\n     - If user says \"no\" or \"wait\" or \"stop\", halt execution\n     - If user says \"yes\" or \"proceed\" or \"continue\", proceed to step 3\n\n   - **If all checklists are complete**:\n     - Display the table showing all checklists passed\n     - Automatically proceed to step 3\n\n4. Load and analyze the implementation context:\n   - **REQUIRED**: Read tasks.md for the complete task list and execution plan\n   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure — including the Component Architecture table, which fixes the Akka component for each domain concept\n   - **IF EXISTS**: Read data-model.md for entities and relationships\n   - **IF EXISTS**: Read contracts\u002F for API specifications and test requirements\n   - **IF EXISTS**: Read research.md for technical decisions and constraints\n   - **IF EXISTS**: Read quickstart.md for integration scenarios\n\n5. **Project Setup Verification**:\n   - **REQUIRED**: Create\u002Fverify ignore files based on actual project setup:\n\n   **Detection & Creation Logic**:\n   - Call `akka_git_status` to determine if the repository is a git repo (create\u002Fverify .gitignore if so)\n   - Check if Dockerfile* exists or Docker in plan.md → create\u002Fverify .dockerignore\n   - Check if .eslintrc* exists → create\u002Fverify .eslintignore\n   - Check if eslint.config.* exists → ensure the config's `ignores` entries cover required patterns\n   - Check if .prettierrc* exists → create\u002Fverify .prettierignore\n   - Check if .npmrc or package.json exists → create\u002Fverify .npmignore (if publishing)\n   - Check if terraform files (*.tf) exist → create\u002Fverify .terraformignore\n   - Check if .helmignore needed (helm charts present) → create\u002Fverify .helmignore\n\n   **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only\n   **If ignore file missing**: Create with full pattern set for detected technology\n\n   **Common Patterns by Technology** (from plan.md tech stack):\n   - **Node.js\u002FJavaScript\u002FTypeScript**: `node_modules\u002F`, `dist\u002F`, `build\u002F`, `*.log`, `.env*`\n   - **Python**: `__pycache__\u002F`, `*.pyc`, `.venv\u002F`, `venv\u002F`, `dist\u002F`, `*.egg-info\u002F`\n   - **Java**: `target\u002F`, `*.class`, `*.jar`, `.gradle\u002F`, `build\u002F`\n   - **C#\u002F.NET**: `bin\u002F`, `obj\u002F`, `*.user`, `*.suo`, `packages\u002F`\n   - **Go**: `*.exe`, `*.test`, `vendor\u002F`, `*.out`\n   - **Ruby**: `.bundle\u002F`, `log\u002F`, `tmp\u002F`, `*.gem`, `vendor\u002Fbundle\u002F`\n   - **PHP**: `vendor\u002F`, `*.log`, `*.cache`, `*.env`\n   - **Rust**: `target\u002F`, `debug\u002F`, `release\u002F`, `*.rs.bk`, `*.rlib`, `*.prof*`, `.idea\u002F`, `*.log`, `.env*`\n   - **Kotlin**: `build\u002F`, `out\u002F`, `.gradle\u002F`, `.idea\u002F`, `*.class`, `*.jar`, `*.iml`, `*.log`, `.env*`\n   - **C++**: `build\u002F`, `bin\u002F`, `obj\u002F`, `out\u002F`, `*.o`, `*.so`, `*.a`, `*.exe`, `*.dll`, `.idea\u002F`, `*.log`, `.env*`\n   - **C**: `build\u002F`, `bin\u002F`, `obj\u002F`, `out\u002F`, `*.o`, `*.a`, `*.so`, `*.exe`, `Makefile`, `config.log`, `.idea\u002F`, `*.log`, `.env*`\n   - **Swift**: `.build\u002F`, `DerivedData\u002F`, `*.swiftpm\u002F`, `Packages\u002F`\n   - **R**: `.Rproj.user\u002F`, `.Rhistory`, `.RData`, `.Ruserdata`, `*.Rproj`, `packrat\u002F`, `renv\u002F`\n   - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode\u002F`, `.idea\u002F`\n\n   **Tool-Specific Patterns**:\n   - **Docker**: `node_modules\u002F`, `.git\u002F`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage\u002F`\n   - **ESLint**: `node_modules\u002F`, `dist\u002F`, `build\u002F`, `coverage\u002F`, `*.min.js`\n   - **Prettier**: `node_modules\u002F`, `dist\u002F`, `build\u002F`, `coverage\u002F`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`\n   - **Terraform**: `.terraform\u002F`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl`\n   - **Kubernetes\u002Fk8s**: `*.secret.yaml`, `secrets\u002F`, `.kube\u002F`, `kubeconfig*`, `*.key`, `*.crt`\n\n6. Parse tasks.md structure and extract:\n   - **Task phases**: Setup, Tests, Core, Integration, Polish\n   - **Task dependencies**: Sequential vs parallel execution rules\n   - **Task details**: ID, description, file paths, parallel markers [P]\n   - **Execution flow**: Order and dependency requirements\n\n7. Execute implementation following the task plan:\n   - **Phase-by-phase execution**: Complete each phase before moving to the next\n   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together\n   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks\n   - **File-based coordination**: Tasks affecting the same files must run sequentially\n   - **Validation checkpoints**: Verify each phase completion before proceeding\n\n8. Implementation execution rules:\n   - **Component fidelity**: Implement components as mapped in plan.md's Component Architecture table. If a task needs a component not in the table, consult the \"Choosing a component type\" section of `akka-context\u002Fsdk\u002Fcomponents\u002Findex.html.md`, then record the addition (with the rejected alternative) in plan.md before coding\n   - **Setup first**: Initialize project structure, dependencies, configuration\n   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios\n   - **Core development**: Implement models, services, CLI commands, endpoints\n   - **Integration work**: Database connections, middleware, logging, external services\n   - **Polish and validation**: Unit tests, performance optimization, documentation\n\n9. Progress tracking and error handling:\n   - Report progress after each completed task\n   - Halt execution if any non-parallel task fails\n   - For parallel tasks [P], continue with successful tasks, report failed ones\n   - Provide clear error messages with context for debugging\n   - Suggest next steps if implementation cannot proceed\n   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.\n\n10. **Commit the implementation**:\n   - Call `akka_git_add` to stage all changes\n   - Call `akka_git_commit` with a descriptive message summarizing the implemented feature\n\n11. **Ask about merging to main**:\n   - Ask the user: \"Would you like to merge the feature branch back to main?\"\n   - If yes: call `akka_git_checkout` to switch to `main`, then `akka_git_merge` with the feature branch name\n   - If no: stay on the feature branch — the user may want to create a PR or continue iterating\n\n12. Completion validation:\n   - Verify all required tasks are completed\n   - Check that implemented features match the original specification\n   - Validate that tests pass and coverage meets requirements\n   - Confirm the implementation follows the technical plan\n   - Report final status with summary of completed work\n\nNote: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `\u002Fakka:tasks` first to regenerate the task list.\n\n## Done When\n\n- [ ] FEATURE_DIR and `tasks.md` were resolved via `akka_sdd_list_specs` with `has_tasks == true`.\n- [ ] The current git branch is the feature branch from spec.md (created via `akka_git_create_branch` if needed) — no implementation work happened on `main`.\n- [ ] The checklists status table was displayed; if any checklist had incomplete items, the user explicitly approved proceeding.\n- [ ] Every applicable ignore file (`.gitignore`, `.dockerignore`, `.eslintignore`\u002Feslint config, `.prettierignore`, `.npmignore`, `.terraformignore`, `.helmignore`) was created or verified with the correct patterns for the detected tech stack.\n- [ ] Tasks were executed phase-by-phase, respecting sequential dependencies and running `[P]` tasks in parallel where safe.\n- [ ] Every completed task in `tasks.md` was marked `[X]`; any failed task halted execution (or, for `[P]` tasks, was reported while continuing successful siblings).\n- [ ] All changes were staged via `akka_git_add` and committed via `akka_git_commit` with a descriptive message.\n- [ ] The user was asked whether to merge the feature branch to `main`; the answer was acted on (`akka_git_checkout` + `akka_git_merge` on yes, stay on feature branch on no).\n- [ ] The final report validates that implemented features match the spec, tests pass, and the implementation follows the plan.\n",{"name":5,"description":7},"main","dbb719c3f52584296af0d92beed03251cd2f3371","skills\u002Fimplement",3,"https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace","https:\u002F\u002Fdoc.akka.io","https:\u002F\u002Fgithub.com\u002Fakka","https:\u002F\u002Fakka.io","2026-11-11 17:37:20",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add akka\u002Fai-marketplace --skill implement",{"tool":45,"command":46},"bunx","bunx skills add akka\u002Fai-marketplace --skill implement",{"tool":48,"command":49},"pnpm","pnpm dlx skills add akka\u002Fai-marketplace --skill implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fimplement\u002FSKILL.md",true,[],[54,70,80,104,117,129],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":25},"01M70VC27E4BQ8YW5M19R43XB5","visualize","Generate Mermaid diagrams for a feature from its spec.md (requirement-level views) and plan.md (technical component diagrams).","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvisualize\u002FSKILL.md",[],[56,61,62,63,64,65,20,66,67,68,69],"diagrams","spec","mermaid","generate","component","mermaid diagrams","technical","for","feature",{"skillNo":71,"name":19,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":25},"01M6GKNPW7D72HYT0NQ095QFT4","Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002FSKILL.md",[],[19,68,76,64,77,78,79,69],"dependency","artifacts","design","actionable",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":25},"01M6GKNJJV6509SZXKB0Z02FC2","status","Show a read-only rollup of the definition of done — every exit condition with its state, properties, and open reason — without running any auditor.","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fstatus\u002FSKILL.md",[],[82,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],"with","definition","reason","condition","running","rollup","read","properties","state","read-only","done","only","show","open","exit","definition of done","auditor",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":25},"01M6GKNE1WXE2X3TVH9EYKFPKX","specify","Create or update the feature specification from a natural language feature description.","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fspecify\u002FSKILL.md",[],[106,111,112,113,114,69,115,116],"update","feature specification","create","specification","natural language","language",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":25},"01M6GKN943T6RYZYHTBQ3M9NG0","ship","Run the auditors for every exit condition in scope for the requested ship target (review or release), and on pass run the ship steps the organization declared for that target.","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fship\u002FSKILL.md",[],[119,124,68,125,101,126,127,128,90],"release","review","run","organization","scope",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":25},"01M6GKN1TQR2ZKRF40YKGQ3MS7","setup","Set up a complete Akka SDK development environment from scratch. Installs Java, Maven, Akka CLI, configures tokens, scaffolds a project, and downloads context documentation. Idempotent — safe to rerun for repair\u002Fupgrade.","https:\u002F\u002Fgithub.com\u002Fakka\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fsetup\u002FSKILL.md",[],[131,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,68,154,155,156],"development environment","java","tokens","complete","environment","development","maven","downloads","repair","From Scratch","context","safe","cli","documentation","upgrade","up","project","SET","rerun","idempotent","scaffolds"]