[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P4J1CJPEECP55AFBMQKY8F":3,"skill-same:01M6P4J1CJPEECP55AFBMQKY8F":66},{"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":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6P4J1CJPEECP55AFBMQKY8F","tech-lead",null,"Analyze a project, turn the user's goal into an implementation-ready GitHub Epic and Issues (following project rules, the Command Bus architecture and Fragiola UI), then start epic-implementer automatically (use the no-implement flag to stop after planning).","maurodesouza\u002Fai-kanban-app-lab","maurodesouza","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54520907?v=4","01M6P3VA3WVQC4XZ0RQWJCDKW6","Mauro de Souza","01M6P3VA7YK770SNWT12GBEGAF",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.agents\u002Fskills\u002Ftech-lead\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"tech lead","tech","implementer","command bus architecture","EPIC","project","stop","goal","ready","use","github","command","Rules","analyze","start","ui","issues","planning","architecture","implement","2026-11-10 10:12:30",false,"---\nname: tech-lead\ndescription: Analyze a project, turn the user's goal into an implementation-ready GitHub Epic and Issues (following project rules, the Command Bus architecture and Fragiola UI), then start epic-implementer automatically (use the no-implement flag to stop after planning).\n---\n\n# User Input\n\n```text\n$ARGUMENTS\n```\n\nYou MUST consider the user input before proceeding.\n\n# Flags\n\n* `no-implement` (also accepted: `--no-implement`, `no implement`, `auto false`, `auto=false`): plan and publish the Epic and Issues, but do not start `epic-implementer`.\n* `no-merge` (also accepted: `--no-merge`, `no merge`): passed through to `epic-implementer`, which then verifies the gates but does not merge.\n\nWithout `no-implement`, `epic-implementer` starts automatically after the Epic is published.\n\nFlags are execution options, not part of the request: do not plan around them.\n\n# Objective\n\nAct as a Senior Technical Lead responsible for project evolution, architecture, technical debt reduction, and implementation planning.\n\nThis skill plans; it does not edit code itself. After publishing, it hands the Epic to `epic-implementer` and keeps running until the implementation finishes (see Start Implementation). Handing off to `epic-implementer` is part of this skill's job, not a violation of it.\n\nYour responsibility is to transform the user's goal into a cohesive, executable Epic that can be implemented autonomously by an Epic Implementer.\n\nThe Epic is the primary unit of execution.\n\nIssues are planning and tracking units inside the Epic, not human approval checkpoints.\n\n# How This Skill Works\n\nThis skill does the analysis and planning itself, because scope, work items, dependencies and delivery are one connected decision.\n\nRepository context, architecture and publishing are delegated to micro-skills shared with `epic-implementer`, so both see the project the same way.\n\n| Step | Micro-skill |\n| --- | --- |\n| Clarify the request | `clarify-first` |\n| Discover the repository | `epic-discover-repository` |\n| Repository rules | `epic-repository-rules` |\n| Current documentation | `epic-current-documentation` |\n| Architecture | `command-bus-architecture` |\n| User interface | `fragiola-ui` |\n| Dependency order | `epic-handle-dependent-work` |\n| Publish to GitHub | `tech-lead-publish` |\n| Implement the Epic | `epic-implementer` (default; skipped with `no-implement`) |\n\n# Clarify the Request\n\nCall `clarify-first` with the user request.\n\nPlan only after every real ambiguity is resolved.\n\n# Context Discovery\n\n1. Call `epic-discover-repository`.\n2. Call `epic-repository-rules`.\n3. Read architecture documentation, roadmap documents, ADRs and issue templates (`docs\u002F`, `architecture\u002F`, `.github\u002F`).\n\nIf multiple instruction sources exist, merge them into a single project context.\n\n# Current Tool Documentation\n\nCall `epic-current-documentation` for every external tool, library, framework, SDK, API or dependency the plan uses, installs, upgrades or integrates.\n\n# Architecture\n\nEvery plan must follow:\n\n* `command-bus-architecture` - every interaction is a Command Bus (V2) action, all state and `$` derived values live in MobX stores, all execution logic lives in Handles, components only read and present.\n* `fragiola-ui` - every interface is built with Fragiola UI.\n\nRead both before planning. A plan that puts logic in components or stores, derived values outside stores, or UI outside Fragiola is wrong.\n\nWhen the project does not have the Command Bus, MobX or Fragiola set up yet, the first Issue of the Epic sets them up.\n\n# Analysis Phase\n\nAnalyze:\n\n* Current architecture\n* Relevant existing functionality\n* Technical debt\n* Coupling issues\n* Layer violations\n* Circular dependencies\n* Dead code\n* Naming inconsistencies\n* Folder organization\n* Test quality\n* Maintainability concerns\n* Existing patterns that should be reused\n\nEvaluate the user's request against the existing project.\n\nPrefer extending existing architecture and conventions over introducing new patterns.\n\n# Planning Principles\n\nPlan for delivery, not for maximum issue count.\n\nCreate the minimum number of cohesive work items necessary to safely implement the requested outcome.\n\nDo NOT split work merely because it can be split.\n\nAvoid extremely small tasks such as:\n\n* Creating a single enum\n* Creating a single function\n* Renaming a file\n* Making an isolated trivial change\n* Creating tests that only exist as a separate task when they naturally belong to the implementation\n\nPrefer cohesive work items that produce a meaningful functional or architectural outcome.\n\nA work item may include:\n\n* Implementation\n* Tests\n* Refactoring required by the implementation\n* Documentation required by the implementation\n* Related validation\n\nDo not optimize work items around estimated hours.\n\nOptimize them around:\n\n* Cohesion\n* Dependencies\n* Risk\n* Testability\n* Architectural boundaries\n* Meaningful outcomes\n\n# Epic Structure\n\nWhen the request represents a meaningful feature, improvement, migration, or architectural change, create an Epic.\n\nThe Epic is the contract read by `epic-read`. Always use exactly this structure and these headings.\n\n## Epic body\n\n```markdown\n## Objective\n\nWhat the user ultimately wants to achieve.\n\n## Scope\n\nWhat is included.\n\n## Out of Scope\n\nWhat is intentionally excluded.\n\n## Architectural Context\n\nRelevant existing architecture, the domains\u002Ffeatures touched and how `command-bus-architecture` and `fragiola-ui` apply.\n\n## Acceptance Criteria\n\n- [ ] Concrete, verifiable conditions that define success.\n\n## Risks\n\nImportant technical or architectural risks.\n\n## Work Items\n\n- [ ] #\u003Cissue> \u003Ctitle>\n\n## Dependencies and Execution Order\n\n1. #\u003Cissue> - depends on: none\n2. #\u003Cissue> - depends on: #\u003Cissue>\n\n## Delivery Strategy\n\nSingle PR. Related Epics and dependencies (`Depends on Epic #\u003Cn>`), when the work was split.\n\n## Definition of Done\n\n- [ ] ...\n\n## Stop Conditions\n\nSituations that require human intervention for this Epic.\n```\n\n## Issue body\n\nCreate cohesive implementation Issues only where useful.\n\nIssues should represent meaningful units of work, not arbitrary slices of implementation.\n\n```markdown\n## Outcome\n\nWhat exists when this Issue is done.\n\n## Scope\n\nWhat is included and what is not.\n\n## Acceptance Criteria\n\n- [ ] Concrete, verifiable conditions.\n\n## Dependencies\n\n#\u003Cissue>, or none.\n\n## Implementation Context\n\nRelevant files, existing patterns to reuse, constraints.\n\n## Architecture Map\n\n- Actions: `\u003Cdomain>.\u003Cverb>` (`Action` | `ScopedAction`) in `\u003Cdomain>-actions.ts`\n- Handles: `\u003Cdomain>-handle.tsx` - what each handler does\n- Stores: `store\u002Fstore.ts` - primitives, setters and `$` derived values (one `$\u003Cpart>UI` per component)\n- Components: what each one presents and which actions it dispatches\n- Fragiola UI: components used\n- Tests: what must be covered\n```\n\nOmit Architecture Map lines that do not apply (e.g. no UI). Never omit the section for an Issue that changes application code.\n\n# Dependency Analysis\n\nCall `epic-handle-dependent-work` with the work items and their dependencies.\n\nUse its order for the Epic's \"Dependencies and Execution Order\".\n\nDo not create artificial dependencies.\n\n# Delivery Strategy\n\n**One Epic = one pull request.** `epic-implementer` delivers each Epic as a single PR.\n\nWhen the work cannot be safely delivered in one PR, split it into multiple Epics instead, for example when there are:\n\n* Independent deployment boundaries\n* High-risk migrations\n* Clearly independent components\n* Repository or CI constraints\n\nEach Epic must be cohesive and deliverable on its own.\n\nWhen splitting:\n\n1. Define the order between Epics and the reason for the split.\n2. An Epic that depends on another declares it in \"Delivery Strategy\" (`Depends on Epic #\u003Cn>`).\n3. A dependent Epic is only executed after the Epic it depends on is merged.\n\nDo not split an Epic merely to make PRs smaller.\n\n# Definition of Done\n\nEvery Epic must define a clear Definition of Done.\n\nAt minimum consider:\n\n* Implementation complete\n* Acceptance criteria satisfied\n* Relevant tests passing\n* Lint passing\n* Type checking passing when applicable\n* Build passing when applicable\n* No unresolved critical issues\n* Architecture conventions respected\n* Final validation completed\n\n# Human Approval\n\nThe Epic Implementer should be able to execute all work items without waiting for human approval between Issues.\n\nHuman intervention should only be required when:\n\n* Requirements are ambiguous.\n* Scope must materially change.\n* A significant architectural decision is required.\n* A destructive or risky migration is required.\n* Security boundaries must change.\n* A new external dependency or service is required (the Command Bus, MobX and Fragiola UI are pre-approved).\n* Infrastructure changes are significant.\n* Data loss is possible.\n* The implementation repeatedly fails validation.\n* The implementation conflicts with the Epic's objectives.\n\nOtherwise, the Epic Implementer should continue autonomously.\n\n# GitHub Integration\n\nWhen the plan is final, call `tech-lead-publish` with the Epic and Issues. Publishing is not the end of this skill: continue to Start Implementation.\n\n# Start Implementation\n\nSkip this section when `no-implement` is set.\n\nOtherwise, once `tech-lead-publish` returns `PUBLISHED`:\n\n1. Call `epic-implementer` with the published Epic, forwarding `no-merge` when it was given.\n2. With more than one Epic, implement them one at a time in the published execution order.\n3. Start a dependent Epic only after the Epic it depends on returns `MERGED`. If it ends as `READY_TO_MERGE` (`no-merge`), `WAITING_FOR_HUMAN` or `BLOCKED`, do not start the Epics that depend on it; independent Epics may still run.\n\nIf `tech-lead-publish` returns `BLOCKED`, do not start the implementation; report what is missing.\n\nDo not ask for confirmation before starting: the automatic start is the default.\n\n# Output\n\nProduce:\n\n1. Architectural analysis.\n2. Technical debt and relevant repository findings.\n3. Epic definition.\n4. Cohesive implementation Issues, each with its Architecture Map.\n5. Dependencies and execution order.\n6. Delivery strategy (and the Epic split with its order, when there is more than one Epic).\n7. Definition of Done.\n8. Human intervention \u002F stop conditions.\n9. Epic and Issue URLs (from `tech-lead-publish`).\n10. Implementation result of each Epic (from `epic-implementer`), or `NOT_STARTED (no-implement)`.\n\nDo not edit code directly in this skill; code changes happen through `epic-implementer`.\n\nDo NOT create unnecessary Issues.\n\nDo NOT stop planning merely to make Issues smaller.\n\nThe goal is to produce an Epic that an autonomous Epic Implementer can execute from start to finish with minimal human intervention.\n\nStop after `epic-implementer` finishes every Epic that can run, or after backlog generation when `no-implement` is set.\n\n","# User Input\n\n```text\n$ARGUMENTS\n```\n\nYou MUST consider the user input before proceeding.\n\n# Flags\n\n* `no-implement` (also accepted: `--no-implement`, `no implement`, `auto false`, `auto=false`): plan and publish the Epic and Issues, but do not start `epic-implementer`.\n* `no-merge` (also accepted: `--no-merge`, `no merge`): passed through to `epic-implementer`, which then verifies the gates but does not merge.\n\nWithout `no-implement`, `epic-implementer` starts automatically after the Epic is published.\n\nFlags are execution options, not part of the request: do not plan around them.\n\n# Objective\n\nAct as a Senior Technical Lead responsible for project evolution, architecture, technical debt reduction, and implementation planning.\n\nThis skill plans; it does not edit code itself. After publishing, it hands the Epic to `epic-implementer` and keeps running until the implementation finishes (see Start Implementation). Handing off to `epic-implementer` is part of this skill's job, not a violation of it.\n\nYour responsibility is to transform the user's goal into a cohesive, executable Epic that can be implemented autonomously by an Epic Implementer.\n\nThe Epic is the primary unit of execution.\n\nIssues are planning and tracking units inside the Epic, not human approval checkpoints.\n\n# How This Skill Works\n\nThis skill does the analysis and planning itself, because scope, work items, dependencies and delivery are one connected decision.\n\nRepository context, architecture and publishing are delegated to micro-skills shared with `epic-implementer`, so both see the project the same way.\n\n| Step | Micro-skill |\n| --- | --- |\n| Clarify the request | `clarify-first` |\n| Discover the repository | `epic-discover-repository` |\n| Repository rules | `epic-repository-rules` |\n| Current documentation | `epic-current-documentation` |\n| Architecture | `command-bus-architecture` |\n| User interface | `fragiola-ui` |\n| Dependency order | `epic-handle-dependent-work` |\n| Publish to GitHub | `tech-lead-publish` |\n| Implement the Epic | `epic-implementer` (default; skipped with `no-implement`) |\n\n# Clarify the Request\n\nCall `clarify-first` with the user request.\n\nPlan only after every real ambiguity is resolved.\n\n# Context Discovery\n\n1. Call `epic-discover-repository`.\n2. Call `epic-repository-rules`.\n3. Read architecture documentation, roadmap documents, ADRs and issue templates (`docs\u002F`, `architecture\u002F`, `.github\u002F`).\n\nIf multiple instruction sources exist, merge them into a single project context.\n\n# Current Tool Documentation\n\nCall `epic-current-documentation` for every external tool, library, framework, SDK, API or dependency the plan uses, installs, upgrades or integrates.\n\n# Architecture\n\nEvery plan must follow:\n\n* `command-bus-architecture` - every interaction is a Command Bus (V2) action, all state and `$` derived values live in MobX stores, all execution logic lives in Handles, components only read and present.\n* `fragiola-ui` - every interface is built with Fragiola UI.\n\nRead both before planning. A plan that puts logic in components or stores, derived values outside stores, or UI outside Fragiola is wrong.\n\nWhen the project does not have the Command Bus, MobX or Fragiola set up yet, the first Issue of the Epic sets them up.\n\n# Analysis Phase\n\nAnalyze:\n\n* Current architecture\n* Relevant existing functionality\n* Technical debt\n* Coupling issues\n* Layer violations\n* Circular dependencies\n* Dead code\n* Naming inconsistencies\n* Folder organization\n* Test quality\n* Maintainability concerns\n* Existing patterns that should be reused\n\nEvaluate the user's request against the existing project.\n\nPrefer extending existing architecture and conventions over introducing new patterns.\n\n# Planning Principles\n\nPlan for delivery, not for maximum issue count.\n\nCreate the minimum number of cohesive work items necessary to safely implement the requested outcome.\n\nDo NOT split work merely because it can be split.\n\nAvoid extremely small tasks such as:\n\n* Creating a single enum\n* Creating a single function\n* Renaming a file\n* Making an isolated trivial change\n* Creating tests that only exist as a separate task when they naturally belong to the implementation\n\nPrefer cohesive work items that produce a meaningful functional or architectural outcome.\n\nA work item may include:\n\n* Implementation\n* Tests\n* Refactoring required by the implementation\n* Documentation required by the implementation\n* Related validation\n\nDo not optimize work items around estimated hours.\n\nOptimize them around:\n\n* Cohesion\n* Dependencies\n* Risk\n* Testability\n* Architectural boundaries\n* Meaningful outcomes\n\n# Epic Structure\n\nWhen the request represents a meaningful feature, improvement, migration, or architectural change, create an Epic.\n\nThe Epic is the contract read by `epic-read`. Always use exactly this structure and these headings.\n\n## Epic body\n\n```markdown\n## Objective\n\nWhat the user ultimately wants to achieve.\n\n## Scope\n\nWhat is included.\n\n## Out of Scope\n\nWhat is intentionally excluded.\n\n## Architectural Context\n\nRelevant existing architecture, the domains\u002Ffeatures touched and how `command-bus-architecture` and `fragiola-ui` apply.\n\n## Acceptance Criteria\n\n- [ ] Concrete, verifiable conditions that define success.\n\n## Risks\n\nImportant technical or architectural risks.\n\n## Work Items\n\n- [ ] #\u003Cissue> \u003Ctitle>\n\n## Dependencies and Execution Order\n\n1. #\u003Cissue> - depends on: none\n2. #\u003Cissue> - depends on: #\u003Cissue>\n\n## Delivery Strategy\n\nSingle PR. Related Epics and dependencies (`Depends on Epic #\u003Cn>`), when the work was split.\n\n## Definition of Done\n\n- [ ] ...\n\n## Stop Conditions\n\nSituations that require human intervention for this Epic.\n```\n\n## Issue body\n\nCreate cohesive implementation Issues only where useful.\n\nIssues should represent meaningful units of work, not arbitrary slices of implementation.\n\n```markdown\n## Outcome\n\nWhat exists when this Issue is done.\n\n## Scope\n\nWhat is included and what is not.\n\n## Acceptance Criteria\n\n- [ ] Concrete, verifiable conditions.\n\n## Dependencies\n\n#\u003Cissue>, or none.\n\n## Implementation Context\n\nRelevant files, existing patterns to reuse, constraints.\n\n## Architecture Map\n\n- Actions: `\u003Cdomain>.\u003Cverb>` (`Action` | `ScopedAction`) in `\u003Cdomain>-actions.ts`\n- Handles: `\u003Cdomain>-handle.tsx` - what each handler does\n- Stores: `store\u002Fstore.ts` - primitives, setters and `$` derived values (one `$\u003Cpart>UI` per component)\n- Components: what each one presents and which actions it dispatches\n- Fragiola UI: components used\n- Tests: what must be covered\n```\n\nOmit Architecture Map lines that do not apply (e.g. no UI). Never omit the section for an Issue that changes application code.\n\n# Dependency Analysis\n\nCall `epic-handle-dependent-work` with the work items and their dependencies.\n\nUse its order for the Epic's \"Dependencies and Execution Order\".\n\nDo not create artificial dependencies.\n\n# Delivery Strategy\n\n**One Epic = one pull request.** `epic-implementer` delivers each Epic as a single PR.\n\nWhen the work cannot be safely delivered in one PR, split it into multiple Epics instead, for example when there are:\n\n* Independent deployment boundaries\n* High-risk migrations\n* Clearly independent components\n* Repository or CI constraints\n\nEach Epic must be cohesive and deliverable on its own.\n\nWhen splitting:\n\n1. Define the order between Epics and the reason for the split.\n2. An Epic that depends on another declares it in \"Delivery Strategy\" (`Depends on Epic #\u003Cn>`).\n3. A dependent Epic is only executed after the Epic it depends on is merged.\n\nDo not split an Epic merely to make PRs smaller.\n\n# Definition of Done\n\nEvery Epic must define a clear Definition of Done.\n\nAt minimum consider:\n\n* Implementation complete\n* Acceptance criteria satisfied\n* Relevant tests passing\n* Lint passing\n* Type checking passing when applicable\n* Build passing when applicable\n* No unresolved critical issues\n* Architecture conventions respected\n* Final validation completed\n\n# Human Approval\n\nThe Epic Implementer should be able to execute all work items without waiting for human approval between Issues.\n\nHuman intervention should only be required when:\n\n* Requirements are ambiguous.\n* Scope must materially change.\n* A significant architectural decision is required.\n* A destructive or risky migration is required.\n* Security boundaries must change.\n* A new external dependency or service is required (the Command Bus, MobX and Fragiola UI are pre-approved).\n* Infrastructure changes are significant.\n* Data loss is possible.\n* The implementation repeatedly fails validation.\n* The implementation conflicts with the Epic's objectives.\n\nOtherwise, the Epic Implementer should continue autonomously.\n\n# GitHub Integration\n\nWhen the plan is final, call `tech-lead-publish` with the Epic and Issues. Publishing is not the end of this skill: continue to Start Implementation.\n\n# Start Implementation\n\nSkip this section when `no-implement` is set.\n\nOtherwise, once `tech-lead-publish` returns `PUBLISHED`:\n\n1. Call `epic-implementer` with the published Epic, forwarding `no-merge` when it was given.\n2. With more than one Epic, implement them one at a time in the published execution order.\n3. Start a dependent Epic only after the Epic it depends on returns `MERGED`. If it ends as `READY_TO_MERGE` (`no-merge`), `WAITING_FOR_HUMAN` or `BLOCKED`, do not start the Epics that depend on it; independent Epics may still run.\n\nIf `tech-lead-publish` returns `BLOCKED`, do not start the implementation; report what is missing.\n\nDo not ask for confirmation before starting: the automatic start is the default.\n\n# Output\n\nProduce:\n\n1. Architectural analysis.\n2. Technical debt and relevant repository findings.\n3. Epic definition.\n4. Cohesive implementation Issues, each with its Architecture Map.\n5. Dependencies and execution order.\n6. Delivery strategy (and the Epic split with its order, when there is more than one Epic).\n7. Definition of Done.\n8. Human intervention \u002F stop conditions.\n9. Epic and Issue URLs (from `tech-lead-publish`).\n10. Implementation result of each Epic (from `epic-implementer`), or `NOT_STARTED (no-implement)`.\n\nDo not edit code directly in this skill; code changes happen through `epic-implementer`.\n\nDo NOT create unnecessary Issues.\n\nDo NOT stop planning merely to make Issues smaller.\n\nThe goal is to produce an Epic that an autonomous Epic Implementer can execute from start to finish with minimal human intervention.\n\nStop after `epic-implementer` finishes every Epic that can run, or after backlog generation when `no-implement` is set.\n\n",{"name":5,"description":7},"main","6f1867f215cf86d20099b6dfb1164c79abfb87ce","lab-10\u002F.agents\u002Fskills\u002Ftech-lead",0,"https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab","https:\u002F\u002Fgithub.com\u002Fmaurodesouza","Software Engineer","2026-10-28 02:01:00",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add maurodesouza\u002Fai-kanban-app-lab --skill tech-lead",{"tool":58,"command":59},"bunx","bunx skills add maurodesouza\u002Fai-kanban-app-lab --skill tech-lead",{"tool":61,"command":62},"pnpm","pnpm dlx skills add maurodesouza\u002Fai-kanban-app-lab --skill tech-lead","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.agents\u002Fskills\u002Ftech-lead\u002FSKILL.md",true,[],[67,92,109,114,126,137],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":39},"01M6P519M13JTBZDK3ZJP48P2C","utils-implementation","Write and organize utils (pure helpers for formatting, mapping, filtering, math, parsing, ids, storage) as one namespace object per domain with clear, readable names. Use before creating or changing any util.","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.codex\u002Fskills\u002Futils-implementation\u002FSKILL.md",[],[74,75,76,77,78,79,80,81,82,83,84,85,86,28,87,88,89,90,91],"utils implementation","implementation","utils","parsing","for","object","storage","ids","clear","math","write","filtering","with","organize","domain","mapping","formatting","as",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":39},"01M6P516BP8GPRJHPGVFWRF5T8","test-writer","Write tests for the current implementation","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.codex\u002Fskills\u002Ftest-writer\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[104,105,106,107,84,75,108,78],"test","test writer","writer","write tests","tests",{"skillNo":110,"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":111,"categories":112,"keywords":113,"publishedAt":39},"01M6P50M0Z2AQH32ZTV90D5V32","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.codex\u002Fskills\u002Ftech-lead\u002FSKILL.md",[],[20,19,27,22,38,29,23,37,36,35,34,33,32,31,30,21,28,26,25,24],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":39},"01M6P50GND99S9QQY6KWPP6NW9","tech-lead-publish","Publish a final Epic and its Issues to GitHub, linked and labeled, keeping dependency and execution information. Sub-skill of tech-lead.","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.codex\u002Fskills\u002Ftech-lead-publish\u002FSKILL.md",[],[121,19,20,122,29,35,123,124,23,125],"tech lead publish","publish","execution","dependency","information",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":39},"01M6P50D4P2SQSYZM7TZMHZA0J","setup-command-system","Install the Command System architecture in the project","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.codex\u002Fskills\u002Fsetup-command-system\u002FSKILL.md",[],[133,30,134,135,37,136,24],"setup command system","system","setup","install",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":39},"01M6P50A032630X9JDDZYJMNV3","reviewer","Review code changes and provide feedback","https:\u002F\u002Fgithub.com\u002Fmaurodesouza\u002Fai-kanban-app-lab\u002Fblob\u002Fmain\u002Flab-10\u002F.codex\u002Fskills\u002Freviewer\u002FSKILL.md",[],[139,144,145,146,147,148],"code","review code","feedback","changes","review"]