npm - project-tiny-context-harness - Versions diffs - 0.2.67 → 0.2.68 - Mend

project-tiny-context-harness 0.2.67 → 0.2.68

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (5) hide show

package/README.md +95 -95
package/assets/README.md +106 -106
package/assets/skills/normal-long-task/SKILL.md +486 -473
package/assets/skills/superpowers-long-task/SKILL.md +256 -241
package/package.json +1 -1

package/assets/skills/normal-long-task/SKILL.md CHANGED Viewed

@@ -1,473 +1,486 @@
----
-name: normal-long-task
-description: Use when directly invoked for ordinary long-running task acceptance planning.
----
-# Normal 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 `normal-long-task` 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 ordinary long-task source into a strict, project-context-aware acceptance checklist and, when requested, a generic goal-mode prompt or target-mode 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 defines the acceptance standard. It is not an execution framework. For a dedicated prompt that binds the finished checklist to the external Superpowers workflow, directly invoke `/superpowers-long-task` after this Skill has produced or verified the full checklist.
-## 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 `tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md`. If the source contains an explicit concrete plan-provided 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. When requested, a generic goal-mode prompt or target-mode prompt that references the plan, full checklist and local audit path without adding execution-framework-specific instructions.
-4. When a local audit path is referenced, it is temporary execution/progress state only, not Context and not proof by itself.
-This Skill 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 the plan is executable enough.
-- `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 development plan is execution direction. The acceptance-and-tests packet is acceptance input.
-Two-document upstream input packet handling is strict mode. If this Skill cannot fully parse required content from both documents, it must stop after preserving inputs, list missing required fields, and ask the user to provide a complete packet. Do not generate a checklist or goal/target-mode prompt from an incomplete two-document packet.
-## 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.
-## Direct Invocation
-Use this Skill through explicit invocation:
-```text
-/normal-long-task
-```
-Do not rely on broad automatic keyword routing. If the user needs the Superpowers-specific long-task adapter, use `/superpowers-long-task` after this Skill has produced or verified the full checklist.
-## Use Cases
-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 generic 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 user requests after direct invocation:
-```text
-acceptance checklist for this 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 `target mode`, `acceptance criteria`, `completion definition`, `目标模式文本`, `验收标准`, or `完成定义` unless the same 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.
-- This two-document upstream input packet path is strict mode. This Skill 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 target-mode executor. This Skill 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, 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.
-- If the plan-provided checklist is too large for the 3850 characters target 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 generated-checklist shaping steps 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.
-When a two-document upstream input packet exists but either document is incomplete, do not continue with the generated-checklist flow. 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.
-## Step 3: Read Relevant Project Context
-Read enough Context and repository guidance to make acceptance criteria falsifiable:
-- Always start with `project_context/global.md`, `project_context/architecture.md`, and `project_context/context.toml` when present.
-- Follow Context graph triggers to relevant area, contract, verification, deployment, implementation-index, decision-rationale or foundation files.
-- Read relevant code/tests only to discover real paths, commands, schema names, UI/API surfaces, runtime entry points and artifact locations.
-- Do not use current implementation convenience to lower the plan's completion definition.
-## Step 4: Run The Context Confirmation Gate
-Stop and ask the user before writing a checklist when:
-- The plan conflicts with durable Context and the conflict changes product scope, ownership, architecture boundary, API/schema contract, state/runtime semantics, security posture or verification design.
-- The plan contains broad words such as `complete`, `production-ready`, `formal`, `all`, `maximum` or `verified`, but no inventory or evidence definition can be derived.
-- A required external account, credential, production environment, paid service, human approval or legal/security decision is needed and the plan does not say how to handle it.
-If this gate triggers:
-- Preserve the source input under `tmp/ty-context/plan-acceptance/`.
-- Report the uncertainty and the Context/code evidence that exposed it.
-- Do not compile the final checklist, write the checklist file, or generate the goal/target-mode prompt yet.
-## Step 5: Compile The Acceptance Contract
-Generated checklists start with:
-```markdown
-## Acceptance Contract
-- Plan source: <path>
-- Source role: implementation/source plan, not acceptance proof
-- Full checklist role: complete acceptance standard
-- Local audit path: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md
-- Current-state claims: <which "current", "generated", "synced", "tested", "accepted" or runtime claims require current evidence>
-- Evidence ledger required: yes/no, with reason
-- Invalid completion evidence: <stale artifacts, code-only edits, partial tests, unexercised runtime, mismatched read paths or other evidence that cannot prove completion>
-- Hard blockers: <user/external/environment blockers that prevent completion>
-```
-## Step 6: Build The Full Acceptance Checklist
-Each generated acceptance item must include:
-- AC ID.
-- Scope.
-- Source.
-- Required evidence.
-- Verification method.
-- Fail condition.
-- Invalid evidence.
-- Status default: `unknown / not_run`.
-Use concrete evidence language. Avoid vague labels such as "works", "done", "handled" or "validated" unless the row defines observable proof.
-## Required automated tests / 必须新增或补强的自动化测试
-Test requirements belong to acceptance evidence, not a fourth artifact.
-No fourth artifact: Do not create `tmp/ty-context/plan-acceptance/<plan-slug>-test-requirements.md`.
-For each required automated test, include:
-- test file path, or behavior-level test description when the exact path is unknowable.
-- test name or behavior description.
-- covered acceptance item.
-- verification command.
-- expected failing condition when the test is added before implementation.
-- expected passing condition after implementation.
-- failure condition.
-- whether the test is required proof or auxiliary evidence only.
-If the plan already includes explicit test requirements, use those plan-provided test requirements and preserve them in the full checklist; do not replace them with generic AC10 wording or an unrelated test list. Do not invent exact test names when only a behavior-level test description is justified.
-## Hard Blocker Handling
-Treat any unresolved required blocker as non-completion.
-For every blocker, record:
-- what is blocked.
-- why local execution cannot satisfy it.
-- what evidence is missing.
-- acceptance impact.
-- the minimum user or external owner action needed.
-- fallback or deferred scope, only if the user explicitly allows it.
-If only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
-## Minimal User Blocker Protocol
-Ask the user for help only after safe self-service discovery has been attempted. When asking, provide a minimal action list:
-- what was already tried.
-- the missing item.
-- exact page/path/field/button/menu when known.
-- minimum value or action needed.
-- sensitive information the user must not send, such as passwords, tokens, cookies, full pages, HAR files or secrets.
-- acceptance impact.
-- fallback or deferred path if any.
-## Generic Acceptance Dimensions
-Use only dimensions that apply to the plan:
-- Scope inventory and non-goals.
-- Context, architecture and boundary conformance.
-- API/schema/data contract.
-- Runtime, worker, job, queue, artifact, checkpoint or scheduler behavior.
-- Console/UI/API projection and user-visible state.
-- Security, privacy, redaction, secret handling and auditability.
-- Tests, build, typecheck, lint, smoke and regression evidence.
-- Documentation or durable Context updates only when the plan changes long-lived facts.
-## Evidence Layer Separation
-Separate evidence layers when they prove different things:
-- code implemented.
-- runtime configured.
-- runtime exercised.
-- artifact generated.
-- artifact accepted by validator.
-- API/UI reflects accepted evidence.
-- browser or user path verified when UI-facing.
-- final gate/check command passed.
-An acceptance row is not complete when the required layer is missing. Examples: runtime configured but not runtime exercised; artifact generated but not artifact accepted by validator; API changed but API/UI reflects accepted evidence is absent; fallback was not configured or exercised.
-## Current-state claims
-Current-state claims require fresh current evidence. Existing files, old logs, stale screenshots, stale artifacts or previous command output cannot prove current completion unless the user explicitly asked for an archival audit.
-## Evidence Ledger
-For evidence-ledger work, use:
-```markdown
-| AC | Expected state | Current observed state | Current evidence | Evidence location / API / UI / command | Status | Invalid evidence |
-|---|---|---|---|---|---|---|
-```
-Allowed statuses: `proven`, `unproven`, `stale-evidence`, `runtime-disconnected`, `implementation-drift`, `blocked`, `deferred-by-explicit-scope`.
-Missing ledger evidence means incomplete, not complete.
-## Invalid completion evidence
-The checklist must reject invalid completion evidence such as:
-- 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.
-## Completion State Machine
-The full checklist and local audit use this state rule:
-- Core ACs start as `unknown / not_run`.
-- Only fresh required evidence can mark an AC complete.
-- Any fresh browser / API / runtime / data / test contradiction must downgrade the affected AC and overall status and be recorded as invalidating evidence.
-- A previous `complete` status does not survive contradictory fresh evidence.
-## Local Audit Rules
-The generic target prompt may ask the future executor to maintain `tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md`.
-The local audit is not Context, not proof by itself, not a global task manager and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`. 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.
-The audit records overall status, each AC status, current evidence, commands and results, artifact/evidence paths, blockers, missing evidence, deferred or narrowed scope and invalidating evidence.
-## Scope Labels
-Use labels consistently:
-- `complete`: all required evidence exists and no contradictory current evidence remains.
-- `partial`: some required evidence exists but at least one required layer is missing.
-- `missing`: no credible evidence exists.
-- `blocked`: required evidence depends on user, external owner, credentials, environment or platform condition.
-- `invalidated`: prior evidence is contradicted by fresh browser / API / runtime / data / test contradiction.
-## Conflict Handling
-When plan, Context, code or evidence conflict, include a conflict table:
-```markdown
-| Conflict | Plan says | Context says | Code/evidence currently says | 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:
-```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.
-```
-## 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.
-```
-## Generic Target-Mode Prompt Generation
-After reusing a plan-provided checklist or compiling a generated checklist, produce a paste-ready generic goal/target-mode prompt when the user asks for one.
-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.
-- Chinese prompts should preserve the compact role phrase `source/implementation plan，非验收证明` when space allows.
-- 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, not Context or proof.
-- 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 with the full checklist is allowed; conflicts are resolved in favor of the full checklist.
-- 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 preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
-- 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`.
-- Do not include explanatory preface inside the prompt.
-- Do not include Markdown tables inside the prompt if they make it too long.
-- 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 tightening wording and referring to the full checklist path while preserving required paths, core AC categories, blocker/evidence rules and false-completion traps.
-## 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 when requested.
-- 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.
+---
+name: normal-long-task
+description: Use when directly invoked for ordinary long-running task acceptance planning.
+---
+# Normal 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 `normal-long-task` 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 ordinary long-task source into a strict, project-context-aware acceptance checklist and, when requested, a generic goal-mode prompt or target-mode 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 defines the acceptance standard. It is not an execution framework. For a dedicated prompt that binds the finished checklist to the external Superpowers workflow, directly invoke `/superpowers-long-task` after this Skill has produced or verified the full checklist.
+## 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 `tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md`. If the source contains an explicit concrete plan-provided 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. When requested, a generic goal-mode prompt or target-mode prompt that references the plan, full checklist and local audit path without adding execution-framework-specific instructions.
+4. When a local audit path is referenced, it is temporary execution/progress state only, not Context and not proof by itself.
+This Skill 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 the plan is executable enough.
+- `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 development plan is execution direction. The acceptance-and-tests packet is acceptance input.
+Two-document upstream input packet handling is strict mode. If this Skill cannot fully parse required content from both documents, it must stop after preserving inputs, list missing required fields, and ask the user to provide a complete packet. Do not generate a checklist or goal/target-mode prompt from an incomplete two-document packet.
+## 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.
+## Direct Invocation
+Use this Skill through explicit invocation:
+```text
+/normal-long-task
+```
+Do not rely on broad automatic keyword routing. If the user needs the Superpowers-specific long-task adapter, use `/superpowers-long-task` after this Skill has produced or verified the full checklist.
+## Use Cases
+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 generic 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 user requests after direct invocation:
+```text
+acceptance checklist for this 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 `target mode`, `acceptance criteria`, `completion definition`, `目标模式文本`, `验收标准`, or `完成定义` unless the same 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.
+- This two-document upstream input packet path is strict mode. This Skill 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 target-mode executor. This Skill 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, 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.
+- If the plan-provided checklist is too large for the 3850 characters target 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 generated-checklist shaping steps 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.
+When a two-document upstream input packet exists but either document is incomplete, do not continue with the generated-checklist flow. 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.
+## Step 3: Read Relevant Project Context
+Read enough Context and repository guidance to make acceptance criteria falsifiable:
+- Always start with `project_context/global.md`, `project_context/architecture.md`, and `project_context/context.toml` when present.
+- Follow Context graph triggers to relevant area, contract, verification, deployment, implementation-index, decision-rationale or foundation files.
+- Read relevant code/tests only to discover real paths, commands, schema names, UI/API surfaces, runtime entry points and artifact locations.
+- Do not use current implementation convenience to lower the plan's completion definition.
+## Step 4: Run The Context Confirmation Gate
+Stop and ask the user before writing a checklist when:
+- The plan conflicts with durable Context and the conflict changes product scope, ownership, architecture boundary, API/schema contract, state/runtime semantics, security posture or verification design.
+- The plan contains broad words such as `complete`, `production-ready`, `formal`, `all`, `maximum` or `verified`, but no inventory or evidence definition can be derived.
+- A required external account, credential, production environment, paid service, human approval or legal/security decision is needed and the plan does not say how to handle it.
+If this gate triggers:
+- Preserve the source input under `tmp/ty-context/plan-acceptance/`.
+- Report the uncertainty and the Context/code evidence that exposed it.
+- Do not compile the final checklist, write the checklist file, or generate the goal/target-mode prompt yet.
+## Step 5: Compile The Acceptance Contract
+Generated checklists start with:
+```markdown
+## Acceptance Contract
+- Plan source: <path>
+- Source role: implementation/source plan, not acceptance proof
+- Full checklist role: complete acceptance standard
+- Local audit path: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md
+- Current-state claims: <which "current", "generated", "synced", "tested", "accepted" or runtime claims require current evidence>
+- Evidence ledger required: yes/no, with reason
+- Invalid completion evidence: <stale artifacts, code-only edits, partial tests, unexercised runtime, mismatched read paths or other evidence that cannot prove completion>
+- Hard blockers: <user/external/environment blockers that prevent completion>
+```
+## Step 6: Build The Full Acceptance Checklist
+Each generated acceptance item must include:
+- AC ID.
+- Scope.
+- Source.
+- Required evidence.
+- Verification method.
+- Fail condition.
+- Invalid evidence.
+- Status default: `unknown / not_run`.
+Use concrete evidence language. Avoid vague labels such as "works", "done", "handled" or "validated" unless the row defines observable proof.
+## Required automated tests / 必须新增或补强的自动化测试
+Test requirements belong to acceptance evidence, not a fourth artifact.
+No fourth artifact: Do not create `tmp/ty-context/plan-acceptance/<plan-slug>-test-requirements.md`.
+For each required automated test, include:
+- test file path, or behavior-level test description when the exact path is unknowable.
+- test name or behavior description.
+- covered acceptance item.
+- verification command.
+- expected failing condition when the test is added before implementation.
+- expected passing condition after implementation.
+- failure condition.
+- whether the test is required proof or auxiliary evidence only.
+If the plan already includes explicit test requirements, use those plan-provided test requirements and preserve them in the full checklist; do not replace them with generic AC10 wording or an unrelated test list. Do not invent exact test names when only a behavior-level test description is justified.
+## Hard Blocker Handling
+Treat any unresolved required blocker as non-completion.
+For every blocker, record:
+- what is blocked.
+- why local execution cannot satisfy it.
+- what evidence is missing.
+- acceptance impact.
+- the minimum user or external owner action needed.
+- fallback or deferred scope, only if the user explicitly allows it.
+If only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
+## Autonomous Progress Protocol
+The generated target-mode prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
+The generated target-mode 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.
+## Minimal User Blocker Protocol
+Ask the user for help only after safe self-service discovery has been attempted. When asking, provide a minimal action list:
+- what was already tried.
+- the missing item.
+- exact page, system, command or owner to open/contact.
+- exact page/path/field/button/menu when known.
+- minimum value or action needed.
+- how to redact or avoid sending sensitive values.
+- sensitive information the user must not send, such as passwords, tokens, cookies, full pages, HAR files or secrets.
+- what the executor will do immediately after receiving the input.
+- acceptance impact.
+- fallback or deferred path if any.
+## Generic Acceptance Dimensions
+Use only dimensions that apply to the plan:
+- Scope inventory and non-goals.
+- Context, architecture and boundary conformance.
+- API/schema/data contract.
+- Runtime, worker, job, queue, artifact, checkpoint or scheduler behavior.
+- Console/UI/API projection and user-visible state.
+- Security, privacy, redaction, secret handling and auditability.
+- Tests, build, typecheck, lint, smoke and regression evidence.
+- Documentation or durable Context updates only when the plan changes long-lived facts.
+## Evidence Layer Separation
+Separate evidence layers when they prove different things:
+- code implemented.
+- runtime configured.
+- runtime exercised.
+- artifact generated.
+- artifact accepted by validator.
+- API/UI reflects accepted evidence.
+- browser or user path verified when UI-facing.
+- final gate/check command passed.
+An acceptance row is not complete when the required layer is missing. Examples: runtime configured but not runtime exercised; artifact generated but not artifact accepted by validator; API changed but API/UI reflects accepted evidence is absent; fallback was not configured or exercised.
+## Current-state claims
+Current-state claims require fresh current evidence. Existing files, old logs, stale screenshots, stale artifacts or previous command output cannot prove current completion unless the user explicitly asked for an archival audit.
+## Evidence Ledger
+For evidence-ledger work, use:
+```markdown
+| AC | Expected state | Current observed state | Current evidence | Evidence location / API / UI / command | Status | Invalid evidence |
+|---|---|---|---|---|---|---|
+```
+Allowed statuses: `proven`, `unproven`, `stale-evidence`, `runtime-disconnected`, `implementation-drift`, `blocked`, `deferred-by-explicit-scope`.
+Missing ledger evidence means incomplete, not complete.
+## Invalid completion evidence
+The checklist must reject invalid completion evidence such as:
+- 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.
+## Completion State Machine
+The full checklist and local audit use this state rule:
+- Core ACs start as `unknown / not_run`.
+- Only fresh required evidence can mark an AC complete.
+- Any fresh browser / API / runtime / data / test contradiction must downgrade the affected AC and overall status and be recorded as invalidating evidence.
+- A previous `complete` status does not survive contradictory fresh evidence.
+## Local Audit Rules
+The generic target prompt may ask the future executor to maintain `tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md`.
+The local audit is not Context, not proof by itself, not a global task manager and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`. 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.
+The audit records overall status, each AC status, current evidence, commands and results, artifact/evidence paths, blockers, missing evidence, deferred or narrowed scope and invalidating evidence.
+## Scope Labels
+Use labels consistently:
+- `complete`: all required evidence exists and no contradictory current evidence remains.
+- `partial`: some required evidence exists but at least one required layer is missing.
+- `missing`: no credible evidence exists.
+- `blocked`: required evidence depends on user, external owner, credentials, environment or platform condition.
+- `invalidated`: prior evidence is contradicted by fresh browser / API / runtime / data / test contradiction.
+## Conflict Handling
+When plan, Context, code or evidence conflict, include a conflict table:
+```markdown
+| Conflict | Plan says | Context says | Code/evidence currently says | 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:
+```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.
+```
+## 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.
+```
+## Generic Target-Mode Prompt Generation
+After reusing a plan-provided checklist or compiling a generated checklist, produce a paste-ready generic goal/target-mode prompt when the user asks for one.
+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.
+- Chinese prompts should preserve the compact role phrase `source/implementation plan，非验收证明` when space allows.
+- 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, not Context or proof.
+- 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 with the full checklist is allowed; conflicts are resolved in favor of the full checklist.
+- 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 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. If pausing for a locally unsatisfiable hard blocker, provide the minimum user action list: exact page/system/command/owner, field or value location, redaction guidance, values not to send and what the executor will do next.
+- 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 preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking the goal complete.
+- 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`.
+- Do not include explanatory preface inside the prompt.
+- Do not include Markdown tables inside the prompt if they make it too long.
+- 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 tightening wording and referring to the full checklist path while preserving required paths, core AC categories, blocker/evidence rules and false-completion traps.
+## 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 when requested.
+- 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.