[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CZSZV5V59VJSYSS2MGTA35":3,"skill-same:01M6CZSZV5V59VJSYSS2MGTA35":70},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6CZSZV5V59VJSYSS2MGTA35","kiro-validate-impl",null,"Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.","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.claude\u002Fskills\u002Fkiro-validate-impl\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"validate","kiro","kiro validate impl","spec","test","tasks","integration","Bash","grep","read","coverage","test suite","task","full","feature","2026-11-10 10:12:30",false,"---\nname: kiro-validate-impl\ndescription: Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.\nallowed-tools: Read, Bash, Grep, Glob, Agent\nargument-hint: \u003Cfeature-name> [task-numbers]\n---\n\n# kiro-validate-impl Skill\n\n## Role\nIndividual tasks have already been reviewed by the per-task reviewer during implementation. Your job is to catch problems that only become visible when looking across all tasks together.\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- feature validation checks for cross-task `Boundary Violations`\n\n## Core Mission\n- **Success Criteria**:\n  - All tasks marked `[x]` in tasks.md\n  - Full test suite passes (not just per-task tests)\n  - Cross-task integration works (data flows between components, interfaces match)\n  - Requirements coverage is complete across all tasks (no gaps between tasks)\n  - Design structure is reflected end-to-end (not just per-component)\n  - No orphaned code, conflicting implementations, integration seams, or boundary spillover\n\n## What This Skill Does NOT Do\nPer-task checks are the reviewer's responsibility during `\u002Fkiro-impl`. This skill does **not** re-check:\n- Individual task acceptance criteria\n- Per-file reality checks (mock\u002Fstub detection)\n- Single-task spec alignment\n\nThis skill's main question is: when the completed tasks are viewed together, do they still respect the designed boundary seams and dependency direction?\n\n## Execution Steps\n\n### Step 1: Detect Validation Target\n\n**If no arguments provided**:\n- Parse conversation history for `\u002Fkiro-impl` commands to detect recently implemented features and tasks\n- Scan `.kiro\u002Fspecs\u002F` for features with completed tasks `[x]`\n- Report detected implementations (e.g., \"user-auth: 1.1, 1.2, 1.3\")\n\n**If feature provided** (feature specified, tasks empty):\n- Use specified feature\n- Detect all completed tasks `[x]` in `.kiro\u002Fspecs\u002F{feature}\u002Ftasks.md`\n\n**If both feature and tasks provided** (explicit mode):\n- Validate specified feature and tasks only (e.g., `user-auth 1.1,1.2`)\n\n### Step 2: Gather Context\n\nIf steering\u002Fspec context is already available from conversation, skip redundant file reads.\nOtherwise, for each detected feature:\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Fspec.json` for metadata\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Frequirements.md` for requirements\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Fdesign.md` for design structure\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Ftasks.md` for task list and Implementation Notes\n- Read `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md` and resolve language-specific section terms from `spec.json.language` before design boundary checks\n- Core steering context: `product.md`, `tech.md`, `structure.md`\n- Additional steering files only when directly relevant to the validated boundaries, runtime prerequisites, integrations, domain rules, security\u002Fperformance constraints, or team conventions that affect the GO\u002FNO-GO call\n\n**Discover canonical validation commands**:\n- Inspect repository-local sources of truth in this order: project scripts\u002Fmanifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, app manifests), task runners (`Makefile`, `justfile`), CI\u002Fworkflow files, existing e2e\u002Fintegration configs, then `README*`\n- Derive a feature-level validation set for this repo: `TEST_COMMANDS`, `BUILD_COMMANDS`, and `SMOKE_COMMANDS`\n- Prefer commands already used by repo automation over ad hoc shell pipelines\n- For `SMOKE_COMMANDS`, choose the lightest trustworthy runtime-liveness check for the app shape (for example: root URL load, Electron launch, CLI `--help`, service health endpoint, mobile simulator\u002Fe2e harness if one already exists)\n- If multiple candidates exist, prefer the command with the smallest setup cost that still exercises the real built artifact\n\n### Step 3: Execute Integration Validation\n\n#### Subagent Dispatch (parallel)\n\nThe following validation dimensions are independent and can be dispatched as **subagents** via the Agent tool. The agent should decide the optimal decomposition based on feature scope — split, merge, or skip subagents as appropriate. Each subagent returns a **structured findings summary** to keep the main context clean for GO\u002FNO-GO synthesis.\n\n**Typical validation dimensions** (adjust as appropriate):\n- **Test execution**: Run the complete test suite, report pass\u002Ffail with details\n- **Requirements coverage**: Build requirements → implementation matrix, report gaps\n- **Design alignment**: Verify architecture matches design.md, report drift and dependency violations\n- **Cross-task integration**: Verify data flows, API contracts, shared state consistency\n\nFor simple features (few tasks, small scope), run checks in main context without subagent dispatch.\n\n#### Mechanical Checks (run commands, use results)\n\nThese checks apply at the feature level. Use command output as the primary signal.\n\n**A. Full Test Suite**\n- Run the discovered canonical full-test command. Use the exit code.\n- If tests fail → NO-GO. No judgment needed.\n- If the canonical test command cannot be identified → `MANUAL_VERIFY_REQUIRED`\n\n**B. Residual TBD\u002FTODO\u002FFIXME**\n- Run: `grep -rn \"TBD\\|TODO\\|FIXME\\|HACK\\|XXX\" \u003Cfiles-in-feature-boundary>`\n- If matches found that were introduced by this feature → flag as Warning\n\n**C. Residual Hardcoded Secrets**\n- Run: `grep -rn \"password\\s*=\\|api_key\\s*=\\|secret\\s*=\\|token\\s*=\" \u003Cfiles-in-feature-boundary>` (case-insensitive)\n- If matches found that aren't environment variable references → flag as Critical\n\n**D. Runtime Liveness (Smoke Boot)**\n- Run the discovered canonical smoke command that proves the built artifact actually starts and reaches its first usable state.\n- Examples if relevant: open the root URL in a headless browser and require zero boot-time console errors; launch Electron and wait for the main process ready signal and first renderer load; run a CLI with `--help`; start a service and hit its health endpoint.\n- If boot produces a runtime crash, unhandled exception, module-load failure, native ABI mismatch, or missing required env\u002Fconfig → NO-GO.\n- If no trustworthy smoke command can be identified, or the required runtime environment is unavailable → `MANUAL_VERIFY_REQUIRED`\n\n#### Judgment Checks (read code, compare to spec)\n\n**E. Cross-Task Integration**\n- Identify where tasks share interfaces, data models, or API contracts\n- Verify that Task A's output format matches Task B's expected input\n- Check for conflicting assumptions between tasks (naming conventions, error codes, data shapes)\n- Verify shared state (database schemas, config, environment) is consistent across tasks\n- Verify integration work happens at the intended seams rather than by leaking one boundary's behavior into another\n\n**F. Requirements Coverage Gaps**\n- Map every requirement section to at least one completed task\n- Identify requirements that no single task fully covers (cross-cutting requirements)\n- Identify requirements partially covered by multiple tasks but not fully by any\n- Use the original section numbering from `requirements.md`; do NOT invent `REQ-*` aliases\n\n**G. Design End-to-End Alignment**\n- Verify the overall component graph matches design.md\n- Check that integration patterns (event flow, API boundaries, dependency injection) work as designed\n- Verify dependency direction follows design.md's architecture (no upward imports)\n- Verify the file structure section named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md` matches the actual file layout\n- Identify any architectural drift from the original design\n- Use the original section numbering from `design.md`\n\n**G.5 Boundary Audit**\n- Compare completed work against the boundary terms named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md`\n- Identify cross-task spillover where one area quietly absorbed another boundary's responsibility\n- Identify downstream-specific workarounds embedded upstream \"to make integration easier\"\n- Identify new hidden dependencies or shared ownership that were not declared in the design\n- If a revalidation trigger fired, verify the affected adjacent specs or integration points were actually re-checked\n\n**H. Blocked Tasks & Implementation Notes**\n- Check for any tasks still marked `_Blocked:_` — report why and assess impact on feature completeness\n- Review `## Implementation Notes` in tasks.md for cross-cutting insights that need attention\n\n### Step 4: Generate Report\n\nBefore returning `GO`, apply the `kiro-verify-completion` protocol to the feature-level claim. Tests alone are insufficient: include full-suite, runtime liveness, coverage, integration, design-alignment, and blocked-task status in the evidence.\n\nClassify concrete failures by ownership before writing remediation:\n- `LOCAL` if the defect belongs to the feature being validated\n- `UPSTREAM` if the root cause belongs to a dependency, foundation, shared platform, or earlier spec\n- `UNCLEAR` if ownership cannot be established from the available evidence\n\nIf ownership is `UPSTREAM`, do not collapse the issue into local remediation for this feature. Name the owning upstream spec and explain which dependent specs should be revalidated after that upstream fix lands.\n\nProvide summary in the language specified in spec.json:\n\n```\n## Validation Report\n- DECISION: GO | NO-GO | MANUAL_VERIFY_REQUIRED\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  - Smoke boot: PASS | FAIL | MANUAL_REQUIRED\n- INTEGRATION:\n  - Cross-task contracts: \u003Cstatus>\n  - Shared state consistency: \u003Cstatus>\n  - Boundary audit: \u003Cstatus>\n- COVERAGE:\n  - Requirements mapped: \u003CX\u002FY sections covered>\n  - Coverage gaps: \u003Clist of uncovered requirement sections>\n- DESIGN:\n  - Architecture drift: \u003Cfindings>\n  - Dependency direction: \u003Cviolations if any>\n  - File structure plan vs actual: \u003Cmatch\u002Fmismatch>\n- OWNERSHIP: LOCAL | UPSTREAM | UNCLEAR\n- UPSTREAM_SPEC: \u003Cfeature-name | N\u002FA>\n- BLOCKED_TASKS: \u003Clist and impact assessment>\n- REMEDIATION: \u003Cif NO-GO: specific, actionable steps to fix each issue>\n```\n\nIf NO-GO, REMEDIATION is mandatory — identify the exact issue and what needs to change. Vague feedback is not acceptable.\n\n## Important Constraints\n- **Strict Final Gate**: Return `GO` only when all integration checks passed; return `NO-GO` for concrete failures and `MANUAL_VERIFY_REQUIRED` when mandatory validation could not be completed\n- **Boundary integrity over convenience**: Do not return `GO` if the feature only works by smearing responsibilities across boundaries, even when tests pass\n\n## Safety & Fallback\n\n### Error Scenarios\n- **No Implementation Found**: If no `[x]` tasks found, report \"No implementations detected\"\n- **Test Command Unknown**: Return `MANUAL_VERIFY_REQUIRED` and explain which validation command is missing; do not return `GO`\n- **Missing Spec Files**: Stop with error if spec.json\u002Frequirements.md\u002Fdesign.md missing\n\n### Next Steps Guidance\n\n**If GO Decision**:\n- Feature validated end-to-end and ready for deployment or next feature\n\n**If NO-GO Decision**:\n- Address issues listed in REMEDIATION\n- Re-run `\u002Fkiro-impl {feature} [tasks]` for targeted fixes\n- Re-validate with `\u002Fkiro-validate-impl {feature}`\n\n**If MANUAL_VERIFY_REQUIRED**:\n- Do not treat the feature as complete\n- Provide the exact missing validation step or environment prerequisite\n","# kiro-validate-impl Skill\n\n## Role\nIndividual tasks have already been reviewed by the per-task reviewer during implementation. Your job is to catch problems that only become visible when looking across all tasks together.\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- feature validation checks for cross-task `Boundary Violations`\n\n## Core Mission\n- **Success Criteria**:\n  - All tasks marked `[x]` in tasks.md\n  - Full test suite passes (not just per-task tests)\n  - Cross-task integration works (data flows between components, interfaces match)\n  - Requirements coverage is complete across all tasks (no gaps between tasks)\n  - Design structure is reflected end-to-end (not just per-component)\n  - No orphaned code, conflicting implementations, integration seams, or boundary spillover\n\n## What This Skill Does NOT Do\nPer-task checks are the reviewer's responsibility during `\u002Fkiro-impl`. This skill does **not** re-check:\n- Individual task acceptance criteria\n- Per-file reality checks (mock\u002Fstub detection)\n- Single-task spec alignment\n\nThis skill's main question is: when the completed tasks are viewed together, do they still respect the designed boundary seams and dependency direction?\n\n## Execution Steps\n\n### Step 1: Detect Validation Target\n\n**If no arguments provided**:\n- Parse conversation history for `\u002Fkiro-impl` commands to detect recently implemented features and tasks\n- Scan `.kiro\u002Fspecs\u002F` for features with completed tasks `[x]`\n- Report detected implementations (e.g., \"user-auth: 1.1, 1.2, 1.3\")\n\n**If feature provided** (feature specified, tasks empty):\n- Use specified feature\n- Detect all completed tasks `[x]` in `.kiro\u002Fspecs\u002F{feature}\u002Ftasks.md`\n\n**If both feature and tasks provided** (explicit mode):\n- Validate specified feature and tasks only (e.g., `user-auth 1.1,1.2`)\n\n### Step 2: Gather Context\n\nIf steering\u002Fspec context is already available from conversation, skip redundant file reads.\nOtherwise, for each detected feature:\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Fspec.json` for metadata\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Frequirements.md` for requirements\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Fdesign.md` for design structure\n- Read `.kiro\u002Fspecs\u002F\u003Cfeature>\u002Ftasks.md` for task list and Implementation Notes\n- Read `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md` and resolve language-specific section terms from `spec.json.language` before design boundary checks\n- Core steering context: `product.md`, `tech.md`, `structure.md`\n- Additional steering files only when directly relevant to the validated boundaries, runtime prerequisites, integrations, domain rules, security\u002Fperformance constraints, or team conventions that affect the GO\u002FNO-GO call\n\n**Discover canonical validation commands**:\n- Inspect repository-local sources of truth in this order: project scripts\u002Fmanifests (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, app manifests), task runners (`Makefile`, `justfile`), CI\u002Fworkflow files, existing e2e\u002Fintegration configs, then `README*`\n- Derive a feature-level validation set for this repo: `TEST_COMMANDS`, `BUILD_COMMANDS`, and `SMOKE_COMMANDS`\n- Prefer commands already used by repo automation over ad hoc shell pipelines\n- For `SMOKE_COMMANDS`, choose the lightest trustworthy runtime-liveness check for the app shape (for example: root URL load, Electron launch, CLI `--help`, service health endpoint, mobile simulator\u002Fe2e harness if one already exists)\n- If multiple candidates exist, prefer the command with the smallest setup cost that still exercises the real built artifact\n\n### Step 3: Execute Integration Validation\n\n#### Subagent Dispatch (parallel)\n\nThe following validation dimensions are independent and can be dispatched as **subagents** via the Agent tool. The agent should decide the optimal decomposition based on feature scope — split, merge, or skip subagents as appropriate. Each subagent returns a **structured findings summary** to keep the main context clean for GO\u002FNO-GO synthesis.\n\n**Typical validation dimensions** (adjust as appropriate):\n- **Test execution**: Run the complete test suite, report pass\u002Ffail with details\n- **Requirements coverage**: Build requirements → implementation matrix, report gaps\n- **Design alignment**: Verify architecture matches design.md, report drift and dependency violations\n- **Cross-task integration**: Verify data flows, API contracts, shared state consistency\n\nFor simple features (few tasks, small scope), run checks in main context without subagent dispatch.\n\n#### Mechanical Checks (run commands, use results)\n\nThese checks apply at the feature level. Use command output as the primary signal.\n\n**A. Full Test Suite**\n- Run the discovered canonical full-test command. Use the exit code.\n- If tests fail → NO-GO. No judgment needed.\n- If the canonical test command cannot be identified → `MANUAL_VERIFY_REQUIRED`\n\n**B. Residual TBD\u002FTODO\u002FFIXME**\n- Run: `grep -rn \"TBD\\|TODO\\|FIXME\\|HACK\\|XXX\" \u003Cfiles-in-feature-boundary>`\n- If matches found that were introduced by this feature → flag as Warning\n\n**C. Residual Hardcoded Secrets**\n- Run: `grep -rn \"password\\s*=\\|api_key\\s*=\\|secret\\s*=\\|token\\s*=\" \u003Cfiles-in-feature-boundary>` (case-insensitive)\n- If matches found that aren't environment variable references → flag as Critical\n\n**D. Runtime Liveness (Smoke Boot)**\n- Run the discovered canonical smoke command that proves the built artifact actually starts and reaches its first usable state.\n- Examples if relevant: open the root URL in a headless browser and require zero boot-time console errors; launch Electron and wait for the main process ready signal and first renderer load; run a CLI with `--help`; start a service and hit its health endpoint.\n- If boot produces a runtime crash, unhandled exception, module-load failure, native ABI mismatch, or missing required env\u002Fconfig → NO-GO.\n- If no trustworthy smoke command can be identified, or the required runtime environment is unavailable → `MANUAL_VERIFY_REQUIRED`\n\n#### Judgment Checks (read code, compare to spec)\n\n**E. Cross-Task Integration**\n- Identify where tasks share interfaces, data models, or API contracts\n- Verify that Task A's output format matches Task B's expected input\n- Check for conflicting assumptions between tasks (naming conventions, error codes, data shapes)\n- Verify shared state (database schemas, config, environment) is consistent across tasks\n- Verify integration work happens at the intended seams rather than by leaking one boundary's behavior into another\n\n**F. Requirements Coverage Gaps**\n- Map every requirement section to at least one completed task\n- Identify requirements that no single task fully covers (cross-cutting requirements)\n- Identify requirements partially covered by multiple tasks but not fully by any\n- Use the original section numbering from `requirements.md`; do NOT invent `REQ-*` aliases\n\n**G. Design End-to-End Alignment**\n- Verify the overall component graph matches design.md\n- Check that integration patterns (event flow, API boundaries, dependency injection) work as designed\n- Verify dependency direction follows design.md's architecture (no upward imports)\n- Verify the file structure section named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md` matches the actual file layout\n- Identify any architectural drift from the original design\n- Use the original section numbering from `design.md`\n\n**G.5 Boundary Audit**\n- Compare completed work against the boundary terms named by `.kiro\u002Fsettings\u002Ftemplates\u002Fspecs\u002Flocalized-spec-terminology.md`\n- Identify cross-task spillover where one area quietly absorbed another boundary's responsibility\n- Identify downstream-specific workarounds embedded upstream \"to make integration easier\"\n- Identify new hidden dependencies or shared ownership that were not declared in the design\n- If a revalidation trigger fired, verify the affected adjacent specs or integration points were actually re-checked\n\n**H. Blocked Tasks & Implementation Notes**\n- Check for any tasks still marked `_Blocked:_` — report why and assess impact on feature completeness\n- Review `## Implementation Notes` in tasks.md for cross-cutting insights that need attention\n\n### Step 4: Generate Report\n\nBefore returning `GO`, apply the `kiro-verify-completion` protocol to the feature-level claim. Tests alone are insufficient: include full-suite, runtime liveness, coverage, integration, design-alignment, and blocked-task status in the evidence.\n\nClassify concrete failures by ownership before writing remediation:\n- `LOCAL` if the defect belongs to the feature being validated\n- `UPSTREAM` if the root cause belongs to a dependency, foundation, shared platform, or earlier spec\n- `UNCLEAR` if ownership cannot be established from the available evidence\n\nIf ownership is `UPSTREAM`, do not collapse the issue into local remediation for this feature. Name the owning upstream spec and explain which dependent specs should be revalidated after that upstream fix lands.\n\nProvide summary in the language specified in spec.json:\n\n```\n## Validation Report\n- DECISION: GO | NO-GO | MANUAL_VERIFY_REQUIRED\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  - Smoke boot: PASS | FAIL | MANUAL_REQUIRED\n- INTEGRATION:\n  - Cross-task contracts: \u003Cstatus>\n  - Shared state consistency: \u003Cstatus>\n  - Boundary audit: \u003Cstatus>\n- COVERAGE:\n  - Requirements mapped: \u003CX\u002FY sections covered>\n  - Coverage gaps: \u003Clist of uncovered requirement sections>\n- DESIGN:\n  - Architecture drift: \u003Cfindings>\n  - Dependency direction: \u003Cviolations if any>\n  - File structure plan vs actual: \u003Cmatch\u002Fmismatch>\n- OWNERSHIP: LOCAL | UPSTREAM | UNCLEAR\n- UPSTREAM_SPEC: \u003Cfeature-name | N\u002FA>\n- BLOCKED_TASKS: \u003Clist and impact assessment>\n- REMEDIATION: \u003Cif NO-GO: specific, actionable steps to fix each issue>\n```\n\nIf NO-GO, REMEDIATION is mandatory — identify the exact issue and what needs to change. Vague feedback is not acceptable.\n\n## Important Constraints\n- **Strict Final Gate**: Return `GO` only when all integration checks passed; return `NO-GO` for concrete failures and `MANUAL_VERIFY_REQUIRED` when mandatory validation could not be completed\n- **Boundary integrity over convenience**: Do not return `GO` if the feature only works by smearing responsibilities across boundaries, even when tests pass\n\n## Safety & Fallback\n\n### Error Scenarios\n- **No Implementation Found**: If no `[x]` tasks found, report \"No implementations detected\"\n- **Test Command Unknown**: Return `MANUAL_VERIFY_REQUIRED` and explain which validation command is missing; do not return `GO`\n- **Missing Spec Files**: Stop with error if spec.json\u002Frequirements.md\u002Fdesign.md missing\n\n### Next Steps Guidance\n\n**If GO Decision**:\n- Feature validated end-to-end and ready for deployment or next feature\n\n**If NO-GO Decision**:\n- Address issues listed in REMEDIATION\n- Re-run `\u002Fkiro-impl {feature} [tasks]` for targeted fixes\n- Re-validate with `\u002Fkiro-validate-impl {feature}`\n\n**If MANUAL_VERIFY_REQUIRED**:\n- Do not treat the feature as complete\n- Provide the exact missing validation step or environment prerequisite\n",{"name":5,"description":7,"allowed-tools":39,"argument-hint":40},"Read, Bash, Grep, Glob, Agent","\u003Cfeature-name> [task-numbers]","main","3e6b722545091ed1bb6b81fe15f38189099154c1",".claude\u002Fskills\u002Fkiro-validate-impl",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":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add j5ik2o\u002Fai-tools --skill kiro-validate-impl",{"tool":56,"command":57},"bunx","bunx skills add j5ik2o\u002Fai-tools --skill kiro-validate-impl",{"tool":59,"command":60},"pnpm","pnpm dlx skills add j5ik2o\u002Fai-tools --skill kiro-validate-impl","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fkiro-validate-impl\u002FSKILL.md",true,[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"resources\u002Fimplementation-playbook.md","REFERENCE","参考文档",17897,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fsimilarity-search-patterns\u002Fresources\u002Fimplementation-playbook.md",[71,86,93,116,125,137],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":82,"publishedAt":34},"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",[77],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[73,83,84,85],"agent team","team","yaml",{"skillNo":87,"name":73,"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":34},"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",[],[73,85,92],"codex",{"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":105,"publishedAt":34},"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",[99,100],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[106,73,107,108,109,110,111,112,113,114,115],"j5ik2o takt workflow builder","builder","workflow builder","workflow","生成","contract","references","knowledge","persona","policy",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":34},"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",[],[73,123,31,107,112,110,85,24,124],"j5ik2o takt task builder","github",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":34},"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",[131],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},[73,133,134,109,135,107,31,136],"skill updater","j5ik2o takt skill updater","schema","optimizer",{"skillNo":138,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":34},"01M6D01Z6WJEXJTXRKEK6N2NBM","https:\u002F\u002Fgithub.com\u002Fj5ik2o\u002Fai-tools\u002Fblob\u002Fmain\u002Fplugins\u002Ftakt\u002Fskills\u002Fj5ik2o-takt-optimizer\u002Freferences\u002Ftakt\u002Fbuiltins\u002Fskill\u002FSKILL.md",[141],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},[73,84,83,85]]