[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CZPSAXG1VSYAPCV3M26DYG":3,"skill-same:01M6CZPSAXG1VSYAPCV3M26DYG":63},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M6CZPSAXG1VSYAPCV3M26DYG","kiro-review",null,"Review a task implementation against approved specs, task boundaries, and verification evidence. Use after an implementer finishes a task, after remediation, or before accepting a task as complete.","j5ik2o\u002Fai-tools","j5ik2o","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F461711?v=4","01M6CR6HZJM242J0HDRJT5GY6J","Junichi Kato","01M6CZP6PXKYDDNX5A7PZ3P4DY",28,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fkiro-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28],"review","kiro","kiro review","verification","remediation","implementer","use","evidence","implementation","task","2026-11-10 10:12:30",false,"---\nname: kiro-review\ndescription: Review a task implementation against approved specs, task boundaries, and verification evidence. Use after an implementer finishes a task, after remediation, or before accepting a task as complete.\n---\n\n# kiro-review\n\n\u003Cbackground_information>\nThis skill performs task-local adversarial review. It verifies that the implementation is real, complete, bounded, aligned with approved requirements and design, and supported by mechanical verification evidence.\n\nBoundary terminology continuity:\n- discovery identifies `Boundary Candidates`\n- design fixes the design boundary section named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md`\n- tasks constrain execution with `_Boundary:_`\n- review rejects concrete `Boundary Violations`\n\u003C\u002Fbackground_information>\n\n\u003Cinstructions>\n## When to Use\n\n- After an implementer reports `READY_FOR_REVIEW`\n- After remediation for a rejected review\n- Before marking a task `[x]`\n- Before accepting a task into feature-level validation\n\nDo not use this skill to invent missing requirements or silently reinterpret the spec.\n\n## Inputs\n\nProvide:\n- Task ID and exact task text from `tasks.md`\n- Relevant requirement section numbers\n- Relevant design section numbers\n- Spec file paths (`spec.json`, `requirements.md`, `design.md`, optionally `tasks.md`)\n- `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md` for language-specific boundary terms\n- The implementer's status report\n- The task `_Boundary:_` scope constraints\n- Validation commands discovered by the controller\n- Relevant steering excerpts when applicable\n- Relevant `## Implementation Notes` entries when applicable\n\n## Outputs\n\nReturn one of:\n- `APPROVED`\n- `REJECTED`\n\nAlso return:\n- Mechanical results\n- Findings with severity\n- Required remediation\n- One-sentence summary\n\nUse the language specified in `spec.json`.\n\n## First Action\n\nRun `git diff` to inspect the actual code changes. If the diff is large or ambiguous, read the changed files directly. Do not trust the implementer report as source of truth.\n\n## Core Principle\n\nRead the spec yourself. Read the diff yourself. Verify mechanically where possible. Reject on concrete failures rather than interpretive optimism.\nThe main review question is not just \"does it work?\" but \"does it stay inside the approved responsibility boundary without hiding new coupling?\"\n\n## Mechanical Checks\n\nRun these checks and use the result as primary signal.\n\n### 1. Regression Safety\n- Run the project's canonical test suite using the validation commands discovered by the controller.\n- If tests fail, reject.\n\n### 2. No Residual Placeholder Markers\n- Check changed files for `TBD`, `TODO`, `FIXME`, `HACK`, `XXX`.\n- Reject if new placeholder markers were introduced without explicit task justification.\n\n### 3. No Hardcoded Secrets\n- Check changed files for hardcoded secrets or credentials.\n- Reject if concrete secret patterns are introduced.\n\n### 4. Boundary Respect\n- Compare changed files against the task `_Boundary:_` scope.\n- Reject if the change spills outside the approved boundary without explicit justification.\n- Reject if the implementation introduces hidden cross-boundary coordination inside what should be a local task.\n\n### 5. RED Phase Evidence\n- For behavioral tasks, verify that the implementer status report includes `RED_PHASE_OUTPUT`.\n- Reject if RED evidence is missing, empty, or unrelated to the task's acceptance criteria.\n\n### 6. Runtime-Sensitive Static Checks\n- If the project already has lint or equivalent static analysis for the touched stack, run the relevant command for the task boundary.\n- Pay attention to patterns that can survive typecheck\u002Fbuild yet fail at runtime: type-only imports used as values, missing namespace value imports for qualified-name access, unresolved globals, and newly introduced runtime-sensitive dependencies without matching boot\u002Fruntime handling.\n- If no project lint command exists, perform a targeted diff-based spot check in the changed files for those patterns.\n- Reject on concrete findings that create a realistic boot-time or module-load failure.\n\n## Judgment Checks\n\n### 7. Reality Check\n- Confirm the implementation is real production code, not a placeholder, stub, fake path, or deferred-work shell.\n\n### 8. Acceptance Criteria Coverage\n- Read the task description and confirm all aspects are implemented, not only the primary happy path.\n\n### 9. Requirements Alignment\n- Read the referenced sections in `requirements.md`.\n- Confirm each requirement is satisfied by concrete observable behavior.\n- Use original section numbers only.\n\n### 10. Design Alignment\n- Read the referenced sections in `design.md`.\n- Confirm the implementation uses the prescribed structures, interfaces, and dependency direction.\n- Reject silent substitutions for design-mandated choices.\n\n### 10.5 Boundary Audit\n- Compare the implementation against the design boundary and out-of-boundary terms named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md`, using `spec.json.language` to select the artifact language.\n- Reject if downstream-specific behavior is pushed into an upstream boundary for convenience.\n- Reject if the implementation creates new hidden dependencies, shared ownership, or undeclared coupling across adjacent boundaries.\n- Reject if a task that is not an explicit integration task now behaves like one.\n\n### 11. Test Quality\n- Confirm tests prove the required behavior rather than only scaffolding.\n- Confirm tests would fail if the implementation were removed or broken.\n\n### 12. Error Handling\n- Confirm relevant failure paths are handled and not silently swallowed.\n\n## Severity Model\n\nUse:\n- `Critical` for broken functionality, invalid verification, data loss, security risk, or major scope violation\n- `Important` for required fixes before acceptance\n- `Suggestion` for non-blocking improvements\n- `FYI` for informational notes\n\n## Stop \u002F Escalate\n\nEscalate instead of papering over the issue when:\n- The approved spec is ambiguous in a correctness-critical way\n- The design conflicts with what is technically possible\n- Required evidence cannot be gathered\n- The implementation only works by silently deviating from approved scope\n- Boundary ownership cannot be determined cleanly from requirements, design, and task scope\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| “Tests pass, so approve” | Passing tests do not prove spec compliance or boundary respect. |\n| “The extra behavior is useful” | Extra behavior outside approved scope is still drift. |\n| “The implementer said RED was done” | RED must be evidenced, not asserted. |\n| “This gap is small enough to let through” | Real gaps must be rejected or escalated. |\n\n## Output Format\n\n```md\n## Review Verdict\n- VERDICT: APPROVED | REJECTED\n- TASK: \u003Ctask-id>\n- MECHANICAL_RESULTS:\n  - Tests: PASS | FAIL (command and exit code)\n  - TBD\u002FTODO grep: CLEAN | \u003Ccount> matches\n  - Secrets grep: CLEAN | \u003Ccount> matches\n  - Static checks: PASS | FAIL | SPOT_CHECKED\n  - Boundary: WITHIN | \u003Cfiles outside boundary>\n  - Boundary audit: CLEAN | \u003Cspillover \u002F hidden dependency findings>\n  - RED phase: VERIFIED | MISSING | N\u002FA\n- FINDINGS:\n  1. \u003Cspecific finding with exact files\u002Fspec refs>\n- REMEDIATION: \u003Cmandatory if REJECTED>\n- SUMMARY: \u003Cone sentence>\n```\n\u003C\u002Finstructions>\n","# kiro-review\n\n\u003Cbackground_information>\nThis skill performs task-local adversarial review. It verifies that the implementation is real, complete, bounded, aligned with approved requirements and design, and supported by mechanical verification evidence.\n\nBoundary terminology continuity:\n- discovery identifies `Boundary Candidates`\n- design fixes the design boundary section named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md`\n- tasks constrain execution with `_Boundary:_`\n- review rejects concrete `Boundary Violations`\n\u003C\u002Fbackground_information>\n\n\u003Cinstructions>\n## When to Use\n\n- After an implementer reports `READY_FOR_REVIEW`\n- After remediation for a rejected review\n- Before marking a task `[x]`\n- Before accepting a task into feature-level validation\n\nDo not use this skill to invent missing requirements or silently reinterpret the spec.\n\n## Inputs\n\nProvide:\n- Task ID and exact task text from `tasks.md`\n- Relevant requirement section numbers\n- Relevant design section numbers\n- Spec file paths (`spec.json`, `requirements.md`, `design.md`, optionally `tasks.md`)\n- `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md` for language-specific boundary terms\n- The implementer's status report\n- The task `_Boundary:_` scope constraints\n- Validation commands discovered by the controller\n- Relevant steering excerpts when applicable\n- Relevant `## Implementation Notes` entries when applicable\n\n## Outputs\n\nReturn one of:\n- `APPROVED`\n- `REJECTED`\n\nAlso return:\n- Mechanical results\n- Findings with severity\n- Required remediation\n- One-sentence summary\n\nUse the language specified in `spec.json`.\n\n## First Action\n\nRun `git diff` to inspect the actual code changes. If the diff is large or ambiguous, read the changed files directly. Do not trust the implementer report as source of truth.\n\n## Core Principle\n\nRead the spec yourself. Read the diff yourself. Verify mechanically where possible. Reject on concrete failures rather than interpretive optimism.\nThe main review question is not just \"does it work?\" but \"does it stay inside the approved responsibility boundary without hiding new coupling?\"\n\n## Mechanical Checks\n\nRun these checks and use the result as primary signal.\n\n### 1. Regression Safety\n- Run the project's canonical test suite using the validation commands discovered by the controller.\n- If tests fail, reject.\n\n### 2. No Residual Placeholder Markers\n- Check changed files for `TBD`, `TODO`, `FIXME`, `HACK`, `XXX`.\n- Reject if new placeholder markers were introduced without explicit task justification.\n\n### 3. No Hardcoded Secrets\n- Check changed files for hardcoded secrets or credentials.\n- Reject if concrete secret patterns are introduced.\n\n### 4. Boundary Respect\n- Compare changed files against the task `_Boundary:_` scope.\n- Reject if the change spills outside the approved boundary without explicit justification.\n- Reject if the implementation introduces hidden cross-boundary coordination inside what should be a local task.\n\n### 5. RED Phase Evidence\n- For behavioral tasks, verify that the implementer status report includes `RED_PHASE_OUTPUT`.\n- Reject if RED evidence is missing, empty, or unrelated to the task's acceptance criteria.\n\n### 6. Runtime-Sensitive Static Checks\n- If the project already has lint or equivalent static analysis for the touched stack, run the relevant command for the task boundary.\n- Pay attention to patterns that can survive typecheck\u002Fbuild yet fail at runtime: type-only imports used as values, missing namespace value imports for qualified-name access, unresolved globals, and newly introduced runtime-sensitive dependencies without matching boot\u002Fruntime handling.\n- If no project lint command exists, perform a targeted diff-based spot check in the changed files for those patterns.\n- Reject on concrete findings that create a realistic boot-time or module-load failure.\n\n## Judgment Checks\n\n### 7. Reality Check\n- Confirm the implementation is real production code, not a placeholder, stub, fake path, or deferred-work shell.\n\n### 8. Acceptance Criteria Coverage\n- Read the task description and confirm all aspects are implemented, not only the primary happy path.\n\n### 9. Requirements Alignment\n- Read the referenced sections in `requirements.md`.\n- Confirm each requirement is satisfied by concrete observable behavior.\n- Use original section numbers only.\n\n### 10. Design Alignment\n- Read the referenced sections in `design.md`.\n- Confirm the implementation uses the prescribed structures, interfaces, and dependency direction.\n- Reject silent substitutions for design-mandated choices.\n\n### 10.5 Boundary Audit\n- Compare the implementation against the design boundary and out-of-boundary terms named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md`, using `spec.json.language` to select the artifact language.\n- Reject if downstream-specific behavior is pushed into an upstream boundary for convenience.\n- Reject if the implementation creates new hidden dependencies, shared ownership, or undeclared coupling across adjacent boundaries.\n- Reject if a task that is not an explicit integration task now behaves like one.\n\n### 11. Test Quality\n- Confirm tests prove the required behavior rather than only scaffolding.\n- Confirm tests would fail if the implementation were removed or broken.\n\n### 12. Error Handling\n- Confirm relevant failure paths are handled and not silently swallowed.\n\n## Severity Model\n\nUse:\n- `Critical` for broken functionality, invalid verification, data loss, security risk, or major scope violation\n- `Important` for required fixes before acceptance\n- `Suggestion` for non-blocking improvements\n- `FYI` for informational notes\n\n## Stop \u002F Escalate\n\nEscalate instead of papering over the issue when:\n- The approved spec is ambiguous in a correctness-critical way\n- The design conflicts with what is technically possible\n- Required evidence cannot be gathered\n- The implementation only works by silently deviating from approved scope\n- Boundary ownership cannot be determined cleanly from requirements, design, and task scope\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| “Tests pass, so approve” | Passing tests do not prove spec compliance or boundary respect. |\n| “The extra behavior is useful” | Extra behavior outside approved scope is still drift. |\n| “The implementer said RED was done” | RED must be evidenced, not asserted. |\n| “This gap is small enough to let through” | Real gaps must be rejected or escalated. |\n\n## Output Format\n\n```md\n## Review Verdict\n- VERDICT: APPROVED | REJECTED\n- TASK: \u003Ctask-id>\n- MECHANICAL_RESULTS:\n  - Tests: PASS | FAIL (command and exit code)\n  - TBD\u002FTODO grep: CLEAN | \u003Ccount> matches\n  - Secrets grep: CLEAN | \u003Ccount> matches\n  - Static checks: PASS | FAIL | SPOT_CHECKED\n  - Boundary: WITHIN | \u003Cfiles outside boundary>\n  - Boundary audit: CLEAN | \u003Cspillover \u002F hidden dependency findings>\n  - RED phase: VERIFIED | MISSING | N\u002FA\n- FINDINGS:\n  1. \u003Cspecific finding with exact files\u002Fspec refs>\n- REMEDIATION: \u003Cmandatory if REJECTED>\n- SUMMARY: \u003Cone sentence>\n```\n\u003C\u002Finstructions>\n",{"name":5,"description":7},"main","3e6b722545091ed1bb6b81fe15f38189099154c1",".agents\u002Fskills\u002Fkiro-review",0,"https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools","https:\u002F\u002Fgithub.com\u002Fj5ik2o","https:\u002F\u002Flapras.com\u002Fpublic\u002FNHXS5RH","I'm a tech-lead in the IDEO;PLUS Inc, is lover to Scala\u002FRust, Akka, DDD\u002FCQRS+Event Sourcing.","2026-11-12 10:31:08",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add j5ik2o\u002Fai-tools --skill kiro-review",{"tool":49,"command":50},"bunx","bunx skills add j5ik2o\u002Fai-tools --skill kiro-review",{"tool":52,"command":53},"pnpm","pnpm dlx skills add j5ik2o\u002Fai-tools --skill kiro-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fkiro-review\u002FSKILL.md",true,[57],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"agents\u002Fopenai.yaml","REFERENCE","参考文档",170,"https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fkiro-review\u002Fagents\u002Fopenai.yaml",[64,79,86,109,119,131],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":75,"publishedAt":29},"01M6D03X604YGMM6YFEG4M6767","takt","TAKT ワークフローエンジン。Agent Team を使ったマルチエージェントオーケストレーション。ワークフロー YAML（steps \u002F initial_step）に従ってマルチエージェントを実行する。","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-workflow-builder\u002Freferences\u002Ftakt\u002Fbuiltins\u002Fskill\u002FSKILL.md",[70],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[66,76,77,78],"agent team","team","yaml",{"skillNo":80,"name":66,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":29},"01M6D03TAJ6WKRV6XACZHZ70NS","TAKT ワークフローエンジン。codex exec でサブエージェントを起動し、ワークフロー YAML（steps \u002F initial_step）に従って マルチエージェントオーケストレーションを実行する。","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-workflow-builder\u002Freferences\u002Ftakt\u002Fbuiltins\u002Fskill-codex\u002FSKILL.md",[],[66,78,85],"codex",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":98,"publishedAt":29},"01M6D02V9SQ13TEDYDGN67K3WA","j5ik2o-takt-workflow-builder","TAKTワークフロー（ワークフローYAML）の作成・カスタマイズスキル。Faceted Prompting （Persona\u002FPolicy\u002FInstruction\u002FKnowledge\u002FOutput Contract）に基づくファセット群の 生成を含む。references\u002Ftaktにあるtaktのソースコード・ドキュメント・ビルトインワークフロー群を 参照資料として活用する。ユーザーの要件をヒアリングし、step構成、ルール設計、 ファセットファイル生成を一括で行う。 トリガー：「ワークフローを作りたい」「ワークフローを定義」「taktのワークフローを作成」 「新しいtaktワークフローを作って」「takt workflow」「ワークフローYAML」","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-workflow-builder\u002FSKILL.md",[92,93],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[99,66,100,101,102,103,104,105,106,107,108],"j5ik2o takt workflow builder","builder","workflow builder","workflow","生成","contract","references","knowledge","persona","policy",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":29},"01M6D02P0Y4DEJ19J6V4S5VZ2S","j5ik2o-takt-task-builder","TAKTのtasks.yaml（タスクメタデータ）とタスクディレクトリ（.takt\u002Ftasks\u002F{slug}\u002Forder.md）の 作成・編集を支援するスキル。TaskRecordスキーマに準拠したYAMLエントリの生成、 order.mdタスク仕様書の作成、ステータス遷移ルールの検証を行う。 references\u002Ftaktにあるtaskスキーマ定義・ドキュメントを参照資料として活用する。 トリガー：「タスクを追加」「tasks.yamlを編集」「taktタスクを作成」 「タスク仕様書を書く」「order.mdを作成」「takt task」「タスクを定義」 「pendingタスクを追加」「GitHub Issueからタスク作成」","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-task-builder\u002FSKILL.md",[],[66,116,28,100,105,103,78,117,118],"j5ik2o takt task builder","tasks","github",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":29},"01M6D022WYSR825B6KB2CSNNY0","j5ik2o-takt-skill-updater","nrslib\u002Ftakt の新バージョンリリース時に、takt-*スキル群（j5ik2o-takt-task-builder, j5ik2o-takt-workflow-builder, j5ik2o-takt-facet-builder, j5ik2o-takt-analyzer, j5ik2o-takt-optimizer）を最新のtaktバージョンに追従させるスキル。 TypeScriptスキーマ（taskRecordSchemas.ts \u002F taskExecutionSchemas.ts）、ワークフローYAML、ファセットMarkdownの差分を検出し、 SKILL.md・参照ドキュメント（task-schema.md等）を体系的に更新する。 トリガー：「taktスキルを更新」「takt-*スキルの鮮度チェック」「taktバージョンアップ対応」 「スキルが古くないか確認」「takt skill updater」","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-skill-updater\u002FSKILL.md",[125],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},[66,127,128,102,129,100,28,130],"skill updater","j5ik2o takt skill updater","schema","optimizer",{"skillNo":132,"name":66,"nameZh":6,"description":67,"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":136,"publishedAt":29},"01M6D01Z6WJEXJTXRKEK6N2NBM","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-optimizer\u002Freferences\u002Ftakt\u002Fbuiltins\u002Fskill\u002FSKILL.md",[135],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},[66,77,76,78]]