project-tiny-context-harness 0.2.69 → 0.2.71

package/assets/skills/superpowers-long-task/SKILL.md

@@ -1,256 +1,372 @@
----
-name: superpowers-long-task
-description: Use when directly invoked for Superpowers long-running task target prompt preparation.
----
-
-# Superpowers Long Task Skill
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `superpowers-long-task` Skill directly in a consumer project.
-
-This is Tiny Context's adapter for feeding a complete acceptance packet into the external Superpowers workflow. It is not a Superpowers official schema and 不是 Superpowers 官方 schema. It only makes the target-mode prompt explicit enough that the official Superpowers skills can do their intended work without losing Tiny Context acceptance authority.
-
-## Purpose
-
-Consumes a complete acceptance packet and emits a paste-ready Superpowers target-mode prompt. The input packet normally comes from `/normal-long-task`.
-
-Use this Skill only after the implementation/source plan and full acceptance checklist already exist or are pasted in full. Do not generate, derive, rewrite, strengthen, or repair the full checklist in this Skill. If the checklist is incomplete, stop and send the user back to `/normal-long-task` or ask for the missing fields.
-
-## Direct Invocation
-
-Use this Skill through explicit invocation:
-
-```text
-/superpowers-long-task
-```
-
-Do not rely on broad automatic keyword routing. Use `/normal-long-task` first when the implementation/source plan and full acceptance checklist do not already exist.
-
-## Use Cases
-
-Use this Skill when a complete plan/checklist packet needs:
-
-- Superpowers target-mode prompt.
-- Superpowers goal-mode prompt.
-- Superpowers 目标模式文本.
-- Superpowers-compatible Codex target prompt.
-- Maximum official Superpowers workflow value from an existing acceptance checklist.
-
-Do not trigger merely because a plan mentions TDD or subagents. The user must ask for a Superpowers target/goal prompt or equivalent execution adapter.
-
-## Required Input Packet
-
-The input must fully expose these fields:
-
-- Original requirement source or original plan summary.
-- implementation/source plan path or pasted text.
-- full acceptance checklist path or pasted text.
-- local audit path, normally `tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md`.
-- relevant Context that must be read before execution.
-- required tests / core paths.
-- Evidence Layer Separation rules.
-- Invalid Evidence Rules.
-- Completion State Machine rules.
-- UI-Facing Gate rules when any AC touches UI.
-- hard blockers or an explicit no-blocker statement.
-
-If any of these are missing required fields, stop. Do not generate the Superpowers target-mode prompt. Report the missing fields and say whether they belong in the development plan, full checklist, local audit rule, blocker section or Context reference.
-
-## Source Roles
-
-- Original requirement source prevents implementation/source plan or checklist shrinkage.
-- implementation/source plan is execution direction, not proof.
-- full acceptance checklist is the highest-priority completion standard.
-- local audit records progress, evidence, blockers and invalidating evidence only; it is not proof.
-- relevant Context remains the durable repo intent and boundary source.
-- required tests / core paths bind AC gaps to executable verification.
-
-Do not let a compact target prompt override the full checklist. The compact prompt is direction, priority and recovery navigation only. The full checklist wins conflicts.
-
-## Evidence Layer Separation
-
-Keep these layers separate in the prompt when relevant:
-
-- code implemented.
-- runtime configured.
-- runtime exercised.
-- artifact generated.
-- artifact accepted by validator.
-- API/UI reflected or API/UI reflects accepted evidence.
-- browser or user path verified.
-- final gate/check command passed.
-
-An AC cannot be complete when its required layer is missing.
-
-## Invalid Evidence Rules
-
-The prompt must reject false proof:
-
-- viewmodel-only does not prove a real page.
-- unit test does not prove real API behavior or latency.
-- artifact exists does not prove artifact accepted by validator.
-- old result does not prove current state.
-- build passes does not prove product acceptance.
-- stale, partial, smoke-only, dry-run or research evidence cannot prove full completion.
-- unresolved API/UI/data/test contradictions invalidate completion claims.
-
-## Completion State Machine
-
-Every AC starts as `unknown / not_run`.
-
-Only fresh required evidence can mark an AC complete.
-
-Any fresh browser / API / runtime / data / test contradiction must downgrade the affected AC and overall status and must be recorded as invalidating evidence. Do not preserve a previous complete status after contradictory fresh evidence appears.
-
-## UI-Facing Gate
-
-For UI-facing acceptance, the executor must open the real page path and confirm the user-visible state matches the AC. component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
-
-## Autonomous Progress Protocol
-
-The Superpowers target prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
-
-The Superpowers target prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
-
-Pause only for locally unsatisfiable hard blockers such as missing accounts, credentials, production access, paid services, legal/security approval, user-only browser sessions or sensitive fields the executor cannot access safely. When pausing, give the minimum user action list: exact page, system, command or owner to open/contact; exact field or value location; how to redact or avoid sending sensitive values; what the executor will do immediately after receiving the input.
-
-## Official Superpowers Binding
-
-Bind the target prompt to the official Skill names and their documented roles:
-
-- If the implementation/source plan is not bite-sized enough, use `superpowers:writing-plans`.
-- Prefer `superpowers:subagent-driven-development` when subagents are available.
-- Use `superpowers:executing-plans` when executing a written plan without the same-session subagent workflow.
-- AC gap -> TDD: every behavior acceptance gap uses `superpowers:test-driven-development` to write a failing test, observe failure, then implement minimally.
-- Before any completion claim, use `superpowers:verification-before-completion` against the full checklist and fresh evidence.
-- review / finish cannot override the full checklist; if the checklist is unsatisfied, continue implementation or report blockers.
-
-If Superpowers is missing, install it through the current platform's official Superpowers installation path. If installation is blocked by permissions, network or platform limits, record the blocker in local audit and do not count it as complete.
-
-## Local Audit Requirements
-
-The Superpowers target prompt must require the future executor to update local audit after each round with:
-
-- overall status.
-- each AC status and current evidence.
-- command/result/time and failure reason.
-- required test command/result/failure.
-- artifact or evidence paths.
-- blockers, missing evidence and acceptance impact.
-- deferred or narrowed scope.
-- stale, partial, smoke, dry-run, research or other invalid evidence.
-
-The local audit is not Context, not proof, not a global task manager, and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`.
-
-## Prompt Generation Rules
-
-- The prompt must visibly output `Superpowers 输入包` for Chinese prompts or `Superpowers input packet` for English prompts.
-- The prompt must visibly output `Superpowers 执行绑定` for Chinese prompts or `Superpowers execution binding` for English prompts.
-- The prompt must identify plan path, full checklist path and local audit path at the top.
-- The prompt must state that the full checklist is the complete acceptance standard and wins conflicts.
-- The prompt must preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking complete.
-- The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries and must include the minimum user action list for locally unsatisfiable hard blockers.
-- The prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
-- The prompt must include the resource lifecycle line: `可多开agent，agent名额不够了就关掉不用的。` or `You may use multiple agents; if agent slots run low, close idle or unnecessary agents.`
-- The prompt must fit 3850 characters including line breaks.
-- Do not include explanatory preface inside the generated prompt.
-
-Recommended compact Chinese prompt shape:
-
-```text
-实施计划: tmp/ty-context/plan-acceptance/<plan-slug>.md（source/implementation plan，非验收证明）
-完整验收清单: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md（该文件是完整验收标准，验收以这个为准。完成前必须逐项检查，不满足则继续实现。）
-执行审计: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md（临时 progress state，非 Context/proof）
-可多开agent，agent名额不够了就关掉不用的。
-本摘要只负责 direction/priority/recovery navigation；允许与完整 checklist 重叠，冲突时以完整 checklist 为准。This is not a Superpowers official schema / 不是 Superpowers 官方 schema。
-Superpowers 输入包：
-- 原始需求源/原始方案摘要：防止计划/checklist 缩水
-- 实施计划：执行方向；不够 bite-sized 时用 superpowers:writing-plans
-- 完整验收清单：最高优先级完成标准；completion gate 以它为准
-- local audit：只记 progress/evidence/blocker/invalidating evidence，非 proof
-- relevant Context：执行前读取；冲突按完整 checklist 和 Context 规则处理
-- required tests / core paths：把每个 AC gap 绑定到测试、API/UI/runtime/browser 验证
-
-自主推进：在当前平台/仓库/工具/用户已授权权限内推进到所有 agent 能安全完成的事项；不把可自助发现/执行/验证的事交给用户。
-权限策略：遵循当前仓库/全局 AGENTS.md 或 agent instructions；已授权 sudo/gsudo/admin elevation 不视为用户阻塞，先尝试使用；只有提权不可用/失败/需用户系统授权时才记 blocker。
-强卡点：仅在本地无法解决的账号/凭证/真实环境/人工审批/敏感字段等阻塞时暂停；暂停时给最小用户执行清单（具体页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
-如果 Superpowers 未安装，先按当前平台 official Superpowers installation path 安装；若 installation is blocked by 权限/网络/平台限制，写入 audit，不得算完成。
-Superpowers 执行绑定：
-- 先读完整验收清单，验收以它为准
-- 计划不够可执行时，用 superpowers:writing-plans 转成 bite-sized implementation plan
-- 有 subagent 支持时优先用 superpowers:subagent-driven-development；否则用 superpowers:executing-plans
-- AC gap -> TDD：每个行为验收缺口先用 superpowers:test-driven-development write a failing test 并 observe failure，再写最小实现
-- 完成声明前用 superpowers:verification-before-completion 按完整 checklist 和 fresh evidence 做 gate
-- review / finish cannot override the full checklist；不满足则继续实现或报告 blocker
-- 每轮后更新 audit：AC status、证据、命令/结果/时间、required test command/result/failure、evidence path、blocker、deferred/narrowed scope、无效证据
-
-状态机：AC 初始 unknown / not_run；只有 fresh required evidence 才能 complete；任何 fresh browser / API / runtime / data / test contradiction 必须 downgrade the affected AC and overall status，并记录 invalidating evidence。
-UI-Facing Gate：UI 验收必须打开 real page path 且用户可见状态匹配；component / viewmodel / mock / unit test 只算辅助证据，除非完整 checklist 明确说明。
-禁止完成于：只改代码/计划、只跑部分测试、旧或部分证据、runtime 未配置/未演练、artifact 未被 validator accepted、API/UI 未 reflected、强卡点未解除、API/UI/data/test 矛盾。
-```
-
-Recommended compact English prompt shape:
-
-```text
-Plan: tmp/ty-context/plan-acceptance/<plan-slug>.md (implementation/source plan, not acceptance proof)
-Full checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (complete acceptance standard; judge against it; check every item before completion)
-Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (temporary progress state, not Context or proof)
-You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
-This summary is direction/priority/recovery only; overlap is allowed and the full checklist wins conflicts. This is not a Superpowers official schema / 不是 Superpowers 官方 schema.
-Superpowers input packet:
-- Source/original requirement: prevents plan/checklist shrinkage.
-- Plan: execution direction; if not bite-sized, use superpowers:writing-plans.
-- Full checklist: acceptance authority and completion gate.
-- Local audit: progress/evidence/blockers/invalidating evidence only; not proof.
-- Relevant Context: read before execution; resolve conflicts through checklist + Context.
-- Required tests/core paths: map AC gaps to test/API/UI/runtime/browser evidence.
-
-Autonomous progress: within current platform/repo/tool/user-authorized permissions, do everything the agent can safely do; do not hand self-service discovery/execution/verification to the user. Hard blockers: pause only for locally unsatisfiable account/credential/real-env/human-approval/sensitive-field needs; give a minimal user action list (exact page/system, field location, redaction/do-not-send values, next agent step).
-Permission policy: follow current repo/global AGENTS.md or agent instructions; authorized sudo/gsudo/admin elevation is not a user blocker, try it before pausing; pause only if elevation is unavailable, fails, or needs user/system authorization.
-If Superpowers is missing, install it through the current platform's official Superpowers installation path; if installation is blocked by permissions/network/platform, record in audit and do not count as complete.
-Superpowers execution binding:
-- Read the full checklist first; acceptance is judged against it.
-- Use superpowers:writing-plans if the plan is not executable enough.
-- Prefer superpowers:subagent-driven-development with subagents; otherwise use superpowers:executing-plans.
-- AC gap -> TDD: every behavior acceptance gap first uses superpowers:test-driven-development to write a failing test, observe failure, then implement minimally.
-- Before any completion claim, use superpowers:verification-before-completion against fresh evidence.
-- review / finish cannot override the full checklist; if unsatisfied, continue or report blockers.
-- After each round update audit: AC status, evidence, command/result/time, required test command/result/failure, evidence paths, blockers, deferred/narrowed scope, invalid evidence.
-
-State machine: ACs start unknown / not_run; only fresh required evidence can mark complete; any fresh browser / API / runtime / data / test contradiction downgrades the affected AC and overall status and is invalidating evidence.
-UI-Facing Gate: open the real page path and confirm visible state; component / viewmodel / mock / unit test evidence is auxiliary unless checklist says otherwise.
-Never complete on: code-only, plan-only, partial tests, stale/partial evidence, unconfigured/unexercised runtime, artifact not accepted by validator, API/UI not reflected, hard blockers, or API/UI/data/test contradictions.
-```
-
-Before final response, check the prompt length. If it exceeds 3850 characters, tighten wording while preserving paths, input roles, official Superpowers skill names, state machine, UI gate, blockers and invalid evidence.
-
-## Final Response Requirements
-
-When successful, return:
-
-- The implementation/source plan path.
-- The full checklist path.
-- The local audit path.
-- Whether required input was complete.
-- The paste-ready Superpowers target-mode prompt in a code block.
-
-When blocked, return:
-
-- Missing required fields.
-- Which source should provide each missing field.
-- A clear statement that no Superpowers target-mode prompt was generated.
-
-Do not claim any AC has passed unless the user explicitly asked for current completion audit and current evidence was inspected.
-
-## Forbidden Behaviors
-
-Do not generate, derive, rewrite, strengthen, or repair the full checklist.
-
-Do not execute the generated prompt.
-
-Do not mark any goal complete.
-
-Do not hide missing source files, ambiguous scope, weak evidence or blockers.
-
-Do not include business-domain logic, concrete provider names, API names, UI names, artifact schemas or one-off project details in this package-managed Skill.
+---
+name: superpowers-long-task
+description: Use when directly invoked for Superpowers long-running task target prompt preparation.
+---
+
+# Superpowers Long Task Skill
+
+## Package-Managed Boundary
+
+This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `superpowers-long-task` Skill directly in a consumer project.
+
+This is Tiny Context's adapter for feeding a recommended three-input long-task packet into the external Superpowers workflow. It is not a Superpowers official schema and 不是 Superpowers 官方 schema. It only makes the target-mode prompt explicit enough that the official Superpowers skills can do their intended work without losing Tiny Context context-delta, plan-conformance and acceptance authority.
+
+## Purpose
+
+Consumes three existing upstream inputs and emits a paste-ready Superpowers target-mode prompt:
+
+- Product / Architecture Source: original intent source for scope, product logic, surface responsibility and durable architecture intent.
+- Technical Realization Plan: the execution blueprint and plan-conformance source.
+- Acceptance Checklist: the acceptance authority and final-verdict source.
+
+Use this Skill only after all three inputs already exist or are pasted in full. Two-document compatibility is allowed only when the first document explicitly contains both Product / Architecture Source and Technical Realization Plan sections; otherwise stop for a missing Technical Realization Plan. Do not generate, derive, or infer the Technical Realization Plan. Do not generate, derive, rewrite, strengthen, or repair the full checklist in this Skill. If plan items or ACs are too vague to trace, stop and ask for the missing fields. If only generic conformance or verdict rules are missing, inject this Skill's default rules into the generated prompt.
+
+## Direct Invocation
+
+Use this Skill through explicit invocation:
+
+```text
+/superpowers-long-task
+```
+
+Do not rely on broad automatic keyword routing. `/normal-long-task` remains useful for ordinary acceptance preparation, but this Skill does not require it when the product/architecture source, technical realization plan and acceptance checklist are already supplied.
+
+## Use Cases
+
+Use this Skill when a three-input long-task packet needs:
+
+- Superpowers target-mode prompt.
+- Superpowers goal-mode prompt.
+- Superpowers 目标模式文本.
+- Superpowers-compatible Codex target prompt.
+- Superpowers execution binding with Context Delta, plan-conformance and acceptance-evidence gates.
+
+Do not trigger merely because a plan mentions TDD or subagents. The user must ask for a Superpowers target/goal prompt or equivalent execution adapter.
+
+## Required Three-Input Packet
+
+The input must fully expose these fields:
+
+- Product / Architecture Source path or pasted text.
+- original requirement source or original plan summary.
+- durable product intent when applicable: product capability, user flow, business state/rule, page/surface responsibility, information architecture, product ownership, status meaning, operation boundary or acceptance semantics.
+- durable architecture intent when applicable: module boundary, dependency direction, API/schema/data/event contract, worker/runtime/state-machine semantics, verification/deployment path or stable technical tradeoff.
+- Technical Realization Plan path or pasted text.
+- traceable plan items or sections that affect behavior.
+- expected implementation surfaces when applicable: code, API/schema, UI/page, worker/runtime, artifact, data, tests.
+- required code/API/schema/UI/worker/runtime/data/test/evidence mapping when applicable.
+- full-scope versus sample/optional boundaries.
+- explicitly non-completing shortcuts, such as local-only enhancement, old page continuing to own a moved responsibility, sampled path, plan-only work or test-only patch.
+- full acceptance checklist path or pasted text.
+- acceptance items or AC IDs.
+- required evidence and verification method per AC.
+- required tests or explicit no-test scope.
+- valid and invalid evidence rules.
+- Completion State Machine rules.
+- UI-Facing Gate rules when any AC touches UI.
+- hard blockers or an explicit no-blocker statement.
+
+If any of these are missing required fields, stop. Do not generate the Superpowers target-mode prompt. Report whether each missing field belongs in Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, blocker section or Context reference. If the user supplied only a product/architecture source plus checklist, report missing Technical Realization Plan.
+
+## Source Roles
+
+- Product / Architecture Source prevents scope shrinkage and drives Product Context Delta / architecture-intent checks; it is not the code construction plan.
+- Technical Realization Plan is the execution blueprint and the source for `plan-conformance-matrix.*`; it is not proof.
+- Acceptance Checklist is the completion authority and the source for `final-acceptance-verdict.*`.
+- local audit records progress, candidate status, evidence, blockers and invalidating evidence only; it is not proof and must not mark final completion.
+- relevant Context remains the durable repo intent and boundary source.
+- required tests / core paths bind plan and AC gaps to executable verification.
+
+Do not let a compact target prompt override the product/architecture source, technical realization plan or full checklist. The compact prompt is direction, priority and recovery navigation only. The technical realization plan controls plan conformance; the product/architecture source prevents scope shrinkage; the full checklist controls acceptance.
+
+## Context Delta Assessment
+
+The prompt must require the future executor to evaluate Context before implementation using:
+
+```text
+Product Context Delta: none|required
+Technical Context Delta: none|required
+Context Delta: none|required
+```
+
+Any required sub-delta makes overall Context Delta required. This is prompt-level workflow discipline, not a validator gate, not a machine-enforced gate, not a phase gate and not a new document chain.
+
+`Product Context Delta: required` applies when the product/architecture source changes durable product facts such as product capability, user flow, business state/rule, page or surface responsibility, main/drilldown ownership, information architecture, user-visible terminology, status meaning, operation boundary, product/domain ownership or acceptance semantics.
+
+`Technical Context Delta: required` applies when the product/architecture source or Technical Realization Plan changes durable technical facts such as API/schema/event/data contract, module ownership, dependency direction, worker/runtime/state-machine semantics, data model, persistence, scheduling, failure/retry/recovery semantics, verification/deployment/bootstrap path or stable technical tradeoff.
+
+When overall `Context Delta: required`, the executor must update the smallest owning `project_context/**` or `DESIGN.md` fact before implementation continues. Use existing roles only: `area`, `subdomain`, `contract`, `foundation`, `verification`, `deployment`, `implementation-index` and `decision-rationale`. Do not write local audit, plan-conformance matrix, final acceptance verdict, temporary plan, sampled evidence, one-off logs, raw outputs, screenshots or PR notes into Context.
+
+## Plan Conformance Gate
+
+The prompt must require the future executor to create or initialize `tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md` and `.json` before substantial implementation, then update it after each meaningful implementation slice.
+
+Each behavior-affecting Technical Realization Plan item must have a trace entry with:
+
+- plan item id and plan requirement.
+- acceptance ids covered by the plan item when applicable.
+- expected surfaces.
+- implemented paths.
+- missing paths.
+- tests.
+- runtime or artifact evidence.
+- scope assessment.
+- status.
+- drift.
+- Context fact refs when Context Delta is required.
+- For Product Surface, IA or architecture-migration items: conformance type, owner surface, required user paths, forbidden primary surfaces, real page evidence, negative surface checks and default visibility requirement.
+
+Allowed plan-conformance statuses:
+
+- `complete`
+- `partial`
+- `sampled_only`
+- `not_implemented`
+- `blocked`
+- `scope_changed_requires_user_approval`
+- `contradicted_by_current_state`
+- `out_of_scope_NA`
+
+Hard rules:
+
+- Passing tests does not imply plan conformance.
+- A sampled implementation path does not imply full plan implementation.
+- A local audit cannot narrow plan scope or mark completion.
+- Scope correction requires explicit user approval or a revised product/architecture source, Technical Realization Plan and checklist.
+- Every behavior-affecting plan section must have an implementation trace entry.
+- Product Surface, IA or architecture-migration rows cannot be complete without owner surface, required user paths, real page evidence, negative surface checks for forbidden primary surfaces and Context fact refs when Context Delta is required.
+- Any `partial`, `sampled_only`, `not_implemented`, unresolved blocker, unapproved scope change or current contradiction prevents overall done.
+
+## Acceptance Evidence Gate
+
+The prompt must require the future executor to generate `tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md` and `.json` only at the final gate, after Context Delta handling, Plan Conformance Gate and current evidence checks.
+
+Each AC verdict entry must include:
+
+- AC id or acceptance item.
+- related plan item ids when applicable.
+- status.
+- required evidence.
+- fresh evidence.
+- missing evidence.
+- contradictions.
+- decision.
+
+Allowed AC statuses:
+
+- `complete`
+- `partial`
+- `blocked`
+- `not_run`
+- `invalidated`
+- `out_of_scope_NA`
+
+Hard rules:
+
+- Final completion requires an AC-by-AC final acceptance verdict.
+- Before any completion claim, run `ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>`; failure prevents final complete and must produce partial / blocker / missing-evidence output.
+- `validate-plan-acceptance` rejects contradictory matrix/verdict JSON, weak-proof complete rows, missing cross-references and declared surface/architecture binding gaps; it checks artifact consistency and references, not product quality.
+- Current API/UI/runtime/data/test contradictions override historical passing evidence.
+- local audit, subagent summaries, final result card text, passing test logs, stale artifacts, partial smoke, dry-run or sampled paths cannot prove completion by themselves.
+- Any current contradiction downgrades the affected AC and overall status.
+- Scope narrowing in audit does not modify acceptance unless the user approved a revised source/plan/checklist.
+- `out_of_scope_NA` requires explicit reason and source reference; arbitrary prose cannot waive missing evidence.
+
+## Evidence Layer Separation
+
+Keep these layers separate in the prompt when relevant:
+
+- code implemented.
+- API/schema reflected.
+- worker/runtime path reflected.
+- UI/page reflected.
+- runtime configured.
+- runtime exercised.
+- artifact generated.
+- artifact accepted by validator.
+- API/UI reflects accepted evidence.
+- browser or user path verified.
+- final gate/check command passed.
+
+A plan item or AC cannot be complete when its required layer is missing.
+
+## Invalid Evidence Rules
+
+The prompt must reject false proof:
+
+- viewmodel-only does not prove a real page.
+- unit test does not prove real API behavior or latency.
+- artifact exists does not prove artifact accepted by validator.
+- old result does not prove current state.
+- build passes does not prove product acceptance.
+- stale, partial, smoke-only, dry-run, sampled-only or research evidence cannot prove full completion.
+- unresolved API/UI/data/runtime/test contradictions invalidate completion claims.
+
+## Completion State Machine
+
+Every plan item and AC starts as `unknown / not_run`.
+
+Only fresh required evidence can mark a plan item or AC complete.
+
+Any fresh browser / API / runtime / data / test contradiction must downgrade the affected plan item, AC and overall status and must be recorded as invalidating evidence. Do not preserve a previous complete status after contradictory fresh evidence appears.
+
+## UI-Facing Gate
+
+For UI-facing acceptance, the executor must open the real page path and confirm the user-visible state matches the AC. component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
+
+## Autonomous Progress Protocol
+
+The Superpowers target prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
+
+The Superpowers target prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
+
+Pause only for locally unsatisfiable hard blockers such as missing accounts, credentials, production access, paid services, legal/security approval, user-only browser sessions or sensitive fields the executor cannot access safely. When pausing, give the minimum user action list: exact page, system, command or owner to open/contact; exact field or value location; how to redact or avoid sending sensitive values; what the executor will do immediately after receiving the input.
+
+## Official Superpowers Binding
+
+Bind the target prompt to the official Skill names and their documented roles:
+
+- If the Technical Realization Plan is not bite-sized enough, use `superpowers:writing-plans`.
+- Prefer `superpowers:subagent-driven-development` when subagents are available.
+- Use `superpowers:executing-plans` when executing a written plan without the same-session subagent workflow.
+- Plan or AC behavior gap -> TDD: each behavior gap uses `superpowers:test-driven-development` to write a failing test, observe failure, then implement minimally.
+- Before any completion claim, use `superpowers:verification-before-completion` against both `plan-conformance-matrix.*` and `final-acceptance-verdict.*` with fresh evidence, then run `ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>`.
+- review / finish cannot override the plan-conformance matrix or full checklist; if either gate is unsatisfied, continue implementation or report blockers.
+
+If Superpowers is missing, install it through the current platform's official Superpowers installation path. If installation is blocked by permissions, network or platform limits, record the blocker in local audit and do not count it as complete.
+
+## Local Audit Requirements
+
+The Superpowers target prompt must require the future executor to update local audit after each round with:
+
+- candidate status, not final completion.
+- Product Context Delta, Technical Context Delta and overall Context Delta decision.
+- plan item and AC status.
+- current evidence.
+- command/result/time and failure reason.
+- required test command/result/failure.
+- artifact or evidence paths.
+- blockers, missing evidence and acceptance impact.
+- deferred or narrowed scope with user approval state.
+- stale, partial, sampled-only, smoke, dry-run, research or other invalid evidence.
+
+The local audit is not Context, not proof, not a global task manager, and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`. It must not contain `overall_status: done`, `status: done` or `final_gate: passed`; use `candidate_status: claims_done_but_unverified` when needed.
+
+## Prompt Generation Rules
+
+- The prompt must visibly output `Superpowers 输入包` for Chinese prompts or `Superpowers input packet` for English prompts.
+- The prompt must visibly output `Superpowers 执行绑定` for Chinese prompts or `Superpowers execution binding` for English prompts.
+- The prompt must identify Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, local audit, plan-conformance matrix and final verdict paths at the top.
+- The prompt must state that the Technical Realization Plan controls plan conformance, the Product / Architecture Source prevents scope shrinkage and the full checklist controls acceptance.
+- The prompt must require Product Context Delta and Technical Context Delta evaluation before implementation.
+- The prompt must preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking complete.
+- The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries and must include the minimum user action list for locally unsatisfiable hard blockers.
+- The prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
+- The prompt must include the resource lifecycle line: `可多开agent，agent名额不够了就关掉不用的。` or `You may use multiple agents; if agent slots run low, close idle or unnecessary agents.`
+- The prompt must fit 3850 characters including line breaks.
+- Do not include explanatory preface inside the generated prompt.
+
+Recommended compact Chinese prompt shape:
+
+```text
+产品/架构源: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md（原始意图/防 scope shrinkage，非施工图）
+技术实现方案: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md（执行图纸/plan conformance source，非证明）
+验收清单: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md（完整验收标准，final verdict 以它为准）
+执行审计: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md（过程日志，非 proof，不能写 done/final_gate passed）
+对图纸矩阵: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json（先建，边做边更新）
+最终验收: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json（最后逐 AC 生成）
+可多开agent，agent名额不够了就关掉不用的。
+This is not a Superpowers official schema / 不是 Superpowers 官方 schema。
+Superpowers 输入包：
+- Product/Architecture Source：原始产品/架构意图，防止 scope shrinkage，不是施工图
+- Technical Realization Plan：施工图；每个行为 plan item 都要进 matrix
+- Acceptance Checklist：最高验收标准；每个 AC 都要进 final verdict
+- local audit：只记 progress/candidate status/evidence/blocker/invalidating evidence，不能裁判完成
+- Context/tests/core paths：执行前读取，把 plan/AC gap 绑定到测试、API/UI/runtime/browser 证据
+
+执行顺序：
+1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
+2. Context Delta required 时，先最小更新 owning project_context/** 或 DESIGN.md；不要把 audit/matrix/verdict/日志/截图/sample evidence 写进 Context。
+3. 检查技术实现方案覆盖产品/架构源关键要求；若只有产品方案没有技术实现方案，停止报告 missing Technical Realization Plan，不现场生成。
+4. 初始化 plan-conformance matrix；计划不够 bite-sized 时用 superpowers:writing-plans。
+5. 有 subagent 支持时优先 superpowers:subagent-driven-development，否则 superpowers:executing-plans。
+6. Plan/AC behavior gap -> superpowers:test-driven-development：先写 failing test 并 observe failure，再最小实现。
+7. 每个实现 slice 后更新 matrix 和 audit。
+8. Candidate done 前跑 Plan Conformance Gate：测试通过不等于按图纸完成；sampled path 不等于 full implementation；每个行为 plan item 必须有 code/API/UI/runtime/test/evidence trace。
+9. 再跑 Acceptance Evidence Gate：按验收清单生成 final verdict；current API/UI/runtime/data/test contradiction 高于历史通过记录。
+10. 完成声明前用 superpowers:verification-before-completion 检查 matrix/verdict，并运行 ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>；失败就继续或报告 blocker。
+
+权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；已授权 sudo/gsudo/admin elevation 先尝试，不算用户阻塞。只有本地无法解决的账号/凭证/真实环境/人工审批/敏感字段等才暂停，并给最小用户执行清单（具体页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
+禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、runtime 未演练、artifact 未被 validator accepted、API/UI 未 reflected、未批准 scope narrowing、任何 API/UI/data/runtime/test 矛盾。
+```
+
+Recommended compact English prompt shape:
+
+```text
+Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (original intent / scope guard, not construction plan)
+Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint / plan-conformance source, not proof)
+Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (acceptance authority; final verdict is judged against it)
+Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (process log, not proof; must not write done/final_gate passed)
+Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (create early, update during work)
+Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (generate at final gate, AC by AC)
+You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
+This is not a Superpowers official schema / 不是 Superpowers 官方 schema.
+Superpowers input packet:
+- Product / Architecture Source: original intent; prevents scope shrinkage; not the construction plan.
+- Technical Realization Plan: execution blueprint; every behavior-affecting item needs a matrix trace.
+- Acceptance Checklist: acceptance authority; every AC needs a final verdict entry.
+- Local audit: progress/candidate status/evidence/blockers/invalidating evidence only; never final proof.
+- Context/tests/core paths: read before execution; map plan/AC gaps to test/API/UI/runtime/browser evidence.
+
+Execution order:
+1. Read the three inputs and Context. Write Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required sub-delta makes overall Context Delta required. This is not a validator gate.
+2. If Context Delta required, minimally update the owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
+3. Check the Technical Realization Plan covers Product / Architecture Source requirements; if only a product plan exists, stop with missing Technical Realization Plan, do not generate it.
+4. Initialize plan-conformance matrix; use superpowers:writing-plans if the plan is not bite-sized.
+5. Prefer superpowers:subagent-driven-development with subagents; otherwise use superpowers:executing-plans.
+6. Plan/AC behavior gap -> superpowers:test-driven-development: write a failing test, observe failure, then implement minimally.
+7. After each slice, update matrix and audit.
+8. Before candidate done, run Plan Conformance Gate: passing tests does not prove plan conformance; sampled path does not prove full implementation; every behavior plan item needs code/API/UI/runtime/test/evidence trace.
+9. Then run Acceptance Evidence Gate: generate final verdict from the checklist; current API/UI/runtime/data/test contradictions override old passing evidence.
+10. Before completion, run superpowers:verification-before-completion on matrix/verdict and ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>; if either fails, continue/report blockers.
+
+Autonomy/blockers: within current platform/repo/tool/user-authorized permissions, do all safe self-service discovery/execution/verification. Authorized sudo/gsudo/admin elevation is not a user blocker; try it first. Pause only for locally unsatisfiable account/credential/real-env/human-approval/sensitive-field needs; give exact page/system, field location, redaction/do-not-send values and next agent step.
+Never complete on: local audit, subagent summary, final card, code-only/plan-only work, partial tests, stale/partial/sampled evidence, unexercised runtime, artifact not accepted by validator, API/UI not reflected, missing validate-plan-acceptance pass, unapproved scope narrowing or any API/UI/data/runtime/test contradiction.
+```
+
+Before final response, check the prompt length. If it exceeds 3850 characters, tighten wording while preserving paths, input roles, official Superpowers skill names, Product Context Delta, Technical Context Delta, plan-conformance matrix, final verdict, state machine, UI gate, blockers and invalid evidence.
+
+## Final Response Requirements
+
+When successful, return:
+
+- The Product / Architecture Source path.
+- The Technical Realization Plan path.
+- The full checklist path.
+- The local audit path.
+- The plan-conformance matrix path.
+- The final acceptance verdict path.
+- Whether required input was complete.
+- The paste-ready Superpowers target-mode prompt in a code block.
+
+When blocked, return:
+
+- Missing required fields.
+- Which source should provide each missing field.
+- A clear statement that no Superpowers target-mode prompt was generated.
+
+Do not claim any plan item or AC has passed unless the user explicitly asked for current completion audit and current evidence was inspected.
+
+## Forbidden Behaviors
+
+Do not generate, derive, or infer the Technical Realization Plan.
+
+Do not generate, derive, rewrite, strengthen, or repair the full checklist.
+
+Do not execute the generated prompt.
+
+Do not mark any goal complete.
+
+Do not hide missing source files, ambiguous scope, weak evidence, implementation drift or blockers.
+
+Do not include business-domain logic, concrete provider names, API names, UI names, artifact schemas or one-off project details in this package-managed Skill.