project-tiny-context-harness 0.2.73 → 0.2.75

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

@@ -1,471 +1,540 @@
----
-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.
-
-This Skill does not perform task-complexity routing. Direct invocation means the user or upstream process has already selected Superpowers long-task execution. Ordinary checklist preparation, non-Superpowers target prompts or incomplete upstream packets should be handled before this Skill, normally with `/normal-long-task` or a revised upstream packet.
-
-## 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.
-
-When blocked by missing input, return a structured Missing Fields Report with:
-
-- `missing_section`.
-- `missing_required_fields`.
-- `why_blocking`.
-- `cannot_infer_policy`.
-- `required_next_input`.
-- `suggested_upstream_action`.
-
-The report must state that this Skill cannot infer the execution blueprint from Product / Architecture Source and cannot repair the checklist. It may recommend supplying the missing Technical Realization Plan or using `/normal-long-task` before Superpowers execution when the upstream packet is not ready.
-
-## 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.
-
-## Authority Model
-
-- Product / Architecture Source owns intent, scope, non-goals, product/architecture boundaries and acceptance semantics.
-- Technical Realization Plan owns plan items, execution blueprint, owner/forbidden surfaces, implementation paths and plan-conformance expectations.
-- Acceptance Checklist owns ACs, completion semantics, required proof layers, invalid evidence rules and final acceptance state.
-- local audit, plan-conformance matrix, final acceptance verdict, validator output, optional proof index and auditor report are execution/evidence artifacts. They cannot narrow, rewrite or replace the upstream sources.
-- When sources conflict, stop or report the conflict instead of letting a downstream artifact silently change scope, plan or 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.
-
-For Superpowers execution, the generated prompt should use a parent/slice pattern:
-
-- Parent Context Delta: evaluate Product Context Delta, Technical Context Delta, overall Context Delta, owning Context files and whether required Context was updated before implementation.
-- Slice Context Delta: each implementation slice inherits the parent decision and only records whether it discovered a new durable fact.
-- If a slice discovers a new durable product or technical fact, it must identify the owning Context and update it before continuing.
-- Slice-level `none` cannot override a parent-level `required` decision.
-
-## 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.
-- required proof layers, satisfied proof layers and missing required layers when the plan/checklist requires layered evidence.
-- substitute or sibling evidence use when any similar execution path, negative case, screenshot or artifact could be confused with the required evidence.
-- 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.
-- A complete row cannot have unresolved `missing_required_layers`, material or critical `drift_severity`, unapproved `sibling_substitution_used`, summary-only evidence or blocking auditor findings.
-- 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.
-- required proof chain when the checklist or plan requires multiple evidence layers.
-- fresh evidence.
-- missing evidence.
-- missing required layers.
-- drift severity.
-- sibling substitution used / approval source.
-- auditor status and findings when an auditor subagent was available.
-- 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.
-- Complete AC rows cannot have unresolved `missing_required_layers`, material or critical `drift_severity`, unapproved `sibling_substitution_used`, blocking `auditor_status` or only self-certifying evidence such as local audit, matrix/verdict text, subagent summary, final card or validator pass.
-
-## External Reviewer Evidence Gate
-
-The final verdict is not completion proof unless every complete AC can be independently reviewed from fresh command, API, UI, runtime, artifact, browser or test evidence. Evidence index, matrix rows, local audit, validator pass and summaries can point to evidence, but cannot replace evidence.
-
-For every AC whose checklist implies multiple required layers, the final verdict must record `required_proof_chain`, `fresh_evidence`, `missing_required_layers`, `drift_severity`, `sibling_substitution_used`, `auditor_status` and `auditor_findings` when applicable. These are generic evidence protocol fields; concrete business layers must come from the Acceptance Checklist, Product / Architecture Source, Technical Realization Plan or project-local Context/Skills.
-
-Evidence Ledger / proof index is optional execution indexing, not a fourth input, not durable Context and not required as a separate file. Complete plan-conformance rows and complete AC verdicts must still be evidence-traceable: cite fresh, reviewable evidence directly in the row or through an optional `evidence_id` that points to command, API, UI, runtime, artifact, browser or test evidence with enough freshness context for a reviewer to reconstruct the proof chain.
-
-## Drift-to-Status
-
-Any plan item or AC with unresolved missing required layers, material / critical drift or a current API / UI / runtime / data / test contradiction cannot be `complete`. It must be `partial`, `blocked`, `invalidated` or `out_of_scope_NA` with explicit source reference.
-
-## No Sibling Substitution
-
-The same execution path, negative case, screenshot or artifact class cannot substitute for the required one unless the checklist explicitly allows that substitution or marks the required layer `out_of_scope_NA`. Similar evidence is auxiliary only.
-
-## Independent Reviewer Gate
-
-When subagents are available, add a read-only auditor after executor self-evidence and `validate-plan-acceptance`. The auditor is a gap detector, not a proof source: it must not edit code, repair artifacts or treat local audit, subagent summary, matrix/verdict text, validator pass or final card as proof. It reconstructs each AC proof chain from source/plan/checklist, checks freshness and raw evidence, rejects sibling substitution and returns `auditor_status` plus findings. Any `partial`, `blocked` or `invalidated` auditor result downgrades the affected AC unless fresh evidence closes the gap.
-
-Final gate order is fixed:
-
-1. executor self-evidence.
-2. update plan-conformance matrix.
-3. update final-acceptance verdict.
-4. run `ty-context validate-plan-acceptance`.
-5. run read-only auditor gap review when subagents are available.
-6. if auditor findings change matrix, verdict or evidence, fix the gap and rerun `ty-context validate-plan-acceptance`.
-7. make a final completion claim only when self-evidence, validator consistency and auditor review have no blocking conflict.
-
-## Goal And Acceptance Wording
-
-The Superpowers target prompt must keep three completion concepts separate:
-
-- `audit_task_complete`: the read-only audit, final-gate workflow or artifact-production task finished.
-- `acceptance_target_status`: the final verdict outcome for the checked plan or product target.
-- `product_goal_complete`: the checked plan or product target is accepted as complete.
-
-`product_goal_complete` may be true only when the final verdict overall status is `accepted` or `complete`, all required ACs are `complete` or explicit sourced `out_of_scope_NA`, `ty-context validate-plan-acceptance` passes, and any auditor has no blocking finding.
-
-When the generated prompt is used as an implementation or execution Goal mode objective, the active Codex goal is complete only when `product_goal_complete=true`. A non-accepted `acceptance_target_status` means continue implementation or report blockers / missing evidence; do not close the implementation goal as complete.
-
-A read-only audit / reporting Goal mode objective is different: when the explicit goal is only to produce an audit and verdict, `audit_task_complete` may complete that meta-goal even when `product_goal_complete=false`. In that case, if `acceptance_target_status` is `partial`, `blocked`, `invalidated`, `not_run`, `partial_not_accepted_as_complete_platform` or any other non-accepted status, the final response must say `Audit workflow completed; acceptance target not complete.` It should include complete / partial / blocked / not_run / invalidated counts when available. Do not write an unqualified `Goal achieved` and do not describe `update_goal(status="complete")` as user-target or product-goal completion in that case.
-
-## 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.
-
-Before treating account, credential or app access as blocked, open the relevant app, browser page, CLI tool or system setting and try existing app sessions, browser cookies, CLI auth, OS credential helpers or other user-authorized local state. If the existing session is absent, expired, permission-denied or requires login/MFA/approval, then pause with the minimal user action list; do not ask the user to send passwords, tokens, cookies or full sensitive fields.
-
-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.
-
-The local audit is process recovery only. It must not contain completion judgment such as accepted, complete, done, final passed or product verified except as invalid evidence being rejected.
-
-## 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 state the Authority Model and that audit/matrix/verdict/validator/auditor artifacts cannot rewrite source, plan or checklist authority.
-- The prompt must require Product Context Delta and Technical Context Delta evaluation before implementation.
-- The prompt must use parent-level Context Delta plus slice-level new durable fact checks.
-- The prompt must state that Evidence Ledger / proof index is optional, but complete rows and ACs require evidence traceability to fresh evidence directly or through optional `evidence_id`.
-- The prompt must require the fixed final gate order and rerun `validate-plan-acceptance` if auditor-driven fixes change artifacts.
-- The prompt must state the Goal mode completion rule: implementation / execution goals complete only at `product_goal_complete=true`; read-only audit / reporting goals may end at `audit_task_complete` but must still report the acceptance target status.
-- The prompt must require the final response to say `Audit workflow completed; acceptance target not complete.` whenever the verdict is not accepted/complete, and must forbid unqualified `Goal achieved` or treating `update_goal(status="complete")` as product acceptance in that case.
-- 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 say existing app sessions, browser cookies, CLI auth and OS credential helpers are self-service resources: open the relevant app/page/tool/settings first, use existing local auth if present, and pause only after access is actually absent, expired, permission-denied or requires login/MFA/approval.
-- 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 证据
-权威：source 管 scope，plan 管施工，checklist 管验收；audit/matrix/verdict/validator/auditor 不能改写它们。Proof index/evidence ledger 文件可选，但 complete 行必须能直接或经 evidence_id 追溯 fresh evidence。
-Goal mode：实现/执行目标只在 product_goal_complete=true 时完成；只读审计目标可在 audit_task_complete 时结束，但若 verdict 非 accepted/complete，必须写“Audit workflow completed; acceptance target not complete.”并列数量；不得写 Goal achieved 或把 update_goal complete 当用户目标完成。
-
-执行顺序：
-1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
-2. 用 Parent Context Delta 统一判断；每个 slice 继承它，只记录 new durable fact yes/no。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；每 AC 写 required proof chain/fresh evidence/missing layers/drift/substitution。current contradiction 高于历史通过记录。
-10. Final gate 固定为 self-evidence -> matrix -> verdict -> validator -> read-only auditor；auditor summary 不是 proof。若审计后改 artifact/evidence，重跑 validator；完成前用 superpowers:verification-before-completion 检查 matrix/verdict，并运行 ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>。
-
-权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；先打开相关 app/浏览器页面/CLI/系统设置，复用已有登录态/授权会话/凭据链；已授权 sudo/gsudo/admin elevation 先尝试。只有实际未登录/会话失效/权限不足/需要 MFA 或人工审批、缺账号/真实环境/敏感字段时才暂停，并给最小用户执行清单（页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
-禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、缺 required layer、material drift、未批准 sibling substitution、runtime 未演练、artifact 未 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 (scope)
-Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint)
-Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (authority)
-Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (log, not proof)
-Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (work trace)
-Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (AC gate)
-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:
-- Source guards scope; plan controls matrix; checklist controls verdict; audit records progress only.
-- Read Context/tests/core paths first; map gaps to test/API/UI/runtime/browser evidence.
-Authority: source/plan/checklist own scope/construction/acceptance; audit/matrix/verdict/validator/auditor cannot rewrite them. Proof index optional; complete rows need fresh evidence/evidence_id.
-Goal mode: implementation/execution goal complete only when product_goal_complete=true; read-only audit goal may end at audit_task_complete, but if verdict not accepted say "Audit workflow completed; acceptance target not complete." Include counts; no bare "Goal achieved" or update_goal complete as user target.
-
-Execution order:
-1. Read inputs and Context. Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required -> Context Delta required. Not a validator gate.
-2. Use Parent Context Delta once; slices inherit it and record new durable fact yes/no. If required, update owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
-3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan.
-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. Plan Conformance Gate: tests do not prove conformance; sampled path is not full implementation; each behavior item needs code/API/UI/runtime/test/evidence trace.
-9. Acceptance Evidence Gate: checklist controls verdict; each AC records proof chain, fresh evidence, missing layers, drift, substitution. Current contradictions override old passes.
-10. Final gate: self-evidence -> matrix -> verdict -> validator -> read-only auditor. Auditor summary is not proof. Rerun validator after evidence changes; before completion run superpowers:verification-before-completion and ty-context validate-plan-acceptance tmp/ty-context/plan-acceptance/<plan-slug>.
-
-Autonomy/blockers: self-serve under current permissions. Open app/browser/CLI/settings and reuse sessions/auth/helpers. Try authorized sudo/gsudo/admin. Pause only after missing login, expired session, denied permission, MFA/approval, unavailable env/account or sensitive field; give page/system, field, redaction/do-not-send values, next step.
-Never complete on: local audit, summary/final card, code/plan-only, partial tests, stale/partial/sampled evidence, missing layer, material drift, unapproved sibling substitution, unexercised runtime, artifact not accepted, API/UI not reflected, missing validator pass, unapproved scope narrowing or 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 generated prompt's Goal mode completion rule for implementation / execution goals, and required final status wording for non-accepted read-only audit results: `Audit workflow completed; acceptance target not complete.`
-- The paste-ready Superpowers target-mode prompt in a code block.
-
-When blocked, return:
-
-- Missing Fields Report.
-- `missing_section`.
-- `missing_required_fields`.
-- `why_blocking`.
-- `cannot_infer_policy`.
-- `required_next_input`.
-- `suggested_upstream_action`.
-- 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.
+---
+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 aligned to the official Superpowers skills, while remaining a Tiny Context-owned adapter rather than an upstream-owned schema. It 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
+
+The extra Tiny Context gates exist because Superpowers alone can still drift under long-running execution pressure. Superpowers strengthens execution discipline, but it does not by itself preserve source authority, prevent scope shrinkage, prove full conformance to the Technical Realization Plan, or enforce AC-by-AC evidence against the Acceptance Checklist.
+
+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. The Technical Realization Plan must already be equivalent to a Superpowers-ready Markdown implementation plan; when it satisfies the required input fields, this Skill skips plan generation and produces the execution binding directly. 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.
+
+This Skill does not perform task-complexity routing. Direct invocation means the user or upstream process has already selected Superpowers long-task execution. Ordinary checklist preparation, non-Superpowers target prompts or incomplete upstream packets should be handled before this Skill, normally with `/normal-long-task` or a revised upstream packet.
+
+## 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 and can be executed like a Superpowers Markdown implementation plan.
+- 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.
+
+When blocked by missing input, return a structured Missing Fields Report with:
+
+- `missing_section`.
+- `missing_required_fields`.
+- `why_blocking`.
+- `cannot_infer_policy`.
+- `required_next_input`.
+- `suggested_upstream_action`.
+
+The report must state that this Skill cannot infer the execution blueprint from Product / Architecture Source and cannot repair the checklist. It may recommend supplying a complete Product / Architecture Source, Technical Realization Plan or Acceptance Checklist packet before Superpowers execution when the upstream packet is not ready.
+
+## 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.
+
+## Authority Model
+
+- Product / Architecture Source owns intent, scope, non-goals, product/architecture boundaries and acceptance semantics.
+- Technical Realization Plan owns plan items, execution blueprint, owner/forbidden surfaces, implementation paths and plan-conformance expectations.
+- Acceptance Checklist owns ACs, completion semantics, required proof layers, invalid evidence rules and final acceptance state.
+- local audit, plan-conformance matrix, final acceptance verdict, validator output, optional proof index and auditor report are execution/evidence artifacts. They cannot narrow, rewrite or replace the upstream sources.
+- When sources conflict, stop or report the conflict instead of letting a downstream artifact silently change scope, plan or acceptance.
+- Tiny Context additions may wrap Superpowers with authority, conformance and acceptance gates, but they must not redefine, duplicate or fork official Superpowers execution mechanics. If a future change would make a Tiny Context-added step conflict with, duplicate or override an official Superpowers responsibility, stop and surface the boundary conflict instead of silently merging the workflows.
+
+## 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.
+
+For Superpowers execution, the generated prompt should use a parent/slice pattern:
+
+- Parent Context Delta: evaluate Product Context Delta, Technical Context Delta, overall Context Delta, owning Context files and whether required Context was updated before implementation.
+- Slice Context Delta: each implementation slice inherits the parent decision and only records whether it discovered a new durable fact.
+- If a slice discovers a new durable product or technical fact, it must identify the owning Context and update it before continuing.
+- Slice-level `none` cannot override a parent-level `required` decision.
+
+## 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.
+- required proof layers, satisfied proof layers and missing required layers when the plan/checklist requires layered evidence.
+- substitute or sibling evidence use when any similar execution path, negative case, screenshot or artifact could be confused with the required evidence.
+- 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.
+- A complete row cannot have unresolved `missing_required_layers`, material or critical `drift_severity`, unapproved `sibling_substitution_used`, summary-only evidence or blocking auditor findings.
+- 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.
+- required proof chain when the checklist or plan requires multiple evidence layers.
+- fresh evidence.
+- missing evidence.
+- missing required layers.
+- drift severity.
+- sibling substitution used / approval source.
+- auditor status and findings when an auditor subagent was available.
+- 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.
+- Complete AC rows cannot have unresolved `missing_required_layers`, material or critical `drift_severity`, unapproved `sibling_substitution_used`, blocking `auditor_status` or only self-certifying evidence such as local audit, matrix/verdict text, subagent summary, final card or validator pass.
+
+## External Reviewer Evidence Gate
+
+The final verdict is not completion proof unless every complete AC can be independently reviewed from fresh command, API, UI, runtime, artifact, browser or test evidence. Evidence index, matrix rows, local audit, validator pass and summaries can point to evidence, but cannot replace evidence.
+
+For every AC whose checklist implies multiple required layers, the final verdict must record `required_proof_chain`, `fresh_evidence`, `missing_required_layers`, `drift_severity`, `sibling_substitution_used`, `auditor_status` and `auditor_findings` when applicable. These are generic evidence protocol fields; concrete business layers must come from the Acceptance Checklist, Product / Architecture Source, Technical Realization Plan or project-local Context/Skills.
+
+Evidence Ledger / proof index is optional execution indexing, not a fourth input, not durable Context and not required as a separate file. Complete plan-conformance rows and complete AC verdicts must still be evidence-traceable: cite fresh, reviewable evidence directly in the row or through an optional `evidence_id` that points to command, API, UI, runtime, artifact, browser or test evidence with enough freshness context for a reviewer to reconstruct the proof chain.
+
+## Evidence Manifest And Slice Batching
+
+For non-trivial execution slices, the prompt should recommend a rolling optional evidence manifest at `tmp/ty-context/plan-acceptance/<plan-slug>-evidence-manifest.md/json`. The manifest is not a fourth input, not durable Context, not proof by itself and not required by `validate-plan-acceptance`; it is a slice-level source for synchronizing matrix, verdict and audit updates with less stale wording.
+
+Each manifest entry should include `evidence_id`, `slice_id`, `slice_goal`, `missing_layer_classes`, `touched_plan_item_ids`, `touched_ac_ids`, `commands`, `artifacts`, `runtime_or_browser_evidence`, `proves`, `explicitly_does_not_prove`, `closed_missing_layers`, `remaining_missing_layers`, `cleanup_status`, `redaction_security_status` and `freshness`.
+
+The manifest must not contain secrets, raw credentials, tokens, cookies or long raw payloads. Record redacted paths, command identities, evidence ids, counts and short summaries instead.
+
+Default slice sizing: group 2-4 strongly related missing layers that share the same AC, runtime scenario, proof environment or verification path. Single-gap slices are reserved for blockers, contradictions or tiny metadata cleanup. Before choosing a slice, classify missing layers as functional gap, proof gap, stale wording/artifact sync, upstream blocker, live DB/runtime proof, Browser/UI proof, security/redaction proof or all-provider/all-runner coverage.
+
+After each slice, update matrix and local audit from the manifest. Update verdict evidence/missing-layer fields conservatively, but do not mark ACs complete before the final gate. Reuse DB/API/Browser environments for related slices only with unique proof prefixes and a final cleanup count/assertion.
+
+Run a stale/overclaim scan over the evidence manifest, matrix, verdict and audit after synchronization. Remove leftover closed gaps and reject unsafe claims such as `accepted`, `complete`, `final passed`, `product_goal_complete=true`, unapproved `scope narrowed` or unapproved sibling substitution unless the checklist and final gate justify them.
+
+## Gate Cadence And Progress Accounting
+
+The generated prompt must use a tiered cadence instead of running the full final gate after every slice:
+
+- Slice Gate: after each implementation slice, sync the evidence manifest when used, matrix, local audit and conservative verdict evidence/missing-layer fields; run only targeted tests or probes needed for that slice; run stale/overclaim cleanup; do not run the full final gate after every slice.
+- Epoch Gate: after a cluster of related slices, such as a provider/browser/runtime/security epoch, batch shared DB/API/Browser/proof-environment cleanup and rerun the higher-value cross-slice tests, validators or smoke checks for that cluster.
+- Final Gate: after all required plan items and AC proof layers are ready, run the fixed final gate order, including `superpowers:verification-before-completion`, `ty-context validate-plan-acceptance`, read-only auditor when available, final stale/overclaim scan and completion wording.
+
+The generated prompt must require Progress Accounting after each Slice Gate, Epoch Gate and Final Gate. Track four metrics separately:
+
+- AC acceptance completion: AC rows that are `complete` or sourced `out_of_scope_NA` versus acceptance-required AC rows.
+- engineering implementation progress: plan-conformance rows with implemented paths/tests/evidence versus behavior-affecting plan rows.
+- runtime/proof progress: required proof layers by status, not just code landed.
+- workflow overhead: time, artifacts, gate loops, stale-sync cleanup and review burden spent on workflow rather than product proof.
+
+Use a lightweight progress ledger at `tmp/ty-context/plan-acceptance/<plan-slug>-progress-ledger.md/json` when the task spans multiple slices or agents. The progress ledger is not Context, not proof and not a fourth input; it records current counts, gate cadence, next high-value clusters and stale-state cleanup so the executor does not rerun the full final gate after every slice.
+
+Every non-trivial slice should declare an artifact budget: expected files/manifest rows/screenshots/log summaries to create or update, maximum raw-output retention, cleanup expectations and which artifacts are safe to sync into verdict rows. Excess artifact growth or repeated stale-sync cleanup triggers workflow overhead backpressure: batch the next proof-environment run, merge small stale-only slices, prune obsolete temporary notes and prefer the next proof that closes the most AC/proof-layer gaps.
+
+Proof-layer milestones should use only these statuses: `not_started`, `implemented_no_proof`, `proof_partial`, `proof_ready`, `complete`, `blocked` and `out_of_scope_NA`. Milestones are progress visibility, not acceptance by themselves. The prompt should ask for Next 3-5 high-value clusters after each epoch: choose clusters that close the most blocking AC/proof layers with the least new workflow overhead.
+
+When final-verdict Markdown includes generated active counts, wrap them exactly in:
+
+```text
+<!-- generated:active-counts:start -->
+complete_count: <n>
+partial_count: <n>
+acceptance_required_count: <n>
+missing_layer_count: <n>
+<!-- generated:active-counts:end -->
+```
+
+Active generated counts must be regenerated from the current verdict, not hand-maintained from stale prose.
+
+## Drift-to-Status
+
+Any plan item or AC with unresolved missing required layers, material / critical drift or a current API / UI / runtime / data / test contradiction cannot be `complete`. It must be `partial`, `blocked`, `invalidated` or `out_of_scope_NA` with explicit source reference.
+
+## No Sibling Substitution
+
+The same execution path, negative case, screenshot or artifact class cannot substitute for the required one unless the checklist explicitly allows that substitution or marks the required layer `out_of_scope_NA`. Similar evidence is auxiliary only.
+
+## Independent Reviewer Gate
+
+When subagents are available, add a read-only auditor after executor self-evidence and `validate-plan-acceptance`. The auditor is a gap detector, not a proof source: it must not edit code, repair artifacts or treat local audit, subagent summary, matrix/verdict text, validator pass or final card as proof. It reconstructs each AC proof chain from source/plan/checklist, checks freshness and raw evidence, rejects sibling substitution and returns `auditor_status` plus findings. Any `partial`, `blocked` or `invalidated` auditor result downgrades the affected AC unless fresh evidence closes the gap.
+
+Use a fixed auditor checklist: source/plan/checklist consistency, closed gaps have fresh evidence, active matrix/verdict wording removed closed missing layers, remaining blockers are preserved, live evidence is fresh and not dry-run/sample substitution, UI proof uses real owner surface evidence, no unapproved sibling substitution or scope narrowing, no overclaim and final status matches the proof chain.
+
+Final gate order is fixed:
+
+1. update evidence manifest when used.
+2. sync plan-conformance matrix, final-acceptance verdict and local audit.
+3. run `superpowers:verification-before-completion` against matrix and verdict.
+4. run `ty-context validate-plan-acceptance`.
+5. run read-only auditor gap review when subagents are available.
+6. if auditor findings change artifacts or evidence, fix the gap and rerun `ty-context validate-plan-acceptance`.
+7. run a final lightweight stale/overclaim scan.
+8. make a final completion claim only when self-evidence, validator consistency and auditor review have no blocking conflict.
+
+## Goal And Acceptance Wording
+
+The Superpowers target prompt must keep three completion concepts separate:
+
+- `audit_task_complete`: the read-only audit, final-gate workflow or artifact-production task finished.
+- `acceptance_target_status`: the final verdict outcome for the checked plan or product target.
+- `product_goal_complete`: the checked plan or product target is accepted as complete.
+
+`product_goal_complete` may be true only when the final verdict overall status is `accepted` or `complete`, all required ACs are `complete` or explicit sourced `out_of_scope_NA`, `ty-context validate-plan-acceptance` passes, and any auditor has no blocking finding.
+
+When the generated prompt is used as an implementation or execution Goal mode objective, the active Codex goal is complete only when `product_goal_complete=true`. A non-accepted `acceptance_target_status` means continue implementation or report blockers / missing evidence; do not close the implementation goal as complete.
+
+A read-only audit / reporting Goal mode objective is different: when the explicit goal is only to produce an audit and verdict, `audit_task_complete` may complete that meta-goal even when `product_goal_complete=false`. In that case, if `acceptance_target_status` is `partial`, `blocked`, `invalidated`, `not_run`, `partial_not_accepted_as_complete_platform` or any other non-accepted status, the final response must say `Audit workflow completed; acceptance target not complete.` It should include complete / partial / blocked / not_run / invalidated counts when available. Do not write an unqualified `Goal achieved` and do not describe `update_goal(status="complete")` as user-target or product-goal completion in that case.
+
+## 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.
+
+Before treating account, credential or app access as blocked, open the relevant app, browser page, CLI tool or system setting and try existing app sessions, browser cookies, CLI auth, OS credential helpers or other user-authorized local state. If the existing session is absent, expired, permission-denied or requires login/MFA/approval, then pause with the minimal user action list; do not ask the user to send passwords, tokens, cookies or full sensitive fields.
+
+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:
+
+- 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.
+- Superpowers review and verification remain useful execution checks, but they cannot override Tiny Context gates: passing Superpowers review does not by itself prove plan conformance or checklist acceptance.
+
+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.
+
+The local audit is process recovery only. It must not contain completion judgment such as accepted, complete, done, final passed or product verified except as invalid evidence being rejected.
+
+## 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 state that this is a Tiny Context adapter for Superpowers workflows, aligned to the official Superpowers skills, not an upstream-owned schema.
+- The prompt must state that Tiny Context gates wrap Superpowers for source authority, conformance and acceptance, but do not redefine or fork Superpowers execution mechanics.
+- 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 state the Authority Model and that audit/matrix/verdict/validator/auditor artifacts cannot rewrite source, plan or checklist authority.
+- The prompt must require Product Context Delta and Technical Context Delta evaluation before implementation.
+- The prompt must use parent-level Context Delta plus slice-level new durable fact checks.
+- The prompt must state that Evidence Ledger / proof index is optional, but complete rows and ACs require evidence traceability to fresh evidence directly or through optional `evidence_id`.
+- The prompt must recommend optional `evidence-manifest.md/json` for non-trivial slices, while stating it is not a fourth input, not durable Context, not proof and not required by `validate-plan-acceptance`.
+- The prompt must forbid secrets, raw credentials, tokens, cookies and long raw payloads in evidence manifests.
+- The prompt must prefer 2-4 strongly related missing layers per slice, require missing-layer classification, manifest-driven matrix/audit synchronization, conservative verdict updates and no AC completion before the final gate.
+- The prompt must include Slice Gate, Epoch Gate and Final Gate cadence; it must say not to run the full final gate after every slice.
+- The prompt must include Progress Accounting for AC acceptance completion, engineering implementation progress, runtime/proof progress and workflow overhead.
+- The prompt must include the progress-ledger.md/json path, artifact budget, proof-layer milestone statuses, workflow overhead backpressure and Next 3-5 high-value clusters.
+- The prompt must mention provider/browser/runtime/security epoch batching and generated active-count markers for final-verdict Markdown.
+- The prompt must include stale/overclaim scan, related-runtime reuse with unique proof prefixes and cleanup count/assertion, and the fixed auditor checklist.
+- The prompt must require the fixed final gate order and rerun `validate-plan-acceptance` if auditor-driven fixes change artifacts.
+- The prompt must state the Goal mode completion rule: implementation / execution goals complete only at `product_goal_complete=true`; read-only audit / reporting goals may end at `audit_task_complete` but must still report the acceptance target status.
+- The prompt must require the final response to say `Audit workflow completed; acceptance target not complete.` whenever the verdict is not accepted/complete, and must forbid unqualified `Goal achieved` or treating `update_goal(status="complete")` as product acceptance in that case.
+- 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 say existing app sessions, browser cookies, CLI auth and OS credential helpers are self-service resources: open the relevant app/page/tool/settings first, use existing local auth if present, and pause only after access is actually absent, expired, permission-denied or requires login/MFA/approval.
+- 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 生成）
+证据manifest: tmp/ty-context/plan-acceptance/<plan-slug>-evidence-manifest.md/json（可选slice小票，禁secret，非proof/第四输入/Context）
+可多开agent，agent名额不够了就关掉不用的。
+这是面向 Superpowers workflow 的 Tiny Context 适配输入包，对齐官方 Superpowers skills；不是上游维护的 schema。
+Tiny Context gates 只管 source authority/对图纸/验收，不重定义或分叉 Superpowers 执行机制。
+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 证据
+权威：source 管 scope，plan 管施工，checklist 管验收；audit/matrix/verdict/validator/auditor 不能改写它们。Proof index/evidence ledger/manifest 可选，但 complete 行必须能直接或经 evidence_id 追溯 fresh evidence。
+Goal mode：实现/执行目标只在 product_goal_complete=true 时完成；只读审计目标可在 audit_task_complete 时结束，但若 verdict 非 accepted/complete，必须写“Audit workflow completed; acceptance target not complete.”并列数量；不得写 Goal achieved 或把 update_goal complete 当用户目标完成。
+
+执行顺序：
+1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
+2. 用 Parent Context Delta 统一判断；每个 slice 继承它，只记录 new durable fact yes/no。Context Delta required 时先最小更新 owning project_context/** 或 DESIGN.md；不要把 audit/matrix/verdict/日志/截图/sample evidence 写进 Context。
+3. 检查技术实现方案覆盖产品/架构源关键要求；若只有产品方案没有技术实现方案，停止报告 missing Technical Realization Plan，不现场生成。
+4. 初始化 plan-conformance matrix；技术实现方案在本 Skill 输入校验阶段已确认可执行，直接绑定执行。
+5. 有 subagent 支持时优先 superpowers:subagent-driven-development，否则 superpowers:executing-plans。
+6. Plan/AC behavior gap -> superpowers:test-driven-development：先写 failing test 并 observe failure，再最小实现。
+7. 默认把同 AC/runtime/proof path 的 2-4 个 related missing layers 合成 slice；单 gap 只用于 blocker/contradiction/metadata cleanup。先分类 functional/proof/stale/upstream/live DB/Browser/security/all-runner gap；每 slice 更新可选 manifest，再同步 matrix/audit，verdict 只保守改 evidence/missing，不提前 complete。
+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；每 AC 写 required proof chain/fresh evidence/missing layers/drift/substitution。current contradiction 高于历史通过记录。
+10. Final gate 固定为 manifest -> matrix/verdict/audit sync -> verification-before-completion -> validator -> read-only auditor -> stale/overclaim scan；auditor summary 不是 proof。若审计后改 artifact/evidence，重跑 validator。
+
+权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；先打开相关 app/浏览器页面/CLI/系统设置，复用已有登录态/授权会话/凭据链；已授权 sudo/gsudo/admin elevation 先尝试。只有实际未登录/会话失效/权限不足/需要 MFA 或人工审批、缺账号/真实环境/敏感字段时才暂停，并给最小用户执行清单（页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
+禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、缺 required layer、material drift、未批准 sibling substitution、runtime 未演练、artifact 未 accepted、API/UI 未 reflected、未批准 scope narrowing、任何 API/UI/data/runtime/test 矛盾。
+```
+
+Recommended compact English prompt shape:
+
+```text
+Base path: tmp/ty-context/plan-acceptance/<plan-slug>
+Product / Architecture Source: <base>-product-architecture-source.md (scope)
+Technical Realization Plan: <base>-technical-realization-plan.md (blueprint)
+Acceptance Checklist: <base>-acceptance-checklist.md (authority)
+Local audit: <base>-local-audit.md (log, not proof)
+Plan matrix: <base>-plan-conformance-matrix.md/json (trace)
+Final verdict: <base>-final-acceptance-verdict.md/json (AC)
+Evidence manifest: <base>-evidence-manifest.md/json (optional note; no secrets; not proof/input/Context)
+You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
+Tiny Context adapter for Superpowers; aligned to official skills, not upstream schema.
+TC gates cover authority/conformance/acceptance, not Superpowers mechanics.
+Superpowers input packet:
+- Source guards scope; plan controls matrix; checklist controls verdict; audit records progress only.
+- Read Context/tests/core paths first; map gaps to test/API/UI/runtime/browser evidence.
+Authority: source/plan/checklist own scope/construction/acceptance; audit/matrix/verdict/validator/auditor cannot rewrite. Proof index/manifest optional; complete rows need fresh evidence/evidence_id.
+Goal mode: implementation/execution complete only at product_goal_complete=true. Read-only audit may end at audit_task_complete; non-accepted verdict says "Audit workflow completed; acceptance target not complete."; no bare "Goal achieved" or update_goal complete as user target.
+
+Execution order:
+1. Read inputs and Context. Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required -> Context Delta required. Not a validator gate.
+2. Use Parent Context Delta once; slices inherit it and record new durable fact yes/no. If required, update owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
+3. Check Technical Realization Plan covers Product / Architecture Source; if only product plan exists, stop with missing Technical Realization Plan.
+4. Init plan matrix; TRP was already validated as executable input, so bind it directly.
+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. Batch slices: prefer 2-4 related missing layers sharing AC/runtime/proof path; single-gap only for blockers/contradictions/metadata cleanup. Classify gaps, write optional manifest, sync matrix/audit; update verdict conservatively, no AC complete before final gate.
+8. Plan Conformance Gate: tests do not prove conformance; sampled path is not full implementation; each behavior item needs code/API/UI/runtime/test/evidence trace.
+9. Acceptance Evidence Gate: checklist controls verdict; each AC records proof chain, fresh evidence, missing layers, drift, substitution. Current contradictions override old passes.
+10. Final gate: manifest -> matrix/verdict/audit sync -> verification-before-completion -> validator -> auditor -> stale/overclaim scan. Auditor summary is not proof; rerun validator after changes.
+
+Autonomy/blockers: self-serve under current permissions. Open app/browser/CLI/settings and reuse sessions/auth/helpers. Try authorized sudo/gsudo/admin. Pause only after missing login/session expiry/denied permission/MFA/approval/missing env/account/field; give page/system, field, redaction, next step.
+Never complete on: local audit, summary/final card, code/plan-only, partial tests/evidence, stale/sampled evidence, missing layer, material drift, unapproved substitution/scope narrowing, unexercised runtime, artifact not accepted, API/UI not reflected, missing validator pass or current 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 generated prompt's Goal mode completion rule for implementation / execution goals, and required final status wording for non-accepted read-only audit results: `Audit workflow completed; acceptance target not complete.`
+- The paste-ready Superpowers target-mode prompt in a code block.
+
+When blocked, return:
+
+- Missing Fields Report.
+- `missing_section`.
+- `missing_required_fields`.
+- `why_blocking`.
+- `cannot_infer_policy`.
+- `required_next_input`.
+- `suggested_upstream_action`.
+- 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.