project-tiny-context-harness 0.2.66 → 0.2.68

package/assets/skills/plan_acceptance_checklist_compiler/SKILL.md

@@ -1,684 +0,0 @@
----
-name: plan_acceptance_checklist_compiler
-description: Use when the user provides or references a plan, Markdown file, RFC, implementation proposal, milestone plan, or long-task goal/target-mode task and explicitly asks for an acceptance checklist, completion definition, or goal/target-mode prompt. Triggers include acceptance checklist for this plan, goal-mode prompt for this implementation plan, target-mode prompt for this plan, 为这份方案生成验收清单, 整理这份方案输出目标模式文本. Do not trigger on standalone acceptance/目标模式/完成定义 terms without a plan-like source. This Skill writes temporary artifacts under tmp/ty-context/plan-acceptance and never executes the plan or marks completion.
----
-
-# Plan Acceptance Checklist Compiler
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `plan_acceptance_checklist_compiler` Skill directly in a consumer project.
-
-Project-specific acceptance rules belong in `project_context/**`, `DESIGN.md` when visual design facts are durable, or a separate project-local Skill. Keep this package-managed Skill business-agnostic.
-
-## Purpose
-
-Convert a given long-task plan into a strict, project-context-aware acceptance checklist and a short goal/target-mode execution prompt.
-
-The output answers:
-
-```text
-For this exact plan, what must be true before a future executor can honestly say the task is complete?
-```
-
-This Skill is generic. Do not embed business-specific rules, vendor-specific rules, product-domain assumptions, artifact schemas, concrete interface names, UI names, state names, or one-off project logic in this Skill. If the user's plan contains a specific domain, derive acceptance items from that plan and the project Context during the current invocation only.
-
-## Required Outputs
-
-Every completed invocation must produce:
-
-1. A preserved copy of the plan under `tmp/ty-context/plan-acceptance/`. The copied plan is the implementation/source plan, not acceptance proof. For a two-document upstream input packet, preserve both source inputs separately when both are provided.
-2. A rigorous full acceptance checklist under a separate `tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md` path. If the plan contains an explicit concrete acceptance checklist, reuse that plan-provided checklist verbatim; otherwise derive the checklist from the plan and relevant project Context. The full checklist is the complete acceptance standard and owns required automated test evidence.
-3. A goal/target-mode prompt the user can paste directly into Codex. The prompt may include a compact checklist summary for direction, priority and recovery navigation, but the full checklist owns the acceptance details.
-4. When a local audit path is referenced, it is temporary execution/progress state only, not Context and not proof by itself.
-
-The compiler may receive one source plan or a two-document upstream input packet:
-
-- `Development Plan / 开发方案`: objective, original requirement source summary, execution direction, module/API/UI/runtime/data flow, risk boundaries, Context Delta and whether execution must first be converted into bite-sized tasks.
-- `Acceptance and Tests / 验收清单和测试用例`: ACs, required evidence, tests, real product paths, core paths, evidence layers, invalid evidence, completion state machine, local audit rules and blockers.
-
-These inputs are preserved source input, not proof. The compiler's job is to turn them into the full checklist and target prompt that Superpowers can execute against without losing acceptance authority.
-
-Two-document upstream input packet handling is strict mode. If the compiler cannot fully parse the required content from both documents, it must stop and ask the user to provide the missing required fields. Do not generate a checklist or goal/target-mode prompt from an incomplete two-document packet.
-
-Exception: if the Context confirmation gate below triggers, stop after materializing the plan and reading enough Context to explain the uncertainty. Ask the user for confirmation before producing the checklist or goal/target-mode prompt.
-
-The goal/target-mode prompt must be no longer than 3850 characters, including line breaks. This conservative budget keeps the prompt below Codex's 4000-character practical paste boundary even when character counting differs slightly. Keep the prompt information-dense: preserve required paths, core acceptance criteria, evidence rules, blockers and false-completion traps while using compact wording. Use the user's language when practical. For Chinese requests, use this shape:
-
-```text
-实施计划: tmp/ty-context/plan-acceptance/<plan>.md（source/implementation plan，非验收证明）
-完整验收清单: tmp/ty-context/plan-acceptance/<plan>-acceptance-checklist.md（该文件是完整验收标准，验收以这个为准。完成前必须逐项检查，不满足则继续实现。）
-执行审计: tmp/ty-context/plan-acceptance/<plan>-local-audit.md（临时 progress state，非 Context/proof）
-可多开agent，agent名额不够了就关掉不用的。
-如果 Superpowers 未安装，先按当前平台官方 Superpowers 安装路径安装；若安装被权限/网络/平台限制阻塞，写入执行审计，不得把阻塞当完成。
-如果 Superpowers 已安装，使用 Superpowers 执行本任务：
-- 先读完整验收清单，验收以它为准；compact prompt 只负责 direction/priority/recovery navigation
-- 若实施计划不够可执行，用 superpowers:writing-plans 转成 bite-sized implementation plan
-- 有 subagent 支持时优先用 superpowers:subagent-driven-development；否则用 superpowers:executing-plans
-- 行为变更使用 superpowers:test-driven-development；先写失败测试并观察失败，再写最小实现
-- review / finish 不能覆盖完整验收清单；完整验收清单不满足则继续实现
-- 每轮执行后更新 local audit，记录 AC 状态、当前证据、命令结果、blocker、deferred/narrowed scope、无效证据
-<验收清单>
-```
-
-For English requests, use this shape:
-
-```text
-Plan: tmp/ty-context/plan-acceptance/<plan>.md (implementation/source plan, not acceptance proof)
-Full checklist: tmp/ty-context/plan-acceptance/<plan>-acceptance-checklist.md (complete acceptance standard; acceptance is judged against it; every item must be checked before completion)
-Local audit: tmp/ty-context/plan-acceptance/<plan>-local-audit.md (temporary execution/progress state, not Context or proof)
-You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
-If Superpowers is not installed, install it through the current platform's official Superpowers installation path first; if installation is blocked by permissions, network or platform limits, record it in local audit and do not treat the blocker as completion.
-If Superpowers is installed, Use Superpowers for this task:
-- Read the full checklist first; acceptance is judged against it, while the compact prompt only provides direction, priority and recovery navigation.
-- If the implementation plan is not executable enough, use superpowers:writing-plans to convert it into a bite-sized implementation plan.
-- Prefer superpowers:subagent-driven-development when subagents are available; otherwise use superpowers:executing-plans.
-- Use superpowers:test-driven-development for behavior changes; write a failing test, observe it fail, then write the minimal implementation.
-- review / finish cannot override the full checklist; if the full checklist is not satisfied, continue implementation.
-- update local audit after each execution round with AC status, current evidence, command results, blockers, deferred/narrowed scope and invalid evidence.
-<acceptance checklist>
-```
-
-This resource lifecycle line is part of the generated execution prompt. It authorizes parallel decomposition for the future executor while requiring unused agents to be closed when slots run low.
-
-## Non-Scope
-
-Do not execute the plan unless the user separately asks for execution.
-
-Do not modify product code, migrations, UI, API, tests, runtime artifacts, or durable Context while using this Skill.
-
-Do not run long validation, external probes, browser flows, cloud smoke tests, database writes, deployment commands, or other side-effect commands unless the user explicitly asks for validation execution.
-
-Do not mark any goal complete. This Skill defines acceptance; it does not complete acceptance.
-
-Do not lower the plan target to match current implementation.
-
-## Trigger Conditions
-
-Use this Skill when the user asks for any of the following:
-
-- Give a plan, Markdown file, RFC, milestone, or implementation proposal an acceptance checklist.
-- Combine project durable Context with a long-task plan to produce acceptance criteria.
-- Convert a long-range task plan into a checklist for Codex goal/target mode.
-- Generate a completion definition for "execute this plan until done."
-- Check whether a plan is missing acceptance conditions.
-- Combine user objective, plan steps, project Context, code entry points, and verification paths into an executable acceptance matrix.
-
-Typical trigger phrases:
-
-```text
-acceptance checklist for this plan
-goal-mode prompt for this implementation plan
-target-mode prompt for this plan
-completion definition for this plan
-long-task plan acceptance
-audit this plan for acceptance criteria
-整理这份方案，输出一份目标模式文本给我
-整理方案输出目标模式文本
-为这份方案生成验收清单
-方案验收清单
-长程任务方案验收
-实施计划验收清单
-结合项目 context 梳理方案验收
-为这份 md 生成目标模式验收文本
-把这份 md 整理成验收清单
-```
-
-Do not trigger from standalone broad phrases such as `goal mode`, `target mode`, `acceptance criteria`, `completion definition`, `目标模式文本`, `验收标准`, or `完成定义` unless the same user request also identifies a plan-like source.
-
-## Input Priority
-
-Build the checklist from these sources, in order:
-
-1. User's current instruction.
-2. The referenced or pasted plan, including both documents when the user provides a two-document upstream input packet.
-3. Relevant durable project Context under `project_context/**`.
-4. Repository guidance such as `AGENTS.md`, `README.md`, `DESIGN.md`, and relevant local Skills.
-5. Current code and tests, only to identify real surfaces, commands, routes, schemas, artifacts, entry points, and likely verification paths.
-6. Existing reports or artifacts, only to identify required evidence and invalidation risks. Existing artifacts are not proof unless the user explicitly asks to audit current completion.
-
-If plan and Context conflict, preserve the conflict in the checklist. Do not silently choose the easier side.
-
-## Upstream Input Packet
-
-When the user provides two related documents, treat them as a two-document upstream input packet when their roles match these shapes:
-
-- `Development Plan / 开发方案`: execution direction for implementation. It can contain the original requirement source or a summary of the original plan so later implementation does not shrink the target.
-- `Acceptance and Tests / 验收清单和测试用例`: target-mode acceptance input packet. It can contain the acceptance matrix, test requirements, real product paths, evidence layers, invalid evidence rules, state-machine rules, local audit requirements and blockers.
-
-Rules:
-
-- Do not create a third upstream artifact. Preserve the source input documents and compile a separate full checklist.
-- If only one plan-like source is provided, keep the existing single-plan flow.
-- If both documents are provided, read both before deciding whether to reuse or generate the full checklist.
-- The development plan is execution direction, not proof. The acceptance-and-tests document is acceptance input, not proof.
-- In the full checklist's `Plan source` and per-row `Source` fields, preserve whether a requirement came from the development plan, the acceptance-and-tests document, user instruction, project Context, code contract or verification risk.
-- If the development plan is not bite-sized enough for direct execution, the generated prompt must require `superpowers:writing-plans` before implementation.
-- This two-document upstream input packet path is strict mode. The compiler must be able to parse the objective or original requirement source summary, implementation/source plan, acceptance items, required evidence, verification methods, fail conditions, required tests or explicit test scope, core paths or explicit non-UI/runtime scope, state-machine rules, invalid evidence rules, local audit expectations and blockers or explicit no-blocker statement.
-- If any required field cannot be fully parsed from the two documents, stop after preserving the inputs. Do not generate a checklist or goal/target-mode prompt. Tell the user which missing required fields must be added to `Development Plan / 开发方案` or `Acceptance and Tests / 验收清单和测试用例`.
-
-## Step 1: Materialize The Plan Under `tmp/ty-context/plan-acceptance/`
-
-Before writing the checklist, write the user-specified source input into the repository `tmp/ty-context/plan-acceptance/` directory.
-
-Rules:
-
-- If `tmp/ty-context/plan-acceptance/` does not exist, create it.
-- If the user references a file outside `tmp/ty-context/plan-acceptance/`, copy its current content into `tmp/ty-context/plan-acceptance/<safe-plan-name>.md`.
-- If the user references a file already under `tmp/ty-context/plan-acceptance/`, use that path directly unless the user asks for a new copy.
-- If the user pasted the plan text, write the pasted plan exactly into `tmp/ty-context/plan-acceptance/<safe-plan-name>.md`.
-- If the user pasted or referenced a two-document upstream input packet, write `Development Plan / 开发方案` and `Acceptance and Tests / 验收清单和测试用例` as separate preserved source inputs under stable readable filenames.
-- Preserve the plan content. Do not summarize, normalize, reorder, translate, or edit it while materializing it.
-- Use a stable readable filename derived from the plan title, source filename, or user topic. Use lowercase letters, digits, hyphens, and `.md`.
-- If the source plan cannot be found or read, stop and report the missing source. Do not invent a plan.
-- The materialized source input is temporary implementation/source input. It is not durable Context, not acceptance proof and not proof that any acceptance item passed.
-
-Recommended paths:
-
-```text
-tmp/ty-context/plan-acceptance/<plan-slug>.md
-tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md
-tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md
-```
-
-The local audit path is for the future goal/target-mode executor. This compiler may require the prompt to maintain it, but the file is a temporary recovery cache and not proof that any acceptance item passed.
-
-## Step 2: Reuse Any Explicit Plan-Provided Checklist
-
-After materializing the plan, inspect it for an explicit concrete acceptance checklist and any explicit test requirements before generating a new checklist.
-
-Plan-provided checklist reuse applies only when the plan contains a clearly labeled checklist or checklist table section, such as `Acceptance Checklist`, `Acceptance Criteria`, `验收清单`, `验收标准`, or equivalent heading, and that section contains concrete acceptance items rather than only saying that acceptance is needed.
-
-For a two-document upstream input packet, the `Acceptance and Tests / 验收清单和测试用例` document is the preferred acceptance source, but it is not automatically a frozen verbatim full checklist. Reuse it as the full checklist only if it already includes enough acceptance structure for target-mode execution: AC ID, scope, required evidence, verification method, fail condition, state-machine rules and invalid evidence rules. If any of those are missing, strict mode applies: stop, list the missing required fields, and ask the user to provide a complete acceptance-and-tests packet.
-
-When a plan-provided checklist is found:
-
-- Copy the plan-provided acceptance checklist section into `tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md` as the full checklist.
-- Preserve the extracted checklist verbatim, including the original language, item wording, order, IDs, Markdown tables, checkboxes, evidence notes, and blocker notes.
-- Do not derive, strengthen, reorder, translate, normalize, merge, split, or add acceptance items.
-- Do not prepend the generated `Acceptance Contract`, checklist table, self-test, or false-completion traps to the full checklist file when reusing a plan-provided checklist.
-- If multiple explicit checklist sections exist, copy all of them into the full checklist file in source order.
-- If the plan also includes explicit test requirements, such as `Required tests`, `Automated tests`, `Test Plan`, `必须新增/补强的自动化测试`, `测试文件`, or equivalent concrete test sections, copy those test requirements verbatim into the full checklist file as plan-provided acceptance evidence. These test requirements are acceptance evidence, not generated additions.
-- Keep the copied plan file and full checklist file separate, even if the checklist already appears inside the plan.
-- Continue to read relevant Context only as needed to explain ambiguities, conflicts, the goal/target-mode prompt, and any required local-audit or false-completion guidance. Do not use Context to expand the reused checklist unless the user separately asks for an audit or rewrite.
-- If the plan-provided checklist is too large for the 3850-character prompt budget, keep it intact in the full checklist file and make the prompt reference that file as the acceptance authority; do not invent a compact replacement checklist with new criteria.
-- Skip Steps 5 and 6 for the full checklist file unless the user separately asks for a checklist audit or rewrite.
-
-When no explicit concrete plan-provided checklist exists, continue with the generated-checklist flow below.
-
-When a two-document upstream input packet exists but either document is incomplete, do not continue with the generated-checklist flow below. Strict mode means incomplete two-document input cannot be repaired by inference. Do not generate a checklist or goal/target-mode prompt; report the missing required fields and wait for the user to provide a complete packet.
-
-When a plan already includes explicit test requirements but not a full acceptance checklist:
-
-- Use those plan-provided test requirements as the source of truth for the generated checklist's `Required automated tests / 必须新增或补强的自动化测试` section.
-- Preserve concrete test file paths, test names, behavior descriptions, commands, and failure notes from the plan.
-- Do not replace them with generic AC10 wording, do not create an unrelated test system, and do not invent competing test lists.
-- If the plan's test requirements are broad but concrete enough to preserve, keep the original wording and add only the minimum acceptance mapping needed to show which AC each test supports.
-
-## Step 3: Read Relevant Project Context
-
-Read only the Context needed for the plan's impacted surfaces. Use Context to identify what the project says the system should mean.
-
-Use code and tests to identify current implementation surfaces and verification commands. Code describes current state; it must not silently redefine the plan's completion definition.
-
-Extract:
-
-- Product or system contract.
-- Module boundaries.
-- API, data, artifact, runtime, UI, and test contracts.
-- Validation and deployment paths.
-- Security, privacy, redaction, and environment rules.
-- Known non-goals and forbidden dependencies.
-- Existing implementation entry points.
-
-## Step 4: Run The Context Confirmation Gate
-
-After reading the plan and relevant Context, decide whether generating an acceptance checklist would require guessing or silently accepting many durable fact changes. If yes, stop and ask the user to confirm details before continuing.
-
-Trigger this gate when any of these apply:
-
-- The plan appears to add or change many long-term facts, such as product ownership, module boundaries, API/schema semantics, data contracts, state semantics, verification/deployment entry points, UI information architecture, security/privacy rules, or cross-domain dependency rules.
-- The plan would likely require updates across multiple Context roles or areas, or more than a small number of durable Context files.
-- The plan conflicts with current Context and the conflict changes the completion definition rather than only implementation details.
-- The plan uses broad or strategic language whose meaning cannot be made falsifiable from the plan and Context alone, such as "rebuild the whole architecture", "unify every module", "production-grade", "fully integrated", "maximize capability", `重构整体架构`, `统一所有模块`, `生产级`, `长期方案`, `完全接入`, or similar.
-- The acceptance outcome depends on choosing between product/architecture alternatives that the user has not explicitly chosen.
-- External approvals, credentials, runtime environments, legal/compliance constraints, paid/provider access, or irreversible operational effects materially change what can be accepted.
-- You judge that proceeding would encode a durable assumption the user probably expects to review.
-
-When the gate triggers:
-
-- Do not compile the final checklist, write the checklist file, or generate the goal/target-mode prompt yet.
-- Ask 1-3 concise questions focused on the blocking durable assumptions.
-- Include the materialized plan path if already written.
-- State the specific Context files or Context roles that made confirmation necessary.
-- Offer a concrete default only when it is safe and reversible; otherwise ask for an explicit decision.
-- Resume from Step 3 after the user answers.
-
-Do not trigger this gate merely because the plan is large. If the Context impact is clear, bounded, and the checklist can represent the durable Context updates as acceptance items without guessing, continue.
-
-## Step 5: Compile The Acceptance Contract
-
-Before the detailed checklist, write a compact contract:
-
-```markdown
-## Acceptance Contract
-
-- Plan source: `tmp/ty-context/plan-acceptance/<plan>.md`
-- User objective: <objective>
-- Completion definition: <what must be true>
-- Core surfaces: <code/API/UI/data/runtime/artifact/test/context/etc.>
-- Explicit non-goals: <items>
-- External blockers: <accounts/session/credentials/network/cloud/manual approval/etc.>
-- Evidence standard: <accepted proof types>
-- Current-state claims: <which "current", "generated", "synced", "tested", "accepted" or runtime claims require current evidence>
-- Evidence ledger required: <whether the checklist or future executor must maintain current evidence by item>
-- Invalid completion evidence: <stale artifacts, code-only edits, partial tests, unexercised runtime, mismatched read paths or other evidence that cannot prove completion>
-```
-
-If the plan uses broad words such as `all`, `complete`, `maximum`, `maximized`, `accepted`, `formal`, `production`, `real`, `current`, or `verified`, convert them into explicit inventory and evidence requirements.
-
-## Step 6: Build The Full Acceptance Checklist
-
-Treat the checklist as the set of falsifiable acceptance items a future executor must satisfy. It is not a progress log.
-
-Use this generated-checklist step only when Step 2 did not find an explicit concrete plan-provided checklist. If Step 2 found one, the full checklist file is the verbatim extracted checklist and this step is skipped.
-
-Create a checklist table with these columns:
-
-```markdown
-| ID | Acceptance item | Source | Scope | Required evidence | Verification method | Fail / not accepted if |
-|---|---|---|---|---|---|---|
-```
-
-Column rules:
-
-- `ID`: stable ID such as `AC-01`; group by workstream if useful.
-- `Acceptance item`: one atomic condition that must be true.
-- `Source`: user instruction, plan section, Context file, code contract, schema, API, UI, test, or risk note.
-- `Scope`: one of `core`, `conditional`, `blocked-external`, `out-of-scope`, `nice-to-have`.
-- `Required evidence`: exact proof required.
-- `Verification method`: concrete command, check, inspection path, API call, UI check, artifact validation, or manual proof.
-- `Fail / not accepted if`: concrete invalidation case.
-
-Each item must be evidence-bound and falsifiable. Split combined requirements into separate rows.
-
-For current-state or evidence-heavy plans, also require the future executor to maintain an Evidence Ledger table:
-
-```markdown
-| AC | Expected state | Current observed state | Current evidence | Evidence location / API / UI / command | Conclusion | Gap / blocker |
-|---|---|---|---|---|---|---|
-```
-
-Allowed `Conclusion` values:
-
-- `proven`
-- `unproven`
-- `partial`
-- `invalidated`
-- `stale-evidence`
-- `runtime-disconnected`
-- `implementation-drift`
-- `blocked`
-- `deferred-by-explicit-scope`
-
-Missing ledger evidence means incomplete, not complete. Do not let missing evidence, old evidence, partial evidence or evidence from a different read path satisfy a current-state claim.
-
-All core AC status starts as `unknown / not_run` unless current required evidence has been inspected. Only fresh required evidence can support `complete`. Any fresh browser / API / runtime / data / test contradiction must immediately downgrade the affected AC and overall status, and the local audit must record the contradiction as invalidating evidence. Do not preserve a previous complete status after contradictory current evidence appears.
-
-### Required Automated Tests / 必须新增或补强的自动化测试
-
-Every generated full checklist must include a `Required automated tests / 必须新增或补强的自动化测试` section. Test requirements are acceptance evidence: a future executor cannot mark a relevant implementation item complete when required test evidence is missing.
-
-No fourth artifact: keep these requirements inside `<plan-slug>-acceptance-checklist.md`. Do not create `tmp/ty-context/plan-acceptance/<plan-slug>-test-requirements.md` or another standalone test requirements file.
-
-Use this table shape when tests are required:
-
-```markdown
-## Required automated tests / 必须新增或补强的自动化测试
-
-| Test file path | Test name or behavior description | Covered acceptance item(s) | Verification command | Failure condition | Source |
-|---|---|---|---|---|---|
-```
-
-Rules:
-
-- If the plan already includes explicit test requirements, use those plan-provided test requirements as the source of truth. Preserve the plan's test file path, test name or behavior description, verification command and failure condition when present.
-- Do not replace plan-provided test requirements with generic AC10, do not invent a separate test taxonomy, and do not add unrelated tests merely because a generic category exists.
-- If no explicit test section exists, derive required tests from the plan's behavior changes, risk, Context contracts and real code/test surfaces.
-- If an exact test name cannot be inferred safely, write a behavior-level test description and do not invent exact test names.
-- Each required test row must identify the covered acceptance item(s), the verification command, and the failure condition that blocks acceptance.
-- For behavior changes, test requirements should identify expected RED/GREEN or pass/fail signal when that can be inferred safely.
-- When a test is auxiliary evidence only, state which acceptance layer it supports and what it cannot prove.
-- If no new or strengthened automated tests are required, state that explicitly with the reason and the acceptance items covered by existing verification.
-- The local audit must record each required test's command, result and failure reason when it is run or when it remains blocked.
-
-## Hard Blocker Handling
-
-Treat any unresolved required blocker as non-completion. A checklist may describe blocked acceptance work, but blocked work is still not accepted until the required evidence exists.
-
-Use `blocked-external` only when the item is required for full completion but depends on unavailable user input, credentials, account/session access, manual approval, external environment state, provider availability, legal/compliance decision, or another dependency the future executor cannot satisfy locally.
-
-For every `blocked-external` item, state:
-
-- The exact missing evidence.
-- Why the future executor cannot produce it locally.
-- The required user, owner, external system, or approval action.
-- The fallback or degraded path, if the plan or Context allows one.
-- The acceptance impact if the blocker remains unresolved.
-
-Do not mark blocked work as `out-of-scope`, `conditional`, or `nice-to-have` merely because it is hard or currently unavailable. Do not treat partial local work, preparation, mocks, old evidence, or an unexercised fallback as completion for a blocked required item.
-
-The generated goal/target-mode prompt must tell the future executor:
-
-- If any executable `core` item remains, continue working it before asking the user to resolve blockers.
-- If the only remaining incomplete required items are hard blockers that cannot be satisfied locally, pause and wait for the user or external owner instead of marking the goal complete.
-- The handoff must list blocker cause, missing evidence, acceptance impact, and the exact user/external action needed to resume.
-
-## Minimal User Blocker Protocol
-
-The generated goal/target-mode prompt must make user questions minimal and action-oriented when the plan says to do as much locally as possible.
-
-Before asking the user, the future executor must complete safe self-service discovery that is available in the repository or current environment:
-
-- Read relevant project Context, code, docs, tests, runtime examples, local artifacts and official documentation when current external rules matter.
-- Use local CLIs, APIs, Browser/Chrome/Computer Use or other tools only when appropriate, safe and allowed by the current tool and security policy.
-- Do not bypass user approval, account boundaries or sensitive-operation rules.
-
-When user input is still required, the blocker request must be the smallest concrete action list, not a research assignment. It must include:
-
-- What was already tried.
-- What is still missing.
-- The exact page, menu, path, field, button, command input or setting when it can be identified.
-- The minimum value or action the user needs to provide.
-- Sensitive material the user should not send, such as cookies, full pages, HAR files, password-store data, raw payloads, unrelated account data, screenshots when a value-only request is enough, or secrets in chat when a safer runtime-only setup path exists.
-- Acceptance impact if the blocker remains unresolved.
-- Allowed fallback, deferred or narrowed-scope option, if the plan or Context permits one.
-
-Do not replace this with broad requests such as "provide the token", "send the secret value" or "give me the configuration credentials" when a narrower page, field, runtime setup step or delegated user action would satisfy the blocker.
-
-## Generic Acceptance Dimensions
-
-Include only dimensions relevant to the plan. Do not mechanically add irrelevant categories.
-
-Consider these generic dimensions:
-
-- Objective and completion definition.
-- Scope inventory and coverage.
-- Domain / project Context conformance.
-- Code implementation behavior.
-- API or interface contract.
-- Data model, schema, migration, or persistence.
-- Runtime state, configuration, session, credential, environment, or degraded behavior.
-- Artifact generation, schema, freshness, provenance, and acceptance.
-- UI or user-visible projection.
-- Real product path or core path, including page/user flow, API route/probe, runtime/worker/job/artifact path, and whether Browser/Chrome verification is required.
-- Async job, worker, scheduler, queue, or background process.
-- Security, privacy, redaction, secrets, and access control.
-- Observability, logs, diagnostics, and operator visibility.
-- Performance, timeout, boundedness, pagination, and resource budget.
-- Backward compatibility and non-regression.
-- Failure states, blocked states, retries, recovery, and next actions.
-- Unit, integration, contract, smoke, browser, cloud, or production-like validation.
-- Documentation or durable Context update, only when the plan requires a durable fact change.
-
-## Evidence Layer Separation
-
-For evidence-heavy or validation-heavy plans, keep these layers separate:
-
-```text
-infrastructure implemented
-runtime configured
-runtime exercised
-artifact generated
-artifact accepted by validator
-API/UI reflects accepted evidence
-browser path verified
-final gate/check command passed
-```
-
-Do not merge these layers unless the plan explicitly treats them as one.
-
-For runtime, provider, artifact or external-evidence acceptance, distinguish adapter or infrastructure implementation, formal artifact production, scope alignment, redaction, replayability, validator acceptance, registry/API/UI projection, full gate/check success and any explicitly narrowed or deferred scope. A fallback path must be exercised before it can prove full completion.
-
-Examples of generic false completion:
-
-- Code exists, but runtime behavior was not exercised.
-- Artifacts exist, but current validators reject them.
-- Tests pass, but the required API/UI/runtime proof was not checked.
-- A partial sample ran, but the plan required full inventory coverage.
-- A document was updated, but the system state did not change.
-- A fallback exists in code, but the fallback was not configured or exercised.
-- Old, partial, smoke, dry-run or research evidence exists, but the current acceptance contract requires full current proof.
-
-## Scope Labels
-
-Use these exact labels:
-
-- `core`: required to call the plan complete.
-- `conditional`: required only when a stated condition applies.
-- `blocked-external`: required for full completion but depends on unavailable external input.
-- `out-of-scope`: explicitly excluded by the user or plan.
-- `nice-to-have`: useful but not required; use sparingly.
-
-Do not mark an item out of scope only because it is difficult.
-Do not mark a `blocked-external` item complete until its required evidence exists.
-
-## Conflict Handling
-
-If the plan, Context, and code disagree, add a conflict table:
-
-```markdown
-| Conflict | Plan says | Context says | Code currently does | Acceptance impact | Required resolution |
-|---|---|---|---|---|---|
-```
-
-Do not resolve conflict by silently following current code.
-
-## False-Completion Traps
-
-After the checklist, include traps that a future executor must not mistake for completion.
-
-Use generic wording. Do not add business-specific traps to the Skill itself.
-
-Template:
-
-```markdown
-## False-Completion Traps
-
-- <activity> is not enough unless <acceptance proof> also exists.
-- <partial proof> cannot prove <full acceptance item>.
-- <old/stale/mismatched evidence> cannot prove current completion.
-- <surface A> passing does not prove <surface B> unless the checklist links them.
-```
-
-For evidence-ledger plans, keep the traps generic and cover these cases when relevant:
-
-- Code-only changes without current execution or acceptance evidence.
-- UI/API shell behavior without the backing data, runtime or artifact evidence required by the checklist.
-- UI-facing acceptance without the real page path and matching user-visible state.
-- Stale artifacts or stale runtime evidence.
-- Evidence from a mismatched read path, service path, artifact path or runtime instance.
-- Unexercised runtime or unexercised fallback behavior.
-- Partial tests, smoke-only checks or dry runs when the plan requires broader current proof.
-- API/UI/data/test contradictions that remain unresolved.
-
-For UI-facing acceptance, component / viewmodel / mock / unit test evidence is insufficient unless the real page path is opened and the user-visible state matches the acceptance item.
-
-## Suggested Execution Order
-
-Suggest an execution order that prioritizes the highest-risk proof first:
-
-1. Confirm scope inventory and completion definition.
-2. Confirm schemas/contracts and invalid evidence rules.
-3. Implement or repair the core path.
-4. Produce or inspect required runtime/artifact/API/UI evidence.
-5. Run contract/integration/regression checks.
-6. Run build/typecheck/lint/smoke checks.
-7. Update temporary checklist status only if the user asked for status tracking.
-
-Do not put low-signal checks before the core acceptance proof when the plan is evidence-driven.
-
-## Checklist Self-Test
-
-Every generated checklist must pass this self-test:
-
-```markdown
-## Checklist Self-Test
-
-- [ ] Every original plan section is mapped to at least one acceptance item or explicitly marked non-goal.
-- [ ] Every broad word such as all / maximum / complete / formal / production / verified is converted into inventory + evidence.
-- [ ] Every core item has a verification method.
-- [ ] Every evidence item defines invalid evidence.
-- [ ] Code, API, UI, data, runtime, artifacts, and tests are separated when they prove different things.
-- [ ] External blockers are separated from local remaining work.
-- [ ] Hard blockers are treated as non-completion, with required user/external action and pause conditions.
-- [ ] Current implementation was not used to reduce the user's completion definition.
-- [ ] The checklist can be handed to another Codex session without hidden assumptions.
-```
-
-## Goal/Target-Mode Prompt Generation
-
-After reusing a plan-provided checklist or compiling a generated checklist, produce a paste-ready goal/target-mode prompt.
-
-Hard requirements:
-
-- The prompt must be no longer than 3850 characters including line breaks. Treat 3850 as the effective hard budget and preserve information density; do not drop required paths, core acceptance categories, blocker rules, evidence rules or false-completion traps merely to be short.
-- The first line must identify the plan path.
-- Use `实施计划: <path>` for Chinese prompts and `Plan: <path>` for English prompts. The line must say the plan is the implementation/source plan and not acceptance proof.
-- The prompt must identify the full checklist path immediately after the plan path and say it is the complete acceptance standard. Chinese prompts must include this exact sentence: `该文件是完整验收标准，验收以这个为准。完成前必须逐项检查，不满足则继续实现。` English prompts must say the full checklist is the complete acceptance standard, acceptance is judged against it, and every item must be checked before completion.
-- The prompt must identify a local audit path, normally `tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md`, and require the future executor to read it before resuming, keep it current during execution, and use it only as target-mode acceptance progress state.
-- After the plan/checklist/audit paths, include a resource lifecycle instruction: `可多开agent，agent名额不够了就关掉不用的。` for Chinese prompts or `You may use multiple agents; if agent slots run low, close idle or unnecessary agents.` for English prompts.
-- The prompt must include mandatory inputs: original requirement source or original plan summary, implementation/source plan, full acceptance checklist, local audit, relevant Context, and required tests / core paths.
-- The prompt must include a Superpowers execution block. If Superpowers is not installed, tell the executor to install it through the current platform's official Superpowers installation path; if installation is blocked by permissions, network or platform limits, record it in local audit and do not treat the blocker as completion. If Superpowers is installed, Use Superpowers for this task.
-- The Superpowers block must require: read the full checklist first and make it the acceptance authority; use `superpowers:writing-plans` when the plan is not executable enough; prefer `superpowers:subagent-driven-development` when subagents are available; otherwise use `superpowers:executing-plans`; use `superpowers:test-driven-development` for behavior changes; use `superpowers:verification-before-completion` before any completion claim; review / finish cannot override the full checklist; update local audit after each execution round.
-- The remaining content must be the acceptance checklist or a compact version of it.
-- The prompt must be self-contained enough for goal/target-mode execution.
-- If the prompt uses a compact checklist summary, say the full checklist owns details and acceptance authority; the compact summary owns direction, priority and recovery navigation; overlap is allowed; conflicts are resolved in favor of the full checklist.
-- The prompt must require the local audit to record overall status (`complete`, `incomplete`, `blocked` or `narrowed-scope-complete`), each core AC status and current evidence, commands with result/time/failure reason, artifact or evidence paths, blockers and missing evidence, acceptance impact, explicit deferred or narrowed scope, and stale/partial/smoke/dry-run/research evidence that cannot prove full completion.
-- The prompt must require local audit status to start from `unknown / not_run`; only fresh required evidence can mark an AC complete. If any fresh browser / API / runtime / data / test contradiction appears, downgrade the affected AC and overall status and record invalidating evidence.
-- The prompt must state that UI-facing acceptance requires a real page path and matching user-visible state; component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
-- The prompt must say that local audit is not Context, not product-quality proof, not a global task manager, and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`.
-- The prompt must say that when a Task Contract or workflow-contract `plan.md` exists, each acceptance item execution still follows it and the repository's Tiny Context workflow contract.
-- Do not include explanatory preface inside the prompt.
-- Do not include Markdown tables inside the prompt if they make it too long.
-- Prefer short numbered items over verbose prose.
-- If the full checklist is too large, write the full checklist to `tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md`, then compress the goal/target-mode prompt by increasing information density while preserving all core acceptance categories.
-- If the full checklist came from a plan-provided checklist and is too large, keep the extracted checklist unchanged in the full checklist file and compress the prompt by referencing the full checklist path, not by rewriting or adding criteria.
-- The compact prompt may reference the full checklist path, but it must still include the core completion criteria directly and state that the summary is direction/priority/recovery navigation, not the acceptance authority.
-- Compact prompts must not expand long test lists. AC10 must reference the Required automated tests section in the full checklist and state that behavior changes still use `superpowers:test-driven-development`.
-
-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 为准。
-mandatory inputs：原始需求源/原始方案摘要、实施计划、完整验收清单、local audit、relevant Context、required tests / core paths。
-
-如果 Superpowers 未安装，先按当前平台官方 Superpowers 安装路径安装；若安装被权限/网络/平台限制阻塞，写入执行审计，不得把阻塞当完成。
-如果 Superpowers 已安装，使用 Superpowers 执行本任务：
-- 先读完整验收清单，验收以它为准
-- 若实施计划不够可执行，用 superpowers:writing-plans 转成 bite-sized implementation plan
-- 有 subagent 支持时优先用 superpowers:subagent-driven-development；否则用 superpowers:executing-plans
-- 行为变更用 superpowers:test-driven-development；先写失败测试并观察失败，再写最小实现
-- 完成声明前用 superpowers:verification-before-completion 按完整 checklist 和 fresh evidence 做 gate
-- review / finish 不能覆盖完整验收清单；不满足则继续实现
-- 每轮执行后更新 local audit，记录 AC 状态、证据、命令结果、blocker、deferred/narrowed scope、无效证据
-
-验收清单：
-AC1 <核心完成定义，包含验收证据>
-AC2 <范围/清单/覆盖要求>
-AC3 <Context/架构/边界要求>
-AC4 <核心实现行为要求>
-AC5 <数据/API/接口/契约要求>
-AC6 <运行态/配置/外部依赖/阻塞分类要求>
-AC7 <artifact/evidence/schema/freshness/provenance 要求>
-AC8 <UI/用户可见/API 投影一致性要求>
-AC9 <安全/隐私/脱敏/secret 要求>
-AC10 测试要求：按完整验收清单的 `Required automated tests / 必须新增或补强的自动化测试` section 执行；compact prompt 不展开长测试列表；行为变更仍用 superpowers:test-driven-development。
-AC11 <文档/Context 更新要求，仅在计划要求时执行>
-AC12 维护执行审计：恢复执行先读 audit；记录总体状态、每个 AC 当前证据、命令/结果/时间、每个 required test 的 command/result/failure reason、artifact/evidence 路径、blocker、deferred/narrowed scope、不能证明 full completion 的旧/部分/smoke/dry-run/research 证据；audit 不是 Context、完成证明、全局任务管理器，也不替代 Task Contract 或流程契约 plan.md。
-AC13 最小用户卡点：问用户前先完成安全自助发现；需要用户介入时只给最小动作清单，写明已尝试、缺失项、具体页面/菜单/字段/按钮、最小值/动作、不要发送的敏感信息、验收影响、fallback/deferred。
-AC14 完成前审计：逐条对照实施计划和完整 checklist；每个 core 项必须有当前证据；未跑验证必须明示；有可继续执行的 core 项不得标记完成；外部/强卡点必须写明原因、缺失证据、验收影响和下一步；若剩余未完成项只有无法本地解决的强卡点，暂停并等待用户/外部 owner，不能标记目标完成。
-AC15 状态机：core AC 初始 unknown / not_run；只有 fresh required evidence 才能 complete；任何 fresh browser / API / runtime / data / test contradiction 必须 downgrade the affected AC and overall status，并在 audit 记录 invalidating evidence。
-AC16 UI-facing acceptance：必须打开 real page path 且用户可见状态匹配；component / viewmodel / mock / unit test 只算辅助证据，除非完整 checklist 另有明确说明。
-
-禁止把以下内容当完成：只改代码、只更新计划、只跑部分测试、只生成旧/部分/不被当前契约接受的证据、只完成基础设施但未完成验收证据、runtime 未配置/未演练、artifact 未被 validator 接受、API/UI 未反映验收证据、fallback 未演练、强卡点未解除、API/UI/数据/测试之间仍矛盾。
-```
-
-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; acceptance is judged against it; every item must be checked 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 only direction, priority and recovery navigation; overlap with the full checklist is allowed, and the full checklist wins conflicts.
-Mandatory inputs: original requirement source or original plan summary, implementation/source plan, full checklist, local audit, relevant Context, and required tests / core paths.
-
-If Superpowers is not installed, install it through the current platform's official Superpowers installation path first; if installation is blocked by permissions, network or platform limits, record it in local audit and do not treat the blocker as completion.
-If Superpowers is installed, Use Superpowers for this task:
-- Read the full checklist first; acceptance is judged against it.
-- If the plan is not executable enough, use superpowers:writing-plans for a bite-sized implementation plan.
-- Prefer superpowers:subagent-driven-development when subagents are available; otherwise use superpowers:executing-plans.
-- Use superpowers:test-driven-development for behavior changes; write a failing test, observe failure, then implement minimally.
-- Use superpowers:verification-before-completion before any completion claim, checking the full checklist against fresh evidence.
-- review / finish cannot override the full checklist; if unsatisfied, continue implementation.
-- update local audit after each execution round with AC status, evidence, command results, blockers, deferred/narrowed scope and invalid evidence.
-
-Acceptance checklist:
-AC1 <core completion definition with required evidence>
-AC2 <scope inventory and coverage>
-AC3 <Context / architecture / boundary conformance>
-AC4 <core implementation behavior>
-AC5 <data / API / interface / contract requirements>
-AC6 <runtime / configuration / external dependency / blocker classification>
-AC7 <artifact / evidence / schema / freshness / provenance requirements>
-AC8 <UI / user-visible / API projection consistency>
-AC9 <security / privacy / redaction / secret handling>
-AC10 Test requirements: follow the full checklist's `Required automated tests / 必须新增或补强的自动化测试` section; the compact prompt must not expand long test lists; behavior changes still use superpowers:test-driven-development.
-AC11 <documentation / Context updates only when required by the plan>
-AC12 Maintain local audit: read it before resuming; record overall status, every AC's current evidence, commands/results/time, each required test's command/result/failure reason, artifact/evidence paths, blockers, deferred/narrowed scope, and stale/partial/smoke/dry-run/research evidence that cannot prove full completion; audit is not Context, completion proof, a global task manager, or a replacement for Task Contract or workflow-contract plan.md.
-AC13 Minimal user blocker protocol: before asking the user, complete safe self-service discovery; when user action is needed, provide only the smallest action list with what was tried, missing item, exact page/menu/path/field/button, minimum value/action, sensitive material not to send, acceptance impact, and fallback/deferred option.
-AC14 Final audit: compare every item against the plan and full checklist; every core item needs current evidence; missing validation must be stated; any executable core item left open means the task is not complete; external or hard blockers need cause, missing evidence, acceptance impact, and next action; if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
-AC15 State machine: core ACs start as unknown / not_run; only fresh required evidence can mark complete; any fresh browser / API / runtime / data / test contradiction must downgrade the affected AC and overall status and be recorded as invalidating evidence.
-AC16 UI-facing acceptance: open the real page path and confirm the user-visible state matches; component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
-
-Do not count these as completion: code-only changes, plan-only updates, partial tests, stale or partial evidence, infrastructure without acceptance proof, runtime not configured/exercised, artifact not accepted by validator, API/UI not reflecting accepted evidence, unexercised fallback, unresolved hard blockers, or contradictions between API/UI/data/tests.
-```
-
-Before final response, check the prompt length. If it exceeds 3850 characters, compress by tightening wording and referring to the full checklist path while preserving required paths, core AC categories, blocker/evidence rules and false-completion traps; then check again.
-
-## Final Response Requirements
-
-For completed checklist runs, the final response must include:
-
-- `tmp/ty-context/plan-acceptance/` plan path.
-- Full checklist path if a full checklist file was written.
-- Whether the full checklist was reused from a plan-provided checklist or generated by this Skill.
-- The paste-ready goal/target-mode prompt in a code block.
-- Any unresolved ambiguity that affects checklist accuracy.
-
-If the Context confirmation gate triggers, the response must ask for the needed confirmation instead of including the checklist or goal/target-mode prompt.
-
-Do not claim that any acceptance item has passed unless the user explicitly asked for a current completion audit and current evidence was inspected.
-
-## Forbidden Behaviors
-
-Do not include concrete business-domain logic in this Skill.
-
-Do not hardcode project-specific provider names, API names, UI names, artifact paths, schemas, statuses, or commands in this Skill.
-
-Do not execute the generated goal/target-mode prompt.
-
-Do not use the checklist to mark the task complete.
-
-Do not hide missing source files, ambiguous plan scope, or external blockers.
-
-Do not rewrite the user's plan while copying it into `tmp/ty-context/plan-acceptance/`.
-
-Do not rewrite, strengthen, reorder, translate, normalize, or add items to a plan-provided checklist when the plan already includes an explicit concrete checklist.
-
-Do not use a short sample, stale artifact, old result, or current implementation convenience to reduce a plan that asked for full completion.