[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M76VZJDM5HXZ9FAQNH39BTH5":3,"skill-same:01M76VZJDM5HXZ9FAQNH39BTH5":68},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":14,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M76VZJDM5HXZ9FAQNH39BTH5","ag-validate-findings",null,"Use when running VALIDATE V2-V3 fan-out. Two-layer investigation (4 dimension agents + per-section feasibility agents) synthesized into PASS\u002FCONDITIONAL\u002FBLOCKED net gate. Strategy-agnostic.","ngxccc\u002Fagent-skills-kit","ngxccc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F163379246?v=4","01M758XVG64QK26AGK0WKB26TB","Ngoc Tran","01M758XVHB8J6MHV0YTBVDBXCA",0,"MIT","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fag-validate-findings\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: ag-validate-findings\ndescription: \"Use when running VALIDATE V2-V3 fan-out. Two-layer investigation (4 dimension agents + per-section feasibility agents) synthesized into PASS\u002FCONDITIONAL\u002FBLOCKED net gate. Strategy-agnostic.\"\ntrigger_keywords: validate findings, layer 1 dimensions, layer 2 feasibility, net gate, validate fan-out\nlayer: contract\n---\n\n# ag-validate-findings\n\n## When to Apply\n\nUse this skill when working with ag-validate-findings workflows, tasks, or system specifications.\n\n## How to Use\n\nRefer to the workflow instructions and command references detailed below.\n\n> **Output style:** Follow `process\u002Fdevelopment-protocols\u002Fcommunication-standards.md` — answer-first, plain language, no unexplained jargon, TL;DR on long responses.\n\nDefines the role specs, prompts, and output schemas for the two-layer VALIDATE fan-out (a parallel check across 4 dimensions + per-section feasibility probes). Produces a net gate verdict (PASS \u002F CONDITIONAL \u002F BLOCKED) and all the inputs needed to write the validate-contract — the written checklist that gates EXECUTE.\n\n---\n\n## References\n\n- `references\u002Fexample-validate-output.md` — full V4 menu + validate-contract template; calibrate output format against this file\n\n---\n\n## When To Invoke\n\n- VALIDATE V2–V3: invoked by `ag-validate-agent` after V1 pre-check passes\n- Post-execute review in UPDATE PROCESS when re-validation of a plan is needed\n\n---\n\n## Strategy Boundary\n\nThis skill is **STRATEGY-AGNOSTIC**. It defines the role specs, prompts, and output schemas for each dimension\u002Fsection agent. It does NOT determine how those agents are executed (Workflow vs parallel Agent tool vs ag-team).\n\nThe execution method is determined by `ag-agent-strategy-compare`, which must be invoked BEFORE `ag-validate-findings` is called. `ag-validate-findings` outputs agent role definitions; the caller executes them using the recommended strategy.\n\n---\n\n## Mode Selection\n\nChoose before spawning any agents. Pass the selected mode to all Layer 1 and Layer 2 agents in their prompt context.\n\n### Simple Mode (default)\n\nRuns the Layer 1 + Layer 2 fan-out using context available in the current conversation. Validation agents derive context from the plan file and what was passed in the prompt.\n\n**Appropriate when:**\n\n- Plan is self-contained (all context needed is in the plan text)\n- Context is fresh in the current conversation window\n- Blast radius is clear and confined to a single domain\n- No container\u002Finfra\u002Fworker lifecycle surfaces are touched\n- Fewer than 5 blast-radius packages\n\n### Deep Mode\n\nTrigger when **any one** of the following is true:\n\n- Plan blast radius touches container, infra, or worker lifecycle\n- Plan has 5+ blast-radius packages\n- Plan is a phase in a multi-phase program (prior phase outputs must be loaded)\n- Caller explicitly requests deep mode\n\n**How Deep Mode works — run this context-loading step BEFORE spawning any Layer 1 or Layer 2 agents:**\n\n1. Read `process\u002Fcontext\u002Fall-context.md` routing table → identify which context groups are relevant to the blast radius\n2. Load relevant context group `all-*.md` files (e.g. `container\u002Fall-container.md`, `infra\u002Fall-infra.md`, `tests\u002Fall-tests.md`, `skills\u002Fall-skills.md`) — only the groups that apply\n3. If phase program: read the latest 1–2 phase reports from inside task folders (`process\u002Ffeatures\u002F{feature}\u002Factive\u002F{slug}_{date}\u002F{slug}_REPORT_{date}.md`) or legacy `process\u002Ffeatures\u002F{feature}\u002Freports\u002F` (read-only legacy path)\n4. Read existing test files in the blast radius (gives the Layer 1 test-coverage agent real data, not guesses)\n5. Package all loaded material as a **Context Bundle** and pass it to every Layer 1 and Layer 2 agent\n\n**Quality difference in practice:**\n\n- Simple: Layer 1 infra agent infers container port assignments from plan description text\n- Deep: Layer 1 infra agent reads the container context group (process\u002Fcontext\u002Fcontainer\u002F or the repo's equivalent routing entrypoint) and knows the real port table (gateway:3000, file-server:3001, app-dev:3002, ctx-gateway:3099, browser-bridge:9377, MITM:9090\u002F9091) — can catch real port conflicts the plan missed\n\n---\n\n## Layer 1 — Four Always-On Dimension Agents\n\nAlways run all four, regardless of complexity score. These run in parallel.\n\n| Dimension        | Focus                                                                                                                       | Context to attach                                                                                            |\n| ---------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |\n| Infra\u002Fsetup fit  | Does this work with container\u002Fworker\u002Fproxy architecture? Are target file paths, port numbers, and runtime surfaces correct? | `process\u002Fcontext\u002Fall-context.md` routing → container and infra groups (follow routing table for local paths) |\n| Test coverage    | Is the verification strategy realistic given the test infra? Which tiers apply (fully-automated \u002F hybrid \u002F agent-probe)?    | `process\u002Fcontext\u002Ftests\u002Fall-tests.md`                                                                         |\n| Breaking changes | Identify API contracts, schemas, auth flows, or public contract changes. Are downstream consumers listed and safe?          | Plan's Public Contracts and Blast Radius sections                                                            |\n| Security surface | Quick STRIDE\u002FOWASP scan. Does the plan touch auth, billing, data, secrets, or trust boundaries?                             | `ag-security` skill context                                                                                  |\n\n**Note:** the security surface dimension INVOKES the `ag-security` skill — do not absorb `ag-security`'s logic here.\n\n### Per-Agent Output Format\n\n```\nDimension: [name]\nStatus: PASS | CONCERN | FAIL\nFindings:\n- [finding 1]\n- [finding 2]\nConfidence: HIGH | MEDIUM | LOW\nNotes: [optional context]\n```\n\n---\n\n## Layer 2 — Per-Section Feasibility Agents\n\nOne agent per plan section or phase. These run in parallel with each other (and may overlap with Layer 1 in time, but Layer 2 results are presented after Layer 1 results are collected).\n\nEach Layer 2 agent must answer four questions — not just \"are edit targets findable?\":\n\n1. **Mechanical feasibility** — Are the edit target strings present and uniquely matchable in the named files? Can the described create\u002Fwrite steps be executed without collision?\n2. **Plan gaps** — What is this section missing that it should include? Are there adjacent files or behaviors that should be updated but are not listed?\n3. **Conflicts** — Does anything in this section contradict current file state, other plan sections, or repo conventions?\n4. **Risk** — What is the single highest-risk edit in this section and how should the execute-agent sequence or mitigate it?\n\n### Per-Agent Output Format\n\n```\nSection: [section name or phase number]\nStatus: PASS | CONCERN | FAIL\nMechanical feasibility: [verdict + evidence]\nGaps found: [list or \"none\"]\nConflicts found: [list or \"none\"]\nHighest-risk edit + mitigation: [description]\n```\n\n**Warning:** A Layer 2 agent that only confirms edit targets are findable without assessing gaps and conflicts is incomplete and must be re-run with the full four-question prompt.\n\n### [V2-PROBE] Feasibility Probe Emission Rule\n\nWhen answering the 4 questions above, if a plan section depends on an **untested runtime\u002Fsystem behavior** (network\u002Fprotocol\u002Fruntime\u002Fthird-party response shape) that cannot be verified by reading source files, the Layer 2 agent MUST:\n\n1. Emit `VC-FEASIBILITY-PROBE-NEEDED: [hypothesis] — cost-class: [class]` and halt.\n2. NOT produce the standard per-agent output format.\n3. NOT attempt to reason about the untested behavior as if it were mechanical.\n\n**Mechanical checks (NO probe):** edit targets findable by Grep, file exists, schema field present, export names matchable, port in the container table, config key present in env.ts.\n\nExamples of mechanical checks (NO probe): \"does `src\u002Fenv.ts` export a `\u003CSERVICE>_JWT_SECRET` field?\" → read the file; \"does the container table list port 3000 for the gateway service?\" → read the table.\n\n**Probe candidates (emit + halt):** any behavior that requires a running system, live network call, or in-container exec to verify.\n\nExamples of probe candidates: \"does the gateway forward the X-Custom-Routing header to the upstream provider at runtime?\", \"does the container proxy honor the `allow-list` config field when injecting platform keys?\", \"does the OpenRouter API return `pricing` as a string or a number?\".\n\n**Note:** For each CONCERN found, INVOKE `ag-scenario`. For high-risk flagged concerns, INVOKE `ag-predict`.\n\n---\n\n## V3 Synthesis Rules\n\nThe ag-validate-agent (or orchestrator) synthesizes all Layer 1 and Layer 2 outputs:\n\n1. Collect all dimension and section verdicts.\n2. List all FAILs prominently — any FAIL from any agent must be surfaced.\n3. List all CONCERNs grouped by dimension.\n4. Note contradictions between agents explicitly; do not resolve them silently.\n5. Compute the net gate status:\n   - Any FAIL → gate is BLOCKED (unless user explicitly converts to CONDITIONAL)\n   - One or more CONCERNs, no FAILs → gate is CONDITIONAL (if user accepts) or re-runs\n   - No FAILs, no CONCERNs → gate is PASS\n6. Select test gates per the Test Tier Waterfall section.\n7. Confirm or update the parallel strategy recommendation based on synthesized findings.\n\n**Note:** Invoke `ag-sequential-thinking` at this synthesis step for contradiction ranking.\n\n---\n\n## Net Gate Derivation Output Format\n\nPresent this exact table format after synthesis:\n\n### Layer 1 dimensions\n\n| Layer 1 dimensions | Status                |\n| ------------------ | --------------------- |\n| Infra fit          | PASS \u002F CONCERN \u002F FAIL |\n| Test coverage      | PASS \u002F CONCERN \u002F FAIL |\n| Breaking changes   | PASS \u002F CONCERN \u002F FAIL |\n| Security surface   | PASS \u002F CONCERN \u002F FAIL |\n\n### Layer 2 sections\n\n| Layer 2 sections   | Status                |\n| ------------------ | --------------------- |\n| Section A — [name] | PASS \u002F CONCERN \u002F FAIL |\n| Section B — [name] | PASS \u002F CONCERN \u002F FAIL |\n| Section N — [name] | PASS \u002F CONCERN \u002F FAIL |\n\n**Totals: [N] FAILs \u002F [N] CONCERNs \u002F [N] PASSes**\n\n**→ Net Gate: [PASS \u002F CONDITIONAL \u002F BLOCKED]**\n\nDecision rules:\n\n- **PASS:** 0 FAILs, 0 CONCERNs. All plan fixes applied. Proceed to EXECUTE.\n- **CONDITIONAL:** 0 FAILs, [N] CONCERNs. [N] fixed in plan, [N] as execute-agent instructions, [N] as known-gaps. Proceed to EXECUTE with gaps on record.\n- **BLOCKED:** [N] unresolved FAILs. [List each.] Return to PLAN — do not route to EXECUTE until each FAIL is resolved or explicitly converted to CONDITIONAL by user.\n\n---\n\n## Findings Output Format\n\nUse this table format for each dimension's findings (Section I of the V4 menu):\n\n| Finding               | Severity       | Proposed fix                                                                   |\n| --------------------- | -------------- | ------------------------------------------------------------------------------ |\n| [Finding description] | CONCERN \u002F FAIL | [Proposed fix — apply to plan, execute-agent instruction, or backlog artifact] |\n| [Finding description] | ✅ PASS        | —                                                                              |\n\nShow PASS findings as `✅ PASS` with `—` in the proposed fix column.\n\n---\n\n## Section IV Output Format\n\n### Proposed Plan Updates\n\nShow the summary below to the user before they approve EXECUTE (before gate V5). These changes are applied to the plan file when the user accepts.\n\n| #   | What changes                                              | Where in plan                          | Why                                                |\n| --- | --------------------------------------------------------- | -------------------------------------- | -------------------------------------------------- |\n| P1  | [e.g. Add route registration step to Section A checklist] | [Section A — Implementation Checklist] | [Gap found: route not reachable without this step] |\n| P2  | [e.g. Correct blast radius: add downstream consumers]     | [Blast Radius section]                 | [Breaking-changes agent found unlisted consumers]  |\n| PN  | [...]                                                     | [...]                                  | [...]                                              |\n\n### Execute-Agent Instructions\n\nConcerns that cannot be fixed in plan text — written to the validate-contract for execute-agent to follow:\n\n| #   | Instruction                                                                                                                                         | Trigger condition |\n| --- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |\n| E1  | [e.g. Confirm exact file path before writing Section A. If path differs: update edit target, do NOT skip. Document corrected path in phase report.] | Section A entry   |\n| E2  | [e.g. Container change requires image rebuild. Use docker:build + container recreate via API lifecycle. Never docker cp.]                           | Section D entry   |\n| EN  | [...]                                                                                                                                               | [...]             |\n\n### Backlog Artifacts\n\n| Artifact                                         | Location                                        | What it tracks                                          |\n| ------------------------------------------------ | ----------------------------------------------- | ------------------------------------------------------- |\n| [e.g. test-envelope-regression_NOTE_03-06-26.md] | [process\u002Ffeatures\u002Fdevelopment-process\u002Fbacklog\u002F] | [Envelope regression test against downstream consumers] |\n| [...]                                            | [...]                                           | [...]                                                   |\n\n---\n\n## \u002Fgoal Block Output\n\nAfter the validate-contract is written to the plan file (V6), the skill stores the \u002Fgoal block.\n\n**Single plan:** derive the \u002Fgoal block from plan content (SESSION GOAL, charter, autonomy rules, hard stops, next phase, contract summary, execute start command). Write it to the plan file under a new `## Autonomous Goal Block` section.\n\n**Multi-phase program:** the \u002Fgoal already exists in the umbrella `## Stable Program Goal`. Do NOT rewrite it — only verify it is current and points to the umbrella path.\n\nThe \u002Fgoal block must include:\n\n- SESSION GOAL\n- Autonomy rules\n- Hard stops\n- Next phase\n- Contract summary\n- Execute start command\n\n**Multi-phase program rule:** If operating within a phase program (umbrella plan exists), emit the \u002Fgoal block update automatically without asking — do not prompt the user.\n\n**Single-plan rule:** Store the \u002Fgoal block during V6. Whether it is printed for copy-paste is decided by the validate-agent's single V5 gate option (`Accept` vs `Accept + print \u002Fgoal`). This skill does not open an extra prompt or separate user round-trip.\n\n\u002Fgoal must be fully copy-pastable (plain text block, no special formatting, under 4000 chars).\n\n**V5 during \u002Fgoal autonomous execution:** agent self-decides (CONDITIONAL → proceed, BLOCKED → backlog + proceed to next non-blocked phase). Skip any print ask — user is not present.\n","# ag-validate-findings\n\n## When to Apply\n\nUse this skill when working with ag-validate-findings workflows, tasks, or system specifications.\n\n## How to Use\n\nRefer to the workflow instructions and command references detailed below.\n\n> **Output style:** Follow `process\u002Fdevelopment-protocols\u002Fcommunication-standards.md` — answer-first, plain language, no unexplained jargon, TL;DR on long responses.\n\nDefines the role specs, prompts, and output schemas for the two-layer VALIDATE fan-out (a parallel check across 4 dimensions + per-section feasibility probes). Produces a net gate verdict (PASS \u002F CONDITIONAL \u002F BLOCKED) and all the inputs needed to write the validate-contract — the written checklist that gates EXECUTE.\n\n---\n\n## References\n\n- `references\u002Fexample-validate-output.md` — full V4 menu + validate-contract template; calibrate output format against this file\n\n---\n\n## When To Invoke\n\n- VALIDATE V2–V3: invoked by `ag-validate-agent` after V1 pre-check passes\n- Post-execute review in UPDATE PROCESS when re-validation of a plan is needed\n\n---\n\n## Strategy Boundary\n\nThis skill is **STRATEGY-AGNOSTIC**. It defines the role specs, prompts, and output schemas for each dimension\u002Fsection agent. It does NOT determine how those agents are executed (Workflow vs parallel Agent tool vs ag-team).\n\nThe execution method is determined by `ag-agent-strategy-compare`, which must be invoked BEFORE `ag-validate-findings` is called. `ag-validate-findings` outputs agent role definitions; the caller executes them using the recommended strategy.\n\n---\n\n## Mode Selection\n\nChoose before spawning any agents. Pass the selected mode to all Layer 1 and Layer 2 agents in their prompt context.\n\n### Simple Mode (default)\n\nRuns the Layer 1 + Layer 2 fan-out using context available in the current conversation. Validation agents derive context from the plan file and what was passed in the prompt.\n\n**Appropriate when:**\n\n- Plan is self-contained (all context needed is in the plan text)\n- Context is fresh in the current conversation window\n- Blast radius is clear and confined to a single domain\n- No container\u002Finfra\u002Fworker lifecycle surfaces are touched\n- Fewer than 5 blast-radius packages\n\n### Deep Mode\n\nTrigger when **any one** of the following is true:\n\n- Plan blast radius touches container, infra, or worker lifecycle\n- Plan has 5+ blast-radius packages\n- Plan is a phase in a multi-phase program (prior phase outputs must be loaded)\n- Caller explicitly requests deep mode\n\n**How Deep Mode works — run this context-loading step BEFORE spawning any Layer 1 or Layer 2 agents:**\n\n1. Read `process\u002Fcontext\u002Fall-context.md` routing table → identify which context groups are relevant to the blast radius\n2. Load relevant context group `all-*.md` files (e.g. `container\u002Fall-container.md`, `infra\u002Fall-infra.md`, `tests\u002Fall-tests.md`, `skills\u002Fall-skills.md`) — only the groups that apply\n3. If phase program: read the latest 1–2 phase reports from inside task folders (`process\u002Ffeatures\u002F{feature}\u002Factive\u002F{slug}_{date}\u002F{slug}_REPORT_{date}.md`) or legacy `process\u002Ffeatures\u002F{feature}\u002Freports\u002F` (read-only legacy path)\n4. Read existing test files in the blast radius (gives the Layer 1 test-coverage agent real data, not guesses)\n5. Package all loaded material as a **Context Bundle** and pass it to every Layer 1 and Layer 2 agent\n\n**Quality difference in practice:**\n\n- Simple: Layer 1 infra agent infers container port assignments from plan description text\n- Deep: Layer 1 infra agent reads the container context group (process\u002Fcontext\u002Fcontainer\u002F or the repo's equivalent routing entrypoint) and knows the real port table (gateway:3000, file-server:3001, app-dev:3002, ctx-gateway:3099, browser-bridge:9377, MITM:9090\u002F9091) — can catch real port conflicts the plan missed\n\n---\n\n## Layer 1 — Four Always-On Dimension Agents\n\nAlways run all four, regardless of complexity score. These run in parallel.\n\n| Dimension        | Focus                                                                                                                       | Context to attach                                                                                            |\n| ---------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |\n| Infra\u002Fsetup fit  | Does this work with container\u002Fworker\u002Fproxy architecture? Are target file paths, port numbers, and runtime surfaces correct? | `process\u002Fcontext\u002Fall-context.md` routing → container and infra groups (follow routing table for local paths) |\n| Test coverage    | Is the verification strategy realistic given the test infra? Which tiers apply (fully-automated \u002F hybrid \u002F agent-probe)?    | `process\u002Fcontext\u002Ftests\u002Fall-tests.md`                                                                         |\n| Breaking changes | Identify API contracts, schemas, auth flows, or public contract changes. Are downstream consumers listed and safe?          | Plan's Public Contracts and Blast Radius sections                                                            |\n| Security surface | Quick STRIDE\u002FOWASP scan. Does the plan touch auth, billing, data, secrets, or trust boundaries?                             | `ag-security` skill context                                                                                  |\n\n**Note:** the security surface dimension INVOKES the `ag-security` skill — do not absorb `ag-security`'s logic here.\n\n### Per-Agent Output Format\n\n```\nDimension: [name]\nStatus: PASS | CONCERN | FAIL\nFindings:\n- [finding 1]\n- [finding 2]\nConfidence: HIGH | MEDIUM | LOW\nNotes: [optional context]\n```\n\n---\n\n## Layer 2 — Per-Section Feasibility Agents\n\nOne agent per plan section or phase. These run in parallel with each other (and may overlap with Layer 1 in time, but Layer 2 results are presented after Layer 1 results are collected).\n\nEach Layer 2 agent must answer four questions — not just \"are edit targets findable?\":\n\n1. **Mechanical feasibility** — Are the edit target strings present and uniquely matchable in the named files? Can the described create\u002Fwrite steps be executed without collision?\n2. **Plan gaps** — What is this section missing that it should include? Are there adjacent files or behaviors that should be updated but are not listed?\n3. **Conflicts** — Does anything in this section contradict current file state, other plan sections, or repo conventions?\n4. **Risk** — What is the single highest-risk edit in this section and how should the execute-agent sequence or mitigate it?\n\n### Per-Agent Output Format\n\n```\nSection: [section name or phase number]\nStatus: PASS | CONCERN | FAIL\nMechanical feasibility: [verdict + evidence]\nGaps found: [list or \"none\"]\nConflicts found: [list or \"none\"]\nHighest-risk edit + mitigation: [description]\n```\n\n**Warning:** A Layer 2 agent that only confirms edit targets are findable without assessing gaps and conflicts is incomplete and must be re-run with the full four-question prompt.\n\n### [V2-PROBE] Feasibility Probe Emission Rule\n\nWhen answering the 4 questions above, if a plan section depends on an **untested runtime\u002Fsystem behavior** (network\u002Fprotocol\u002Fruntime\u002Fthird-party response shape) that cannot be verified by reading source files, the Layer 2 agent MUST:\n\n1. Emit `VC-FEASIBILITY-PROBE-NEEDED: [hypothesis] — cost-class: [class]` and halt.\n2. NOT produce the standard per-agent output format.\n3. NOT attempt to reason about the untested behavior as if it were mechanical.\n\n**Mechanical checks (NO probe):** edit targets findable by Grep, file exists, schema field present, export names matchable, port in the container table, config key present in env.ts.\n\nExamples of mechanical checks (NO probe): \"does `src\u002Fenv.ts` export a `\u003CSERVICE>_JWT_SECRET` field?\" → read the file; \"does the container table list port 3000 for the gateway service?\" → read the table.\n\n**Probe candidates (emit + halt):** any behavior that requires a running system, live network call, or in-container exec to verify.\n\nExamples of probe candidates: \"does the gateway forward the X-Custom-Routing header to the upstream provider at runtime?\", \"does the container proxy honor the `allow-list` config field when injecting platform keys?\", \"does the OpenRouter API return `pricing` as a string or a number?\".\n\n**Note:** For each CONCERN found, INVOKE `ag-scenario`. For high-risk flagged concerns, INVOKE `ag-predict`.\n\n---\n\n## V3 Synthesis Rules\n\nThe ag-validate-agent (or orchestrator) synthesizes all Layer 1 and Layer 2 outputs:\n\n1. Collect all dimension and section verdicts.\n2. List all FAILs prominently — any FAIL from any agent must be surfaced.\n3. List all CONCERNs grouped by dimension.\n4. Note contradictions between agents explicitly; do not resolve them silently.\n5. Compute the net gate status:\n   - Any FAIL → gate is BLOCKED (unless user explicitly converts to CONDITIONAL)\n   - One or more CONCERNs, no FAILs → gate is CONDITIONAL (if user accepts) or re-runs\n   - No FAILs, no CONCERNs → gate is PASS\n6. Select test gates per the Test Tier Waterfall section.\n7. Confirm or update the parallel strategy recommendation based on synthesized findings.\n\n**Note:** Invoke `ag-sequential-thinking` at this synthesis step for contradiction ranking.\n\n---\n\n## Net Gate Derivation Output Format\n\nPresent this exact table format after synthesis:\n\n### Layer 1 dimensions\n\n| Layer 1 dimensions | Status                |\n| ------------------ | --------------------- |\n| Infra fit          | PASS \u002F CONCERN \u002F FAIL |\n| Test coverage      | PASS \u002F CONCERN \u002F FAIL |\n| Breaking changes   | PASS \u002F CONCERN \u002F FAIL |\n| Security surface   | PASS \u002F CONCERN \u002F FAIL |\n\n### Layer 2 sections\n\n| Layer 2 sections   | Status                |\n| ------------------ | --------------------- |\n| Section A — [name] | PASS \u002F CONCERN \u002F FAIL |\n| Section B — [name] | PASS \u002F CONCERN \u002F FAIL |\n| Section N — [name] | PASS \u002F CONCERN \u002F FAIL |\n\n**Totals: [N] FAILs \u002F [N] CONCERNs \u002F [N] PASSes**\n\n**→ Net Gate: [PASS \u002F CONDITIONAL \u002F BLOCKED]**\n\nDecision rules:\n\n- **PASS:** 0 FAILs, 0 CONCERNs. All plan fixes applied. Proceed to EXECUTE.\n- **CONDITIONAL:** 0 FAILs, [N] CONCERNs. [N] fixed in plan, [N] as execute-agent instructions, [N] as known-gaps. Proceed to EXECUTE with gaps on record.\n- **BLOCKED:** [N] unresolved FAILs. [List each.] Return to PLAN — do not route to EXECUTE until each FAIL is resolved or explicitly converted to CONDITIONAL by user.\n\n---\n\n## Findings Output Format\n\nUse this table format for each dimension's findings (Section I of the V4 menu):\n\n| Finding               | Severity       | Proposed fix                                                                   |\n| --------------------- | -------------- | ------------------------------------------------------------------------------ |\n| [Finding description] | CONCERN \u002F FAIL | [Proposed fix — apply to plan, execute-agent instruction, or backlog artifact] |\n| [Finding description] | ✅ PASS        | —                                                                              |\n\nShow PASS findings as `✅ PASS` with `—` in the proposed fix column.\n\n---\n\n## Section IV Output Format\n\n### Proposed Plan Updates\n\nShow the summary below to the user before they approve EXECUTE (before gate V5). These changes are applied to the plan file when the user accepts.\n\n| #   | What changes                                              | Where in plan                          | Why                                                |\n| --- | --------------------------------------------------------- | -------------------------------------- | -------------------------------------------------- |\n| P1  | [e.g. Add route registration step to Section A checklist] | [Section A — Implementation Checklist] | [Gap found: route not reachable without this step] |\n| P2  | [e.g. Correct blast radius: add downstream consumers]     | [Blast Radius section]                 | [Breaking-changes agent found unlisted consumers]  |\n| PN  | [...]                                                     | [...]                                  | [...]                                              |\n\n### Execute-Agent Instructions\n\nConcerns that cannot be fixed in plan text — written to the validate-contract for execute-agent to follow:\n\n| #   | Instruction                                                                                                                                         | Trigger condition |\n| --- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |\n| E1  | [e.g. Confirm exact file path before writing Section A. If path differs: update edit target, do NOT skip. Document corrected path in phase report.] | Section A entry   |\n| E2  | [e.g. Container change requires image rebuild. Use docker:build + container recreate via API lifecycle. Never docker cp.]                           | Section D entry   |\n| EN  | [...]                                                                                                                                               | [...]             |\n\n### Backlog Artifacts\n\n| Artifact                                         | Location                                        | What it tracks                                          |\n| ------------------------------------------------ | ----------------------------------------------- | ------------------------------------------------------- |\n| [e.g. test-envelope-regression_NOTE_03-06-26.md] | [process\u002Ffeatures\u002Fdevelopment-process\u002Fbacklog\u002F] | [Envelope regression test against downstream consumers] |\n| [...]                                            | [...]                                           | [...]                                                   |\n\n---\n\n## \u002Fgoal Block Output\n\nAfter the validate-contract is written to the plan file (V6), the skill stores the \u002Fgoal block.\n\n**Single plan:** derive the \u002Fgoal block from plan content (SESSION GOAL, charter, autonomy rules, hard stops, next phase, contract summary, execute start command). Write it to the plan file under a new `## Autonomous Goal Block` section.\n\n**Multi-phase program:** the \u002Fgoal already exists in the umbrella `## Stable Program Goal`. Do NOT rewrite it — only verify it is current and points to the umbrella path.\n\nThe \u002Fgoal block must include:\n\n- SESSION GOAL\n- Autonomy rules\n- Hard stops\n- Next phase\n- Contract summary\n- Execute start command\n\n**Multi-phase program rule:** If operating within a phase program (umbrella plan exists), emit the \u002Fgoal block update automatically without asking — do not prompt the user.\n\n**Single-plan rule:** Store the \u002Fgoal block during V6. Whether it is printed for copy-paste is decided by the validate-agent's single V5 gate option (`Accept` vs `Accept + print \u002Fgoal`). This skill does not open an extra prompt or separate user round-trip.\n\n\u002Fgoal must be fully copy-pastable (plain text block, no special formatting, under 4000 chars).\n\n**V5 during \u002Fgoal autonomous execution:** agent self-decides (CONDITIONAL → proceed, BLOCKED → backlog + proceed to next non-blocked phase). Skip any print ask — user is not present.\n",{"name":5,"layer":24,"description":7,"trigger_keywords":25},"contract","validate findings, layer 1 dimensions, layer 2 feasibility, net gate, validate fan-out","main","1ef0dcd00fe806a8dc4e0b7173b9db967c3ab274",".claude\u002Fskills\u002Fag-validate-findings","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit","https:\u002F\u002Fgithub.com\u002Fngxccc","https:\u002F\u002Fngxccc.github.io","Make it work, make it right, make it fast.","2026-08-02 20:59:07",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add ngxccc\u002Fagent-skills-kit --skill ag-validate-findings",{"tool":40,"command":41},"bunx","bunx skills add ngxccc\u002Fagent-skills-kit --skill ag-validate-findings",{"tool":43,"command":44},"pnpm","pnpm dlx skills add ngxccc\u002Fagent-skills-kit --skill ag-validate-findings","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fag-validate-findings\u002FSKILL.md",true,[48,54,60,64],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Fexample-validate-output.md","REFERENCE","参考文档",25293,"https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fag-validate-findings\u002Freferences\u002Fexample-validate-output.md",{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"scripts\u002Ffixtures\u002Fvalidate-findings-output\u002Ffail.md","SCRIPT","脚本",466,"https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fag-validate-findings\u002Fscripts\u002Ffixtures\u002Fvalidate-findings-output\u002Ffail.md",{"path":61,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":62,"sourceHtmlUrl":63},"scripts\u002Ffixtures\u002Fvalidate-findings-output\u002Fpass.md",456,"https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fag-validate-findings\u002Fscripts\u002Ffixtures\u002Fvalidate-findings-output\u002Fpass.md",{"path":65,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":66,"sourceHtmlUrl":67},"scripts\u002Fvalidate-findings-output.mjs",2309,"https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fag-validate-findings\u002Fscripts\u002Fvalidate-findings-output.mjs",[69,76,83,90,97,104],{"skillNo":70,"name":71,"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":19},"01M76W3C8X6Q5DS0364KQT7W7A","zustand","Rules and standards for state management using Zustand in React and Next.js. Use when implementing client-side stores, persistence with localStorage, or preventing SSR hydration mismatch.","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002Fskills\u002F.curated\u002Fzustand\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M76W39FJGES309VAH7SFWA9Y","zod","Zod v4 schema validation best practices. Use when defining schemas, utilizing safeParse, or customizing error messages.","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002Fskills\u002F.curated\u002Fzod\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M76W36HTYA4BR5FKCWMX1RFR","upstash-ratelimit","Rules, standards, and references for rate limiting in serverless environments using Upstash Ratelimit. Use when implementing rate limiting, configuring Upstash Redis, or handling request blocking.","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002Fskills\u002F.curated\u002Fupstash-ratelimit\u002FSKILL.md",[],[],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M76W32H4PS01WFRS7FNPK2G1","ui-design","UI\u002FUX and frontend design best practices guidelines (formerly frontend-design). This skill should be used when writing, reviewing, or designing frontend code to ensure accessibility, performance, and usability. Triggers on tasks involving HTML structure, CSS styling, responsive layouts, form design, animations, or accessibility improvements.","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002Fskills\u002F.curated\u002Fui-design\u002FSKILL.md",[],[],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":19},"01M76W2YAP6RK8N0EVWFG54VD7","typescript","TypeScript performance, tsconfig, type errors, async patterns — triggered when the user asks to \"optimize TypeScript performance\", \"speed up tsc compilation\", \"configure tsconfig.json\", \"fix type errors\", \"improve async patterns\", or encounters TS errors (TS2322, TS2339, \"is not assignable to\"). Also triggers on .ts, .tsx, .d.ts file work involving type definitions, module organization, or memory management. Does NOT cover TypeScript basics, framework-specific patterns, or testing.","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002Fskills\u002F.curated\u002Ftypescript\u002FSKILL.md",[],[],{"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":19},"01M76W2RMAZNNJQ2HECH3X6ZSH","typescript-refactor","TypeScript and TSX refactoring and modernization guidelines from a principal specialist perspective, current to TypeScript 6.0 and React 19. This skill should be used when refactoring, reviewing, or modernizing TypeScript or React\u002FTSX code for type safety, compiler performance, and idiomatic patterns. Triggers on tasks involving type architecture, narrowing, generics, discriminated unions, error handling, React component and hook typing, or migration to modern TypeScript features (satisfies, using, const type parameters, inferred type predicates, isolatedDeclarations, erasable syntax, import attributes).","https:\u002F\u002Fgithub.com\u002Fngxccc\u002Fagent-skills-kit\u002Fblob\u002Fmain\u002Fskills\u002F.curated\u002Ftypescript-refactor\u002FSKILL.md",[],[]]