project-tiny-context-harness 0.2.68 → 0.2.70
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.
- package/README.md +17 -16
- package/assets/README.md +24 -23
- package/assets/README.zh-CN.md +8 -7
- package/assets/agents/AGENTS_CORE.md +1 -1
- package/assets/skills/superpowers-long-task/SKILL.md +362 -256
- package/package.json +69 -68
package/README.md
CHANGED
|
@@ -79,23 +79,24 @@ workflow contract + project_context/** -> implementation -> verification -> drif
|
|
|
79
79
|
|
|
80
80
|
For long-running tasks, externalize the target first. Use explicit Skill invocation instead of broad keyword triggering:
|
|
81
81
|
|
|
82
|
-
```text
|
|
83
|
-
Web GPT or another external planning model produces
|
|
84
|
-
-> /normal-long-task produces the full checklist and optional generic target-mode prompt
|
|
85
|
-
-> /superpowers-long-task
|
|
86
|
-
-> Superpowers derives concrete implementation slices
|
|
87
|
-
->
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
82
|
+
```text
|
|
83
|
+
Web GPT or another external planning model produces the long-task source inputs
|
|
84
|
+
-> /normal-long-task produces the full checklist and optional generic target-mode prompt
|
|
85
|
+
-> /superpowers-long-task consumes Product / Architecture Source + Technical Realization Plan + Acceptance Checklist when Superpowers execution is needed
|
|
86
|
+
-> Superpowers derives concrete implementation slices
|
|
87
|
+
-> execution maintains a plan-conformance matrix and final acceptance verdict
|
|
88
|
+
-> each slice follows the workflow contract + project_context/**
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
For ordinary target-mode preparation, a two-document upstream input remains enough: a `Development Plan` for execution direction and plan traceability, and an `Acceptance and Tests` packet for acceptance authority. Source Pack exports are temporary upload material for external planning, not durable Context.
|
|
91
92
|
|
|
92
93
|
The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers acceptance pass: it can generate or reuse the full acceptance checklist and can produce a generic target-mode prompt.
|
|
93
94
|
|
|
94
|
-
The Superpowers long-task path uses `/superpowers-long-task`
|
|
95
|
+
The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion.
|
|
95
96
|
|
|
96
|
-
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against the
|
|
97
|
+
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against both the plan-conformance matrix and final acceptance verdict.
|
|
97
98
|
|
|
98
|
-
The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A
|
|
99
|
+
The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, plan-conformance matrix, final acceptance verdict and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
|
|
99
100
|
|
|
100
101
|
## Positioning
|
|
101
102
|
|
|
@@ -146,7 +147,7 @@ npm ci
|
|
|
146
147
|
npm run smoke:quickstart
|
|
147
148
|
npm run preview:pack
|
|
148
149
|
cd /path/to/your/test-repo
|
|
149
|
-
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.
|
|
150
|
+
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.70.tgz
|
|
150
151
|
npx --no-install ty-context init --adopt
|
|
151
152
|
make validate-context
|
|
152
153
|
```
|
|
@@ -261,7 +262,7 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
|
|
|
261
262
|
| Full project context export Skill | `<harnessRoot>/skills/context_full_project_export/SKILL.md` | Handles explicit full-project, project-overall, Source Pack or code-level export requests and uses `export-context --source-pack`, `--code-index`, `--task-context`, `--all`, `--full` or `--code` to create temporary artifacts under `tmp/ty-context/context-exports/**`. |
|
|
262
263
|
| Harness upgrade Skill | `<harnessRoot>/skills/context_harness_upgrade/SKILL.md` | Handles explicit Tiny Context / Project Tiny Context Harness upgrade requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project”; it runs the canonical `upgrade` path, handles only migration-scoped `manual_required` / `blocked` follow-up, then runs diagnostics. |
|
|
263
264
|
| Ordinary long-task Skill | `<harnessRoot>/skills/normal-long-task/SKILL.md` | Invoke as `/normal-long-task` to turn a referenced plan, RFC, implementation proposal or two-document upstream input into a falsifiable acceptance checklist and optional generic paste-ready goal/target-mode prompt under `tmp/ty-context/plan-acceptance/**`; if the plan already contains an explicit concrete checklist, the Skill reuses it verbatim in the separate full-checklist file; compact summaries are only navigation/priority, but the Skill does not execute the plan or prove completion. |
|
|
264
|
-
| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task`
|
|
265
|
+
| Superpowers long-task Skill | `<harnessRoot>/skills/superpowers-long-task/SKILL.md` | Invoke as `/superpowers-long-task` when Product / Architecture Source, Technical Realization Plan and Acceptance Checklist exist and Superpowers execution is needed. It emits a Superpowers-specific prompt with Context Delta checks and the official workflow skill names, requires a plan-conformance matrix and final acceptance verdict during execution, and stops when required input fields are missing. It is not a Superpowers official schema and does not generate the technical plan, checklist or execute the plan. |
|
|
265
266
|
| Project-local Skills | `<harnessRoot>/skills/<role>/SKILL.md` | Optional local product/design/development Skills created by the project, such as `product_plan`, `uiux_design` or `development_engineer`. They supersede package-managed default Skills when more specific, are not overwritten by `sync`, and should keep front matter trigger keywords aligned with the project `AGENTS.md` role-trigger rule. |
|
|
266
267
|
| Managed file sync | `make ty-context-sync` or `npx --yes --package project-tiny-context-harness@latest ty-context sync` | Refreshes package-managed guidance, default Skills, Makefile include, context templates, tools and workflow YAML. It does not run migrations or perform semantic Context generation; it may block only direct asset-refresh safety issues such as invalid managed blocks or deprecated managed Skill overrides. |
|
|
267
268
|
| Upgrade | `make ty-context-upgrade` or `npx --yes --package project-tiny-context-harness@latest ty-context upgrade` | Use for releases marked `upgrade-required` or `manual-required`. Builds an upgrade plan, stops before writes when `blocked` items exist, otherwise applies `safe_pending` migrations, runs `sync` and `doctor`, and exits non-zero when manual follow-up or diagnostics remain. |
|
|
@@ -279,13 +280,13 @@ Use `npx --no-install ty-context ...` only when you explicitly want the already
|
|
|
279
280
|
| Diagnostics | `make ty-context-doctor` or `npx --yes --package project-tiny-context-harness@latest ty-context doctor` | Reports Harness root, package version, schema version and required Minimal Context paths. |
|
|
280
281
|
| Package source checks | `ty-context package sync-source`, `ty-context package check-source` | Maintainer-only commands for keeping package canonical assets aligned with the source workspace. |
|
|
281
282
|
|
|
282
|
-
For high-risk product, UI/UX and engineering tasks that affect durable architecture or module ownership, API/Schema/data contracts, state/runtime behavior, dependency direction, verification/deployment semantics or design-rationale tradeoffs, the default Skills compile a short current-task contract before implementation. The contract starts with `Context Delta: none|required`; `required` preserves context-first behavior, while `none` means the task can proceed against existing Context. It can name `Architecture Context Hit` and `Decision Rationale Hit: existing|required|none` so agents explicitly check the controlling Context and rationale state. When module design principles are relevant, the same contract still uses `Applicable Module Design` for the principles, design logic and rationale controlling the current choice. For engineering, RFC and implementation work, the existing Task Contract still includes `Modularity Check: none|required|exception` so oversized touched files trigger split-or-exception reasoning without becoming an architecture gate. Ordinary bug fixes, local styling, small refactors, package/release chores, test repairs and spikes are not forced into architecture/rationale ceremony unless they produce durable facts. The task contract and Contract Conformance are handoff evidence, not new PRD, tech-plan, ADR, implementation-document, validator or gate surfaces.
|
|
283
|
+
For high-risk product, UI/UX and engineering tasks that affect durable architecture or module ownership, API/Schema/data contracts, state/runtime behavior, dependency direction, verification/deployment semantics or design-rationale tradeoffs, the default Skills compile a short current-task contract before implementation. The contract starts with `Context Delta: none|required`; `required` preserves context-first behavior, while `none` means the task can proceed against existing Context. When an input is a product/architecture source or technical implementation plan, the same judgment is refined into `Product Context Delta: none|required` and `Technical Context Delta: none|required`; either `required` means overall `Context Delta: required`. Product Context Delta covers product logic, flows, surface responsibility, information architecture, status meaning, operation boundaries and acceptance semantics. Technical Context Delta covers API/schema/data/event contracts, module ownership, dependency direction, worker/runtime/state semantics, verification/deployment paths and durable technical tradeoffs. It can name `Architecture Context Hit` and `Decision Rationale Hit: existing|required|none` so agents explicitly check the controlling Context and rationale state. When module design principles are relevant, the same contract still uses `Applicable Module Design` for the principles, design logic and rationale controlling the current choice. For engineering, RFC and implementation work, the existing Task Contract still includes `Modularity Check: none|required|exception` so oversized touched files trigger split-or-exception reasoning without becoming an architecture gate. Ordinary bug fixes, local styling, small refactors, package/release chores, test repairs and spikes are not forced into architecture/rationale ceremony unless they produce durable facts. The task contract and Contract Conformance are handoff evidence, not new PRD, tech-plan, ADR, implementation-document, validator or gate surfaces.
|
|
283
284
|
|
|
284
285
|
Technical architecture support is a Minimal Context capability: use restrained `architecture.md`, area Module Design Capsules and existing `contract` / `decision-rationale` roles when durable architecture or rationale matters. Do not invent rationale; store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface when they will affect future implementation or verification choices.
|
|
285
286
|
|
|
286
287
|
For long-running plans, RFCs or implementation proposals, invoke `/normal-long-task` to turn a plan plus relevant Context into a falsifiable acceptance checklist and an optional generic paste-ready goal/target-mode prompt. It also supports a two-document upstream input from Web GPT or another external planner: `Development Plan` for execution direction and `Acceptance and Tests` for target-mode acceptance input. If the plan already contains an explicit concrete acceptance checklist, the Skill copies that checklist verbatim into a separate full-checklist file instead of generating a competing checklist. The two-document packet path is strict mode: when required fields cannot be fully parsed from both documents, the Skill preserves the inputs, reports the missing fields, and stops without generating a checklist or goal/target-mode prompt. It is one pre-execution acceptance pass, not a task planner or workflow engine: it stores temporary inputs under `tmp/ty-context/plan-acceptance/**`, asks for confirmation when durable assumptions are unclear, and leaves execution evidence to the future executor, tests, CI, review or human acceptance. The generated prompt may require a local audit under the same temporary directory so future sessions can recover acceptance progress; that audit is not Context, not a quality proof and not a replacement for the project's Tiny Context workflow contract. When the prompt references a full checklist, that checklist is the acceptance authority; compact prompt text is only navigation, priority and recovery guidance.
|
|
287
288
|
|
|
288
|
-
When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the
|
|
289
|
+
When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*` and `final-acceptance-verdict.*`. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections.
|
|
289
290
|
|
|
290
291
|
For Product Surface work, `context_surface_contract` turns broad product/page/UI principles into project-owned surface responsibilities. A Product Surface can be a Web page, mobile screen, desktop window, game UI/HUD/menu, CLI/TUI output, extension UI or embedded/device interface. Cross-surface contracts use the existing `contract` role; area-owned screen facts stay in `area` or `subdomain`; repeatable validation paths use `verification`. The Harness does not add a new surface-specific role, does not create business surface contracts during `init` or `upgrade`, and does not turn surface conformance into a validator gate. Projects that want mandatory task blocks should add a separate project-local Skill, while `product-surface-contract.md` is only a compact managed template for optional Context authoring.
|
|
291
292
|
|
package/assets/README.md
CHANGED
|
@@ -94,7 +94,7 @@ That smoke packs the local workspace, installs it into a disposable repo, runs `
|
|
|
94
94
|
```sh
|
|
95
95
|
npm run preview:pack
|
|
96
96
|
cd /path/to/your/test-repo
|
|
97
|
-
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.
|
|
97
|
+
npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.2.70.tgz
|
|
98
98
|
npx --no-install ty-context init --adopt
|
|
99
99
|
make validate-context
|
|
100
100
|
```
|
|
@@ -123,23 +123,24 @@ workflow contract + project_context/** -> implementation -> verification -> drif
|
|
|
123
123
|
|
|
124
124
|
For long-running tasks, externalize the target first. Use explicit Skill invocation instead of broad keyword triggering:
|
|
125
125
|
|
|
126
|
-
```text
|
|
127
|
-
Web GPT or another external planning model produces
|
|
128
|
-
-> /normal-long-task produces the full checklist and optional generic target-mode prompt
|
|
129
|
-
-> /superpowers-long-task
|
|
130
|
-
-> Superpowers derives concrete implementation slices
|
|
131
|
-
->
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
126
|
+
```text
|
|
127
|
+
Web GPT or another external planning model produces the long-task source inputs
|
|
128
|
+
-> /normal-long-task produces the full checklist and optional generic target-mode prompt
|
|
129
|
+
-> /superpowers-long-task consumes Product / Architecture Source + Technical Realization Plan + Acceptance Checklist when Superpowers execution is needed
|
|
130
|
+
-> Superpowers derives concrete implementation slices
|
|
131
|
+
-> execution maintains a plan-conformance matrix and final acceptance verdict
|
|
132
|
+
-> each slice follows the workflow contract + project_context/**
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
For ordinary target-mode preparation, a two-document upstream input remains enough: a `Development Plan` for execution direction and plan traceability, and an `Acceptance and Tests` packet for acceptance authority. Source Pack exports are temporary upload material for external planning, not durable Context.
|
|
136
|
+
|
|
137
|
+
The ordinary long-task path uses `/normal-long-task`. It is the non-Superpowers acceptance pass: it can generate or reuse the full acceptance checklist and can produce a generic target-mode prompt.
|
|
138
|
+
|
|
139
|
+
The Superpowers long-task path uses `/superpowers-long-task` when three inputs already exist: `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`. The product/architecture source preserves original intent and scope; the technical realization plan is the execution blueprint and plan-conformance source; the checklist is the acceptance authority. Two-document compatibility is allowed only when the first document clearly contains both product/architecture source and technical realization plan sections. If only a product/architecture source and checklist exist, the Skill stops for a missing `Technical Realization Plan` instead of generating one. The prompt is Tiny Context's adapter layer, not a Superpowers official schema. It requires `Product Context Delta` and `Technical Context Delta` checks before implementation, a `plan-conformance-matrix.*` process trace for implementation drift and a final AC-by-AC `final-acceptance-verdict.*` before completion.
|
|
140
|
+
|
|
141
|
+
The recommended Superpowers layer is the specific [obra/Superpowers](https://github.com/obra/superpowers) plugin/workflow, not a generic planning substitute. Use `superpowers:writing-plans` when the target-mode prompt or source plan still needs bite-sized implementation tasks, then prefer `superpowers:subagent-driven-development` when subagents are available and `superpowers:executing-plans` otherwise. Behavior changes should use `superpowers:test-driven-development`, and completion claims should use `superpowers:verification-before-completion` against both the plan-conformance matrix and final acceptance verdict.
|
|
142
|
+
|
|
143
|
+
The reason is drift control. The workflow contract plus Context layer is intentionally a soft constraint. It works well for short tasks, and Context can still capture the expected facts for long tasks, but long execution makes the Context-to-code step drift as the context window grows, work is handed off, subagents split scope or validation loops multiply. A product/architecture source, technical realization plan, acceptance checklist, explicit long-task Skill invocation, target-mode prompt, plan-conformance matrix, final acceptance verdict and optional Superpowers execution layer make implementation conformance and completion evidence recoverable without restoring a phase-gated workflow.
|
|
143
144
|
|
|
144
145
|
## Positioning
|
|
145
146
|
|
|
@@ -298,19 +299,19 @@ No. It checks that recovery facts exist and avoids fake test-result claims. Prod
|
|
|
298
299
|
|
|
299
300
|
It should stay smaller than a full process. Ordinary bug fixes and local refactors do not update Context unless they produce durable product, architecture, API, state or validation facts.
|
|
300
301
|
|
|
301
|
-
The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria for a referenced plan but do not execute it or
|
|
302
|
+
The default Skills are Minimal Context helpers for explicit product-planning, UI/UX-design, development-engineering, Product Surface Contract, full-project-export, Tiny Context upgrade and explicit long-task requests. Product, screen-flow, surface responsibility and durable engineering conclusions go to `project_context/**`; visual identity and design tokens go to root `DESIGN.md`. Export artifacts are temporary files under `tmp/ty-context/context-exports/**`, not Context. Long-task artifacts are temporary files under `tmp/ty-context/plan-acceptance/**`; they define completion criteria or execution evidence for a referenced plan but do not execute it or become durable Context. The ordinary long-task Skill is invoked as `/normal-long-task`: if the plan already contains an explicit concrete checklist, it reuses that checklist verbatim in the separate full-checklist file. For a two-document upstream input, the external planner should provide a `Development Plan` and an `Acceptance and Tests` packet; `/normal-long-task` preserves both source roles and, only when strict-mode required fields are fully parseable from both documents, turns them into the full checklist plus optional generic target prompt. When a generated prompt references a full checklist, that checklist is the authoritative acceptance standard; the compact prompt summary is only navigation and priority guidance. The Superpowers long-task Skill is invoked as `/superpowers-long-task`: it consumes `Product / Architecture Source`, `Technical Realization Plan` and `Acceptance Checklist`, emits the Superpowers-specific target-mode prompt, requires `Product Context Delta`, `Technical Context Delta`, `plan-conformance-matrix.*` and `final-acceptance-verdict.*` during future execution, is not a Superpowers official schema, and stops if required fields are missing. The Harness upgrade Skill handles requests such as “upgrade Tiny Context” and “use the Tiny Context upgrade skill to upgrade this project” by following the release update mode, using `upgrade` for migration-bearing releases, and limiting manual cleanup to migration-scoped follow-up.
|
|
302
303
|
|
|
303
304
|
Multilingual trigger phrases are compatibility details. Public README, npm and launch copy stay English-first, and public/package-managed surfaces must remain English-complete; literal non-English examples are documented only where they explain generated Skill matching and must not be the sole activation path.
|
|
304
305
|
|
|
305
|
-
For high-risk product, UI/UX and engineering tasks that affect durable architecture or module ownership, API/Schema/data contracts, state/runtime behavior, dependency direction, verification/deployment semantics or design-rationale tradeoffs, the default Skills compile a short current-task contract before implementation. The contract starts with `Context Delta: none|required`; `required` preserves context-first behavior, while `none` means the task can proceed against existing Context. It can name `Architecture Context Hit` and `Decision Rationale Hit: existing|required|none` so agents explicitly check the controlling Context and rationale state. When module design principles are relevant, the same contract still uses `Applicable Module Design` for the principles, design logic and rationale controlling the current choice. For engineering, RFC and implementation work, the existing Task Contract still includes `Modularity Check: none|required|exception` so oversized touched files trigger split-or-exception reasoning without becoming an architecture gate. Ordinary bug fixes, local styling, small refactors, package/release chores, test repairs and spikes are not forced into architecture/rationale ceremony unless they produce durable facts. The task contract and Contract Conformance are handoff evidence, not new PRD, tech-plan, ADR, implementation-document, validator or gate surfaces.
|
|
306
|
+
For high-risk product, UI/UX and engineering tasks that affect durable architecture or module ownership, API/Schema/data contracts, state/runtime behavior, dependency direction, verification/deployment semantics or design-rationale tradeoffs, the default Skills compile a short current-task contract before implementation. The contract starts with `Context Delta: none|required`; `required` preserves context-first behavior, while `none` means the task can proceed against existing Context. When an input is a product/architecture source or technical implementation plan, the same judgment is refined into `Product Context Delta: none|required` and `Technical Context Delta: none|required`; either `required` means overall `Context Delta: required`. Product Context Delta covers product logic, flows, surface responsibility, information architecture, status meaning, operation boundaries and acceptance semantics. Technical Context Delta covers API/schema/data/event contracts, module ownership, dependency direction, worker/runtime/state semantics, verification/deployment paths and durable technical tradeoffs. It can name `Architecture Context Hit` and `Decision Rationale Hit: existing|required|none` so agents explicitly check the controlling Context and rationale state. When module design principles are relevant, the same contract still uses `Applicable Module Design` for the principles, design logic and rationale controlling the current choice. For engineering, RFC and implementation work, the existing Task Contract still includes `Modularity Check: none|required|exception` so oversized touched files trigger split-or-exception reasoning without becoming an architecture gate. Ordinary bug fixes, local styling, small refactors, package/release chores, test repairs and spikes are not forced into architecture/rationale ceremony unless they produce durable facts. The task contract and Contract Conformance are handoff evidence, not new PRD, tech-plan, ADR, implementation-document, validator or gate surfaces.
|
|
306
307
|
|
|
307
308
|
Technical architecture support is a Minimal Context capability: use restrained `architecture.md`, area Module Design Capsules and existing `contract` / `decision-rationale` roles when durable architecture or rationale matters. Do not invent rationale; store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface when they will affect future implementation or verification choices.
|
|
308
309
|
|
|
309
310
|
For long-running plans, RFCs or implementation proposals, invoke `/normal-long-task` to turn a plan plus relevant Context into a falsifiable acceptance checklist and an optional generic paste-ready goal/target-mode prompt. It also supports a two-document upstream input from Web GPT or another external planner: `Development Plan` for execution direction and `Acceptance and Tests` for target-mode acceptance input. If the plan already contains an explicit concrete acceptance checklist, the Skill copies that checklist verbatim into a separate full-checklist file instead of generating a competing checklist. The two-document packet path is strict mode: when required fields cannot be fully parsed from both documents, the Skill preserves the inputs, reports the missing fields, and stops without generating a checklist or goal/target-mode prompt. This is one pre-execution acceptance pass, not a task planner or workflow engine: it stores temporary inputs under `tmp/ty-context/plan-acceptance/**`, asks for confirmation when durable assumptions are unclear, and leaves execution evidence to the future executor, tests, CI, review or human acceptance. The generated prompt may require a local audit under the same temporary directory so future sessions can recover acceptance progress; that audit is not Context, not a quality proof and not a replacement for the project's Tiny Context workflow contract. The full checklist is the acceptance authority, while any compact prompt summary exists for navigation, priority and recovery after context compaction.
|
|
310
311
|
|
|
311
|
-
When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the
|
|
312
|
-
|
|
313
|
-
Important usage note: Minimal Context intentionally keeps Context read order, Context/code priority and drift checks as agent-level soft constraints rather than machine-enforced gates. That tradeoff works well for short tasks, but long tasks with large context windows, multiple handoffs or many verification loops are expected to drift unless
|
|
312
|
+
When the next step explicitly needs Superpowers, invoke `/superpowers-long-task` on the Product / Architecture Source, Technical Realization Plan and Acceptance Checklist. It emits the `Superpowers input packet` and execution binding so the future executor sees which inputs feed Context Delta assessment, `superpowers:writing-plans`, `superpowers:subagent-driven-development`, `superpowers:executing-plans`, TDD, `superpowers:verification-before-completion`, local audit, `plan-conformance-matrix.*` and `final-acceptance-verdict.*`. This is Tiny Context's adapter layer, not a Superpowers official schema. It cannot replace `/normal-long-task` for ordinary checklist preparation, and it does not derive a technical plan from a product plan; a two-document packet is accepted only when the first document explicitly contains both product/architecture source and technical realization plan sections.
|
|
313
|
+
|
|
314
|
+
Important usage note: Minimal Context intentionally keeps Context read order, Context/code priority and drift checks as agent-level soft constraints rather than machine-enforced gates. That tradeoff works well for short tasks, but long tasks with large context windows, multiple handoffs or many verification loops are expected to drift unless product intent, technical implementation target and acceptance target are externalized. Use `/normal-long-task` before long-running execution when ordinary checklist preparation is needed; use `/superpowers-long-task` when the three upstream inputs already exist and Superpowers execution is desired. Treat the plan-conformance matrix as process trace, the final verdict as final AC-by-AC acceptance evidence, and the local audit only as temporary progress/recovery state.
|
|
314
315
|
|
|
315
316
|
For Product Surface work, `context_surface_contract` turns broad product/page/UI principles into project-owned surface responsibilities. A Product Surface can be a Web page, mobile screen, desktop window, game UI/HUD/menu, CLI/TUI output, extension UI or embedded/device interface. Cross-surface contracts use the existing `contract` role; area-owned screen facts stay in `area` or `subdomain`; repeatable validation paths use `verification`. The Harness does not add a new surface-specific role, does not create business surface contracts during `init` or `upgrade`, and does not turn surface conformance into a validator gate. Projects that want mandatory task blocks should add a separate project-local Skill, while `product-surface-contract.md` is only a compact managed template for optional Context authoring.
|
|
316
317
|
|
package/assets/README.zh-CN.md
CHANGED
|
@@ -50,11 +50,11 @@ Fresh agent 先读这些文件，再开始改代码。
|
|
|
50
50
|
|
|
51
51
|
一个典型失败场景是 ABCD 模块链：A/B/C 是上游，D 是下游。现在做 D 的需求时发现能力缺口；如果没有 Context 和优先级约束，agent 很容易为了让 D 完成而去改上游 A/B，因为当前代码让这条路可行。但真正需要判断的是：D 是否有权改 A/B？缺口是不是属于 C 的契约？是否必须先声明 `Context Delta`，让项目意图变化被确认后再实现？代码能说明“现在怎么改得动”，不能说明“项目意图是否允许这样改”。Tiny Context 要补的就是这一层 repo 内长期事实和优先级契约。
|
|
52
52
|
|
|
53
|
-
对于长程任务，Harness 提供两个显式调用的长程任务 Skill。普通长程任务用 `/normal-long-task`：它把方案和验收输入临时放到 `tmp/ty-context/plan-acceptance/**`，生成或复用完整验收清单，并可输出普通目标模式文本。如果外部规划模型参与，推荐仍然只给两份产物：`《开发方案》`
|
|
53
|
+
对于长程任务，Harness 提供两个显式调用的长程任务 Skill。普通长程任务用 `/normal-long-task`：它把方案和验收输入临时放到 `tmp/ty-context/plan-acceptance/**`，生成或复用完整验收清单，并可输出普通目标模式文本。如果外部规划模型参与，推荐仍然只给两份产物：`《开发方案》` 作为执行方向和 plan traceability source，`《验收清单和测试用例》` 作为 Codex target-mode acceptance input packet。第一份应包含可逐项追踪的 plan item、预期落点 surface、full scope 与 sampled/optional 边界；第二份应包含 AC、required evidence、测试命令、真实产品路径 / core path、证据分层、无效证据、状态机、local audit 和 blocker。Source Pack 只是临时上传材料，不是 durable Context。如果方案里已经有明确、具体的“验收清单”，`/normal-long-task` 会直接复用那份清单并单独写入完整验收清单文件；两份输入包走 strict mode，如果两份内容无法完整解析出 required fields，或第二份缺少 required evidence、verification method、fail condition、状态机、无效证据规则等必要字段，Skill 会停止并列出缺失项，不生成完整验收清单或目标模式文本。
|
|
54
54
|
|
|
55
|
-
Superpowers 长程任务 Skill 用 `/superpowers-long-task`。如果下一步明确要 Superpowers
|
|
55
|
+
Superpowers 长程任务 Skill 用 `/superpowers-long-task`。如果下一步明确要 Superpowers 目标模式文本，推荐在三份输入都存在后调用：`Product / Architecture Source`（产品/架构原始意图源）、`Technical Realization Plan`（具体技术实现方案）和 `Acceptance Checklist`（验收清单）。它不要求先跑 `/normal-long-task`，但也不会把产品方案现场翻译成技术方案；如果只有产品/架构方案和验收清单，Skill 会停止并报告缺少 `Technical Realization Plan`。两份输入兼容只限第一份明确包含产品/架构源和技术实现方案两个章节。它显式输出 `Superpowers 输入包` 和执行绑定，让未来 executor 清楚哪些输入进入 Product Context Delta、Technical Context Delta、`superpowers:writing-plans`、subagent/inline execution、TDD、`superpowers:verification-before-completion`、local audit、`plan-conformance-matrix.*` 和 `final-acceptance-verdict.*`。这个 prompt 是 Tiny Context 的适配层，不是 Superpowers 官方 schema；它不生成技术方案或验收清单、不执行计划、不证明完成，也不会把临时清单、矩阵或 verdict 注册成 `project_context/**`。
|
|
56
56
|
|
|
57
|
-
重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 gate
|
|
57
|
+
重要使用提示：Minimal Context 有意把 Context 读取顺序、Context / 代码优先级和漂移检查保持为 agent 级软约束，而不是机器强制 gate。这个取舍适合短任务，但长任务、大上下文、多次交接或多轮验证时预期会漂移。普通 checklist 准备需要 `/normal-long-task`；已有产品/架构原始意图源、具体技术实现方案和验收清单且需要 Superpowers 时，可直接用 `/superpowers-long-task`。`Product Context Delta` 判断产品逻辑、页面职责、信息架构和验收语义是否需要写入 Context；`Technical Context Delta` 判断 API/schema、模块边界、runtime/state、验证/部署路径和稳定技术取舍是否需要写入 Context。`plan-conformance-matrix.*` 是执行期“对图纸台账”，`final-acceptance-verdict.*` 是最后逐 AC 验收报告，local audit 只是临时进度/恢复状态，不能裁判完成。
|
|
58
58
|
|
|
59
59
|
## 当前最佳实践
|
|
60
60
|
|
|
@@ -67,16 +67,17 @@ Superpowers 长程任务 Skill 用 `/superpowers-long-task`。如果下一步明
|
|
|
67
67
|
长程任务先外化目标，再进入实现：
|
|
68
68
|
|
|
69
69
|
```text
|
|
70
|
-
Web GPT
|
|
70
|
+
Web GPT 或其他外部规划模型产出长任务源输入
|
|
71
71
|
-> /normal-long-task 生成完整验收清单和可选普通目标模式文本
|
|
72
|
-
-> 需要 Superpowers
|
|
72
|
+
-> 需要 Superpowers 专用目标模式文本时，/superpowers-long-task 消费 Product / Architecture Source + Technical Realization Plan + Acceptance Checklist
|
|
73
73
|
-> Superpowers 得出具体落地执行片段
|
|
74
|
+
-> 执行中维护 plan-conformance-matrix，最后生成 final-acceptance-verdict
|
|
74
75
|
-> 每个执行片段都回到流程契约 + project_context/**
|
|
75
76
|
```
|
|
76
77
|
|
|
77
|
-
这里的 Superpowers 指具体的 [obra/Superpowers](https://github.com/obra/superpowers) 插件/开源工作流，不是泛化的执行规划替代品。如果目标模式文本或原方案还不够可执行，用 `superpowers:writing-plans` 转成 bite-sized implementation plan；有 subagent 支持时优先用 `superpowers:subagent-driven-development`，否则用 `superpowers:executing-plans`；涉及行为变更时用 `superpowers:test-driven-development`；完成声明前用 `superpowers:verification-before-completion`
|
|
78
|
+
这里的 Superpowers 指具体的 [obra/Superpowers](https://github.com/obra/superpowers) 插件/开源工作流，不是泛化的执行规划替代品。如果目标模式文本或原方案还不够可执行，用 `superpowers:writing-plans` 转成 bite-sized implementation plan；有 subagent 支持时优先用 `superpowers:subagent-driven-development`，否则用 `superpowers:executing-plans`；涉及行为变更时用 `superpowers:test-driven-development`；完成声明前用 `superpowers:verification-before-completion` 同时检查 plan-conformance matrix 和 final acceptance verdict。
|
|
78
79
|
|
|
79
|
-
原因是漂移控制。流程契约 + Context 层是软约束，短任务里通常能让 agent 按预期执行；长程任务里，Context 仍然能记录符合预期的事实，但 Context 到代码 的实现步骤会随着上下文窗口变大、多次交接、subagent
|
|
80
|
+
原因是漂移控制。流程契约 + Context 层是软约束，短任务里通常能让 agent 按预期执行；长程任务里，Context 仍然能记录符合预期的事实，但 Context 到代码 的实现步骤会随着上下文窗口变大、多次交接、subagent 拆分和多轮验证而漂移。产品/架构原始意图源、具体技术实现方案、验收清单、显式长程任务 Skill 调用、目标模式文本、plan-conformance matrix、final acceptance verdict 和可选 Superpowers 执行层，把“产品/技术 Context 有没有先对齐”“有没有按图纸实现”和“有没有按验收证据完成”都外化成可恢复、可审计的临时执行标准，同时不恢复阶段式 gate。
|
|
80
81
|
|
|
81
82
|
## 适合谁
|
|
82
83
|
|
|
@@ -39,7 +39,7 @@
|
|
|
39
39
|
10. 长期事实只写入 `project_context/**`；不要默认创建 PRD、tech plan、ADR、implementation doc、review/test/release 文档。
|
|
40
40
|
11. 用户明确要求“产品方案 / 产品经理 / 产品专家 / product plan / product manager / product spec”、“设计稿 / UI/UX 设计方案 / 视觉专家 / UX designer / UI designer / visual polish / design system spec”或“开发工程师 / 技术方案 / 开发方案 / 实现 / 实现方案 / 实施计划 / 技术专家 / software engineer / development plan / technical implementation plan / 多开agent / subagent”这类角色或强产物名时，使用对应 Context authoring Skill，把长期结论写回 `project_context/**`。
|
|
41
41
|
12. 用户明确要求“导出尽可能详细的项目全量上下文 / 全量上下文导出 / 项目整体上下文 / full project context export / export full project context / project context export / project overall context / 当前项目代码实现 / 代码级实现导出 / code-level implementation export / Source Pack export / source-pack export / task context export / code index export”时，使用 `context_full_project_export` Skill；默认优先运行 `ty-context export-context --source-pack` 生成最多 5 个临时上传文件到 `tmp/ty-context/context-exports/latest/`，且只保留 `latest/` 导出轮次；只需要导航索引用 `--code-index`，聚焦交接用 `--task-context <name>`，需要 legacy 单文件完整代码快照时再用 `--code`，需要 legacy Context+代码双导出时可用 `--all`；导出产物只放 `tmp/ty-context/context-exports/**`，不得放入或注册到 `project_context/**` / `project_context/context.toml`。用户明确要求“upgrade Tiny Context / update Tiny Context / Project Tiny Context Harness upgrade / 用 Tiny Context upgrade skill 升级这个项目 / 升级 tiny context”时，使用 `context_harness_upgrade` Skill，先走 `upgrade`，不要先单独运行 `sync`。
|
|
42
|
-
13. 长程任务不要靠宽泛关键词自动触发临时验收流程；需要普通长程任务包时，建议用户直接调用 `/normal-long-task
|
|
42
|
+
13. 长程任务不要靠宽泛关键词自动触发临时验收流程；需要普通长程任务包时，建议用户直接调用 `/normal-long-task`；已有 Product / Architecture Source、Technical Realization Plan 和 Acceptance Checklist 且需要 Superpowers 目标模式文本时，建议直接调用 `/superpowers-long-task`。输出只放 `tmp/ty-context/plan-acceptance/**`，它们只定义验收标准、执行提示词或临时执行证据，不执行计划、不证明完成、不把结果注册到 `project_context/**` / `project_context/context.toml`。
|
|
43
43
|
14. 当任务涉及设计稿、重做设计、视觉方案、设计系统、visual polish、frontend redesign 或 frontend styling，且存在可扫描的 UI 代码、页面文件、构建产物目录或本地/远程 URL 时，默认运行 `npx impeccable detect <target>` 做 Impeccable 视觉审查；没有可扫描目标、命令不可用或扫描失败时，说明原因并继续。Impeccable 不是 `validate-context` gate，也不替代截图检查、项目测试或人工判断。
|
|
44
44
|
15. Tiny Context / Harness managed surfaces 是生成资产：`AGENTS.md` managed block、`.agent/ty-context-managed/**`、`.agent/skills/context_product_plan/**`、`.agent/skills/context_uiux_design/**`、`.agent/skills/context_development_engineer/**`、`.agent/skills/context_surface_contract/**`、`.agent/skills/context_full_project_export/**`、`.agent/skills/context_harness_upgrade/**`、`.agent/skills/normal-long-task/**` 和 `.agent/skills/superpowers-long-task/**` 禁止承载项目特定规则；直接编辑会在 `sync` 时被覆盖或产生漂移。项目本地产品 / UIUX / 开发 / surface contract 规则必须新建独立 Skill，例如 `.agent/skills/product_plan/SKILL.md`、`.agent/skills/uiux_design/SKILL.md`、`.agent/skills/development_engineer/SKILL.md` 或 `.agent/skills/surface_contract/SKILL.md`；当项目本地 Skill 与默认 Skill 同时适用时，优先使用更具体的项目本地 Skill。项目本地 Skill 的 front matter `description` 触发词应与本文件中的角色触发规则和对应默认 `context_*` Skill 保持一致；新增或收窄关键词时，同步更新本地 Skill 描述和项目级 agent 指引，避免 Skill 触发条件与 Tiny Context 工作规则漂移。
|
|
45
45
|
16. ADR 降级为 Context 中的 `Design Rationale`；实现说明优先写成代码注释、测试名或模块 Context 中的关键约束。
|
|
@@ -1,256 +1,362 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: superpowers-long-task
|
|
3
|
-
description: Use when directly invoked for Superpowers long-running task target prompt preparation.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Superpowers Long Task Skill
|
|
7
|
-
|
|
8
|
-
## Package-Managed Boundary
|
|
9
|
-
|
|
10
|
-
This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `superpowers-long-task` Skill directly in a consumer project.
|
|
11
|
-
|
|
12
|
-
This is Tiny Context's adapter for feeding a
|
|
13
|
-
|
|
14
|
-
## Purpose
|
|
15
|
-
|
|
16
|
-
Consumes
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
Use this Skill
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
-
|
|
37
|
-
|
|
38
|
-
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
The
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
-
|
|
51
|
-
-
|
|
52
|
-
-
|
|
53
|
-
-
|
|
54
|
-
-
|
|
55
|
-
-
|
|
56
|
-
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
-
|
|
65
|
-
-
|
|
66
|
-
-
|
|
67
|
-
-
|
|
68
|
-
|
|
69
|
-
Do not
|
|
70
|
-
|
|
71
|
-
##
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
-
|
|
76
|
-
-
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
-
|
|
93
|
-
|
|
94
|
-
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
-
|
|
123
|
-
-
|
|
124
|
-
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
-
|
|
142
|
-
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
-
|
|
152
|
-
-
|
|
153
|
-
-
|
|
154
|
-
-
|
|
155
|
-
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
-
|
|
170
|
-
-
|
|
171
|
-
-
|
|
172
|
-
-
|
|
173
|
-
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
-
|
|
206
|
-
|
|
207
|
-
|
|
208
|
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
-
|
|
220
|
-
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
##
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
-
|
|
233
|
-
-
|
|
234
|
-
-
|
|
235
|
-
-
|
|
236
|
-
-
|
|
237
|
-
|
|
238
|
-
|
|
239
|
-
|
|
240
|
-
-
|
|
241
|
-
-
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
|
|
252
|
-
|
|
253
|
-
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
|
|
1
|
+
---
|
|
2
|
+
name: superpowers-long-task
|
|
3
|
+
description: Use when directly invoked for Superpowers long-running task target prompt preparation.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Superpowers Long Task Skill
|
|
7
|
+
|
|
8
|
+
## Package-Managed Boundary
|
|
9
|
+
|
|
10
|
+
This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `superpowers-long-task` Skill directly in a consumer project.
|
|
11
|
+
|
|
12
|
+
This is Tiny Context's adapter for feeding a recommended three-input long-task packet into the external Superpowers workflow. It is not a Superpowers official schema and 不是 Superpowers 官方 schema. It only makes the target-mode prompt explicit enough that the official Superpowers skills can do their intended work without losing Tiny Context context-delta, plan-conformance and acceptance authority.
|
|
13
|
+
|
|
14
|
+
## Purpose
|
|
15
|
+
|
|
16
|
+
Consumes three existing upstream inputs and emits a paste-ready Superpowers target-mode prompt:
|
|
17
|
+
|
|
18
|
+
- Product / Architecture Source: original intent source for scope, product logic, surface responsibility and durable architecture intent.
|
|
19
|
+
- Technical Realization Plan: the execution blueprint and plan-conformance source.
|
|
20
|
+
- Acceptance Checklist: the acceptance authority and final-verdict source.
|
|
21
|
+
|
|
22
|
+
Use this Skill only after all three inputs already exist or are pasted in full. Two-document compatibility is allowed only when the first document explicitly contains both Product / Architecture Source and Technical Realization Plan sections; otherwise stop for a missing Technical Realization Plan. Do not generate, derive, or infer the Technical Realization Plan. Do not generate, derive, rewrite, strengthen, or repair the full checklist in this Skill. If plan items or ACs are too vague to trace, stop and ask for the missing fields. If only generic conformance or verdict rules are missing, inject this Skill's default rules into the generated prompt.
|
|
23
|
+
|
|
24
|
+
## Direct Invocation
|
|
25
|
+
|
|
26
|
+
Use this Skill through explicit invocation:
|
|
27
|
+
|
|
28
|
+
```text
|
|
29
|
+
/superpowers-long-task
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
Do not rely on broad automatic keyword routing. `/normal-long-task` remains useful for ordinary acceptance preparation, but this Skill does not require it when the product/architecture source, technical realization plan and acceptance checklist are already supplied.
|
|
33
|
+
|
|
34
|
+
## Use Cases
|
|
35
|
+
|
|
36
|
+
Use this Skill when a three-input long-task packet needs:
|
|
37
|
+
|
|
38
|
+
- Superpowers target-mode prompt.
|
|
39
|
+
- Superpowers goal-mode prompt.
|
|
40
|
+
- Superpowers 目标模式文本.
|
|
41
|
+
- Superpowers-compatible Codex target prompt.
|
|
42
|
+
- Superpowers execution binding with Context Delta, plan-conformance and acceptance-evidence gates.
|
|
43
|
+
|
|
44
|
+
Do not trigger merely because a plan mentions TDD or subagents. The user must ask for a Superpowers target/goal prompt or equivalent execution adapter.
|
|
45
|
+
|
|
46
|
+
## Required Three-Input Packet
|
|
47
|
+
|
|
48
|
+
The input must fully expose these fields:
|
|
49
|
+
|
|
50
|
+
- Product / Architecture Source path or pasted text.
|
|
51
|
+
- original requirement source or original plan summary.
|
|
52
|
+
- durable product intent when applicable: product capability, user flow, business state/rule, page/surface responsibility, information architecture, product ownership, status meaning, operation boundary or acceptance semantics.
|
|
53
|
+
- durable architecture intent when applicable: module boundary, dependency direction, API/schema/data/event contract, worker/runtime/state-machine semantics, verification/deployment path or stable technical tradeoff.
|
|
54
|
+
- Technical Realization Plan path or pasted text.
|
|
55
|
+
- traceable plan items or sections that affect behavior.
|
|
56
|
+
- expected implementation surfaces when applicable: code, API/schema, UI/page, worker/runtime, artifact, data, tests.
|
|
57
|
+
- required code/API/schema/UI/worker/runtime/data/test/evidence mapping when applicable.
|
|
58
|
+
- full-scope versus sample/optional boundaries.
|
|
59
|
+
- explicitly non-completing shortcuts, such as local-only enhancement, old page continuing to own a moved responsibility, sampled path, plan-only work or test-only patch.
|
|
60
|
+
- full acceptance checklist path or pasted text.
|
|
61
|
+
- acceptance items or AC IDs.
|
|
62
|
+
- required evidence and verification method per AC.
|
|
63
|
+
- required tests or explicit no-test scope.
|
|
64
|
+
- valid and invalid evidence rules.
|
|
65
|
+
- Completion State Machine rules.
|
|
66
|
+
- UI-Facing Gate rules when any AC touches UI.
|
|
67
|
+
- hard blockers or an explicit no-blocker statement.
|
|
68
|
+
|
|
69
|
+
If any of these are missing required fields, stop. Do not generate the Superpowers target-mode prompt. Report whether each missing field belongs in Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, blocker section or Context reference. If the user supplied only a product/architecture source plus checklist, report missing Technical Realization Plan.
|
|
70
|
+
|
|
71
|
+
## Source Roles
|
|
72
|
+
|
|
73
|
+
- Product / Architecture Source prevents scope shrinkage and drives Product Context Delta / architecture-intent checks; it is not the code construction plan.
|
|
74
|
+
- Technical Realization Plan is the execution blueprint and the source for `plan-conformance-matrix.*`; it is not proof.
|
|
75
|
+
- Acceptance Checklist is the completion authority and the source for `final-acceptance-verdict.*`.
|
|
76
|
+
- local audit records progress, candidate status, evidence, blockers and invalidating evidence only; it is not proof and must not mark final completion.
|
|
77
|
+
- relevant Context remains the durable repo intent and boundary source.
|
|
78
|
+
- required tests / core paths bind plan and AC gaps to executable verification.
|
|
79
|
+
|
|
80
|
+
Do not let a compact target prompt override the product/architecture source, technical realization plan or full checklist. The compact prompt is direction, priority and recovery navigation only. The technical realization plan controls plan conformance; the product/architecture source prevents scope shrinkage; the full checklist controls acceptance.
|
|
81
|
+
|
|
82
|
+
## Context Delta Assessment
|
|
83
|
+
|
|
84
|
+
The prompt must require the future executor to evaluate Context before implementation using:
|
|
85
|
+
|
|
86
|
+
```text
|
|
87
|
+
Product Context Delta: none|required
|
|
88
|
+
Technical Context Delta: none|required
|
|
89
|
+
Context Delta: none|required
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Any required sub-delta makes overall Context Delta required. This is prompt-level workflow discipline, not a validator gate, not a machine-enforced gate, not a phase gate and not a new document chain.
|
|
93
|
+
|
|
94
|
+
`Product Context Delta: required` applies when the product/architecture source changes durable product facts such as product capability, user flow, business state/rule, page or surface responsibility, main/drilldown ownership, information architecture, user-visible terminology, status meaning, operation boundary, product/domain ownership or acceptance semantics.
|
|
95
|
+
|
|
96
|
+
`Technical Context Delta: required` applies when the product/architecture source or Technical Realization Plan changes durable technical facts such as API/schema/event/data contract, module ownership, dependency direction, worker/runtime/state-machine semantics, data model, persistence, scheduling, failure/retry/recovery semantics, verification/deployment/bootstrap path or stable technical tradeoff.
|
|
97
|
+
|
|
98
|
+
When overall `Context Delta: required`, the executor must update the smallest owning `project_context/**` or `DESIGN.md` fact before implementation continues. Use existing roles only: `area`, `subdomain`, `contract`, `foundation`, `verification`, `deployment`, `implementation-index` and `decision-rationale`. Do not write local audit, plan-conformance matrix, final acceptance verdict, temporary plan, sampled evidence, one-off logs, raw outputs, screenshots or PR notes into Context.
|
|
99
|
+
|
|
100
|
+
## Plan Conformance Gate
|
|
101
|
+
|
|
102
|
+
The prompt must require the future executor to create or initialize `tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md` and `.json` before substantial implementation, then update it after each meaningful implementation slice.
|
|
103
|
+
|
|
104
|
+
Each behavior-affecting Technical Realization Plan item must have a trace entry with:
|
|
105
|
+
|
|
106
|
+
- plan item id and plan requirement.
|
|
107
|
+
- expected surfaces.
|
|
108
|
+
- implemented paths.
|
|
109
|
+
- missing paths.
|
|
110
|
+
- tests.
|
|
111
|
+
- runtime or artifact evidence.
|
|
112
|
+
- scope assessment.
|
|
113
|
+
- status.
|
|
114
|
+
- drift.
|
|
115
|
+
|
|
116
|
+
Allowed plan-conformance statuses:
|
|
117
|
+
|
|
118
|
+
- `complete`
|
|
119
|
+
- `partial`
|
|
120
|
+
- `sampled_only`
|
|
121
|
+
- `not_implemented`
|
|
122
|
+
- `blocked`
|
|
123
|
+
- `scope_changed_requires_user_approval`
|
|
124
|
+
- `contradicted_by_current_state`
|
|
125
|
+
|
|
126
|
+
Hard rules:
|
|
127
|
+
|
|
128
|
+
- Passing tests does not imply plan conformance.
|
|
129
|
+
- A sampled implementation path does not imply full plan implementation.
|
|
130
|
+
- A local audit cannot narrow plan scope or mark completion.
|
|
131
|
+
- Scope correction requires explicit user approval or a revised product/architecture source, Technical Realization Plan and checklist.
|
|
132
|
+
- Every behavior-affecting plan section must have an implementation trace entry.
|
|
133
|
+
- Any `partial`, `sampled_only`, `not_implemented`, unresolved blocker, unapproved scope change or current contradiction prevents overall done.
|
|
134
|
+
|
|
135
|
+
## Acceptance Evidence Gate
|
|
136
|
+
|
|
137
|
+
The prompt must require the future executor to generate `tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md` and `.json` only at the final gate, after Context Delta handling, Plan Conformance Gate and current evidence checks.
|
|
138
|
+
|
|
139
|
+
Each AC verdict entry must include:
|
|
140
|
+
|
|
141
|
+
- AC id or acceptance item.
|
|
142
|
+
- status.
|
|
143
|
+
- required evidence.
|
|
144
|
+
- fresh evidence.
|
|
145
|
+
- missing evidence.
|
|
146
|
+
- contradictions.
|
|
147
|
+
- decision.
|
|
148
|
+
|
|
149
|
+
Allowed AC statuses:
|
|
150
|
+
|
|
151
|
+
- `complete`
|
|
152
|
+
- `partial`
|
|
153
|
+
- `blocked`
|
|
154
|
+
- `not_run`
|
|
155
|
+
- `invalidated`
|
|
156
|
+
|
|
157
|
+
Hard rules:
|
|
158
|
+
|
|
159
|
+
- Final completion requires an AC-by-AC final acceptance verdict.
|
|
160
|
+
- Current API/UI/runtime/data/test contradictions override historical passing evidence.
|
|
161
|
+
- local audit, subagent summaries, final result card text, passing test logs, stale artifacts, partial smoke, dry-run or sampled paths cannot prove completion by themselves.
|
|
162
|
+
- Any current contradiction downgrades the affected AC and overall status.
|
|
163
|
+
- Scope narrowing in audit does not modify acceptance unless the user approved a revised source/plan/checklist.
|
|
164
|
+
|
|
165
|
+
## Evidence Layer Separation
|
|
166
|
+
|
|
167
|
+
Keep these layers separate in the prompt when relevant:
|
|
168
|
+
|
|
169
|
+
- code implemented.
|
|
170
|
+
- API/schema reflected.
|
|
171
|
+
- worker/runtime path reflected.
|
|
172
|
+
- UI/page reflected.
|
|
173
|
+
- runtime configured.
|
|
174
|
+
- runtime exercised.
|
|
175
|
+
- artifact generated.
|
|
176
|
+
- artifact accepted by validator.
|
|
177
|
+
- API/UI reflects accepted evidence.
|
|
178
|
+
- browser or user path verified.
|
|
179
|
+
- final gate/check command passed.
|
|
180
|
+
|
|
181
|
+
A plan item or AC cannot be complete when its required layer is missing.
|
|
182
|
+
|
|
183
|
+
## Invalid Evidence Rules
|
|
184
|
+
|
|
185
|
+
The prompt must reject false proof:
|
|
186
|
+
|
|
187
|
+
- viewmodel-only does not prove a real page.
|
|
188
|
+
- unit test does not prove real API behavior or latency.
|
|
189
|
+
- artifact exists does not prove artifact accepted by validator.
|
|
190
|
+
- old result does not prove current state.
|
|
191
|
+
- build passes does not prove product acceptance.
|
|
192
|
+
- stale, partial, smoke-only, dry-run, sampled-only or research evidence cannot prove full completion.
|
|
193
|
+
- unresolved API/UI/data/runtime/test contradictions invalidate completion claims.
|
|
194
|
+
|
|
195
|
+
## Completion State Machine
|
|
196
|
+
|
|
197
|
+
Every plan item and AC starts as `unknown / not_run`.
|
|
198
|
+
|
|
199
|
+
Only fresh required evidence can mark a plan item or AC complete.
|
|
200
|
+
|
|
201
|
+
Any fresh browser / API / runtime / data / test contradiction must downgrade the affected plan item, AC and overall status and must be recorded as invalidating evidence. Do not preserve a previous complete status after contradictory fresh evidence appears.
|
|
202
|
+
|
|
203
|
+
## UI-Facing Gate
|
|
204
|
+
|
|
205
|
+
For UI-facing acceptance, the executor must open the real page path and confirm the user-visible state matches the AC. component / viewmodel / mock / unit test evidence is auxiliary unless the full checklist explicitly says otherwise.
|
|
206
|
+
|
|
207
|
+
## Autonomous Progress Protocol
|
|
208
|
+
|
|
209
|
+
The Superpowers target prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries. Do not ask the user for work the executor can safely discover, run, inspect or verify itself.
|
|
210
|
+
|
|
211
|
+
The Superpowers target prompt must inherit current repository/global `AGENTS.md` or agent-instruction permission policy. Authorized `sudo` / `gsudo` / administrator elevation is not a user blocker; the executor must try it before pausing. Pause only if elevation is unavailable, fails, or requires user/system authorization.
|
|
212
|
+
|
|
213
|
+
Pause only for locally unsatisfiable hard blockers such as missing accounts, credentials, production access, paid services, legal/security approval, user-only browser sessions or sensitive fields the executor cannot access safely. When pausing, give the minimum user action list: exact page, system, command or owner to open/contact; exact field or value location; how to redact or avoid sending sensitive values; what the executor will do immediately after receiving the input.
|
|
214
|
+
|
|
215
|
+
## Official Superpowers Binding
|
|
216
|
+
|
|
217
|
+
Bind the target prompt to the official Skill names and their documented roles:
|
|
218
|
+
|
|
219
|
+
- If the Technical Realization Plan is not bite-sized enough, use `superpowers:writing-plans`.
|
|
220
|
+
- Prefer `superpowers:subagent-driven-development` when subagents are available.
|
|
221
|
+
- Use `superpowers:executing-plans` when executing a written plan without the same-session subagent workflow.
|
|
222
|
+
- Plan or AC behavior gap -> TDD: each behavior gap uses `superpowers:test-driven-development` to write a failing test, observe failure, then implement minimally.
|
|
223
|
+
- Before any completion claim, use `superpowers:verification-before-completion` against both `plan-conformance-matrix.*` and `final-acceptance-verdict.*` with fresh evidence.
|
|
224
|
+
- review / finish cannot override the plan-conformance matrix or full checklist; if either gate is unsatisfied, continue implementation or report blockers.
|
|
225
|
+
|
|
226
|
+
If Superpowers is missing, install it through the current platform's official Superpowers installation path. If installation is blocked by permissions, network or platform limits, record the blocker in local audit and do not count it as complete.
|
|
227
|
+
|
|
228
|
+
## Local Audit Requirements
|
|
229
|
+
|
|
230
|
+
The Superpowers target prompt must require the future executor to update local audit after each round with:
|
|
231
|
+
|
|
232
|
+
- candidate status, not final completion.
|
|
233
|
+
- Product Context Delta, Technical Context Delta and overall Context Delta decision.
|
|
234
|
+
- plan item and AC status.
|
|
235
|
+
- current evidence.
|
|
236
|
+
- command/result/time and failure reason.
|
|
237
|
+
- required test command/result/failure.
|
|
238
|
+
- artifact or evidence paths.
|
|
239
|
+
- blockers, missing evidence and acceptance impact.
|
|
240
|
+
- deferred or narrowed scope with user approval state.
|
|
241
|
+
- stale, partial, sampled-only, smoke, dry-run, research or other invalid evidence.
|
|
242
|
+
|
|
243
|
+
The local audit is not Context, not proof, not a global task manager, and not a replacement for project tests, CI, review, human acceptance, Task Contract or workflow-contract `plan.md`. It must not contain `overall_status: done`, `status: done` or `final_gate: passed`; use `candidate_status: claims_done_but_unverified` when needed.
|
|
244
|
+
|
|
245
|
+
## Prompt Generation Rules
|
|
246
|
+
|
|
247
|
+
- The prompt must visibly output `Superpowers 输入包` for Chinese prompts or `Superpowers input packet` for English prompts.
|
|
248
|
+
- The prompt must visibly output `Superpowers 执行绑定` for Chinese prompts or `Superpowers execution binding` for English prompts.
|
|
249
|
+
- The prompt must identify Product / Architecture Source, Technical Realization Plan, Acceptance Checklist, local audit, plan-conformance matrix and final verdict paths at the top.
|
|
250
|
+
- The prompt must state that the Technical Realization Plan controls plan conformance, the Product / Architecture Source prevents scope shrinkage and the full checklist controls acceptance.
|
|
251
|
+
- The prompt must require Product Context Delta and Technical Context Delta evaluation before implementation.
|
|
252
|
+
- The prompt must preserve hard-blocker semantics: if only locally unsatisfiable hard blockers remain, pause for the user or external owner instead of marking complete.
|
|
253
|
+
- The prompt must require maximum safe autonomous progress within current platform, repository, tool and user-authorized permission boundaries and must include the minimum user action list for locally unsatisfiable hard blockers.
|
|
254
|
+
- 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.
|
|
255
|
+
- The prompt must include the resource lifecycle line: `可多开agent，agent名额不够了就关掉不用的。` or `You may use multiple agents; if agent slots run low, close idle or unnecessary agents.`
|
|
256
|
+
- The prompt must fit 3850 characters including line breaks.
|
|
257
|
+
- Do not include explanatory preface inside the generated prompt.
|
|
258
|
+
|
|
259
|
+
Recommended compact Chinese prompt shape:
|
|
260
|
+
|
|
261
|
+
```text
|
|
262
|
+
产品/架构源: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md（原始意图/防 scope shrinkage，非施工图）
|
|
263
|
+
技术实现方案: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md（执行图纸/plan conformance source，非证明）
|
|
264
|
+
验收清单: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md（完整验收标准，final verdict 以它为准）
|
|
265
|
+
执行审计: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md（过程日志，非 proof，不能写 done/final_gate passed）
|
|
266
|
+
对图纸矩阵: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json（先建，边做边更新）
|
|
267
|
+
最终验收: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json（最后逐 AC 生成）
|
|
268
|
+
可多开agent，agent名额不够了就关掉不用的。
|
|
269
|
+
This is not a Superpowers official schema / 不是 Superpowers 官方 schema。
|
|
270
|
+
Superpowers 输入包：
|
|
271
|
+
- Product/Architecture Source：原始产品/架构意图，防止 scope shrinkage，不是施工图
|
|
272
|
+
- Technical Realization Plan：施工图；每个行为 plan item 都要进 matrix
|
|
273
|
+
- Acceptance Checklist：最高验收标准；每个 AC 都要进 final verdict
|
|
274
|
+
- local audit：只记 progress/candidate status/evidence/blocker/invalidating evidence，不能裁判完成
|
|
275
|
+
- Context/tests/core paths：执行前读取，把 plan/AC gap 绑定到测试、API/UI/runtime/browser 证据
|
|
276
|
+
|
|
277
|
+
执行顺序：
|
|
278
|
+
1. 读三份输入和 Context。先写 Task Contract：Product Context Delta none|required；Technical Context Delta none|required；任一 required -> Context Delta required。这不是 validator gate。
|
|
279
|
+
2. Context Delta required 时，先最小更新 owning project_context/** 或 DESIGN.md；不要把 audit/matrix/verdict/日志/截图/sample evidence 写进 Context。
|
|
280
|
+
3. 检查技术实现方案覆盖产品/架构源关键要求；若只有产品方案没有技术实现方案，停止报告 missing Technical Realization Plan，不现场生成。
|
|
281
|
+
4. 初始化 plan-conformance matrix；计划不够 bite-sized 时用 superpowers:writing-plans。
|
|
282
|
+
5. 有 subagent 支持时优先 superpowers:subagent-driven-development，否则 superpowers:executing-plans。
|
|
283
|
+
6. Plan/AC behavior gap -> superpowers:test-driven-development：先写 failing test 并 observe failure，再最小实现。
|
|
284
|
+
7. 每个实现 slice 后更新 matrix 和 audit。
|
|
285
|
+
8. Candidate done 前跑 Plan Conformance Gate：测试通过不等于按图纸完成；sampled path 不等于 full implementation；每个行为 plan item 必须有 code/API/UI/runtime/test/evidence trace。
|
|
286
|
+
9. 再跑 Acceptance Evidence Gate：按验收清单生成 final verdict；current API/UI/runtime/data/test contradiction 高于历史通过记录。
|
|
287
|
+
10. 完成声明前用 superpowers:verification-before-completion 同时检查 matrix 和 verdict；两关不过就继续或报告 blocker。
|
|
288
|
+
|
|
289
|
+
权限/卡点：在当前平台/仓库/工具/用户已授权权限内最大自主推进；已授权 sudo/gsudo/admin elevation 先尝试，不算用户阻塞。只有本地无法解决的账号/凭证/真实环境/人工审批/敏感字段等才暂停，并给最小用户执行清单（具体页面/系统、字段位置、脱敏/勿发值、拿到后下一步）。
|
|
290
|
+
禁止完成于：local audit、subagent summary、final card、只改代码/计划、只跑部分测试、旧/部分/抽样证据、runtime 未演练、artifact 未被 validator accepted、API/UI 未 reflected、未批准 scope narrowing、任何 API/UI/data/runtime/test 矛盾。
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
Recommended compact English prompt shape:
|
|
294
|
+
|
|
295
|
+
```text
|
|
296
|
+
Product / Architecture Source: tmp/ty-context/plan-acceptance/<plan-slug>-product-architecture-source.md (original intent / scope guard, not construction plan)
|
|
297
|
+
Technical Realization Plan: tmp/ty-context/plan-acceptance/<plan-slug>-technical-realization-plan.md (blueprint / plan-conformance source, not proof)
|
|
298
|
+
Acceptance Checklist: tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md (acceptance authority; final verdict is judged against it)
|
|
299
|
+
Local audit: tmp/ty-context/plan-acceptance/<plan-slug>-local-audit.md (process log, not proof; must not write done/final_gate passed)
|
|
300
|
+
Plan matrix: tmp/ty-context/plan-acceptance/<plan-slug>-plan-conformance-matrix.md/json (create early, update during work)
|
|
301
|
+
Final verdict: tmp/ty-context/plan-acceptance/<plan-slug>-final-acceptance-verdict.md/json (generate at final gate, AC by AC)
|
|
302
|
+
You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
|
|
303
|
+
This is not a Superpowers official schema / 不是 Superpowers 官方 schema.
|
|
304
|
+
Superpowers input packet:
|
|
305
|
+
- Product / Architecture Source: original intent; prevents scope shrinkage; not the construction plan.
|
|
306
|
+
- Technical Realization Plan: execution blueprint; every behavior-affecting item needs a matrix trace.
|
|
307
|
+
- Acceptance Checklist: acceptance authority; every AC needs a final verdict entry.
|
|
308
|
+
- Local audit: progress/candidate status/evidence/blockers/invalidating evidence only; never final proof.
|
|
309
|
+
- Context/tests/core paths: read before execution; map plan/AC gaps to test/API/UI/runtime/browser evidence.
|
|
310
|
+
|
|
311
|
+
Execution order:
|
|
312
|
+
1. Read the three inputs and Context. Write Task Contract: Product Context Delta none|required; Technical Context Delta none|required; any required sub-delta makes overall Context Delta required. This is not a validator gate.
|
|
313
|
+
2. If Context Delta required, minimally update the owning project_context/** or DESIGN.md; never store audit/matrix/verdict/logs/screenshots/sample evidence as Context.
|
|
314
|
+
3. Check the Technical Realization Plan covers Product / Architecture Source requirements; if only a product plan exists, stop with missing Technical Realization Plan, do not generate it.
|
|
315
|
+
4. Initialize plan-conformance matrix; use superpowers:writing-plans if the plan is not bite-sized.
|
|
316
|
+
5. Prefer superpowers:subagent-driven-development with subagents; otherwise use superpowers:executing-plans.
|
|
317
|
+
6. Plan/AC behavior gap -> superpowers:test-driven-development: write a failing test, observe failure, then implement minimally.
|
|
318
|
+
7. After each slice, update matrix and audit.
|
|
319
|
+
8. Before candidate done, run Plan Conformance Gate: passing tests does not prove plan conformance; sampled path does not prove full implementation; every behavior plan item needs code/API/UI/runtime/test/evidence trace.
|
|
320
|
+
9. Then run Acceptance Evidence Gate: generate final verdict from the checklist; current API/UI/runtime/data/test contradictions override old passing evidence.
|
|
321
|
+
10. Before completion, use superpowers:verification-before-completion against both matrix and verdict; if either gate fails, continue or report blockers.
|
|
322
|
+
|
|
323
|
+
Autonomy/blockers: within current platform/repo/tool/user-authorized permissions, do all safe self-service discovery/execution/verification. Authorized sudo/gsudo/admin elevation is not a user blocker; try it first. Pause only for locally unsatisfiable account/credential/real-env/human-approval/sensitive-field needs; give exact page/system, field location, redaction/do-not-send values and next agent step.
|
|
324
|
+
Never complete on: local audit, subagent summary, final card, code-only/plan-only work, partial tests, stale/partial/sampled evidence, unexercised runtime, artifact not accepted by validator, API/UI not reflected, unapproved scope narrowing or any API/UI/data/runtime/test contradiction.
|
|
325
|
+
```
|
|
326
|
+
|
|
327
|
+
Before final response, check the prompt length. If it exceeds 3850 characters, tighten wording while preserving paths, input roles, official Superpowers skill names, Product Context Delta, Technical Context Delta, plan-conformance matrix, final verdict, state machine, UI gate, blockers and invalid evidence.
|
|
328
|
+
|
|
329
|
+
## Final Response Requirements
|
|
330
|
+
|
|
331
|
+
When successful, return:
|
|
332
|
+
|
|
333
|
+
- The Product / Architecture Source path.
|
|
334
|
+
- The Technical Realization Plan path.
|
|
335
|
+
- The full checklist path.
|
|
336
|
+
- The local audit path.
|
|
337
|
+
- The plan-conformance matrix path.
|
|
338
|
+
- The final acceptance verdict path.
|
|
339
|
+
- Whether required input was complete.
|
|
340
|
+
- The paste-ready Superpowers target-mode prompt in a code block.
|
|
341
|
+
|
|
342
|
+
When blocked, return:
|
|
343
|
+
|
|
344
|
+
- Missing required fields.
|
|
345
|
+
- Which source should provide each missing field.
|
|
346
|
+
- A clear statement that no Superpowers target-mode prompt was generated.
|
|
347
|
+
|
|
348
|
+
Do not claim any plan item or AC has passed unless the user explicitly asked for current completion audit and current evidence was inspected.
|
|
349
|
+
|
|
350
|
+
## Forbidden Behaviors
|
|
351
|
+
|
|
352
|
+
Do not generate, derive, or infer the Technical Realization Plan.
|
|
353
|
+
|
|
354
|
+
Do not generate, derive, rewrite, strengthen, or repair the full checklist.
|
|
355
|
+
|
|
356
|
+
Do not execute the generated prompt.
|
|
357
|
+
|
|
358
|
+
Do not mark any goal complete.
|
|
359
|
+
|
|
360
|
+
Do not hide missing source files, ambiguous scope, weak evidence, implementation drift or blockers.
|
|
361
|
+
|
|
362
|
+
Do not include business-domain logic, concrete provider names, API names, UI names, artifact schemas or one-off project details in this package-managed Skill.
|
package/package.json
CHANGED
|
@@ -1,68 +1,69 @@
|
|
|
1
|
-
{
|
|
2
|
-
"name": "project-tiny-context-harness",
|
|
3
|
-
"version": "0.2.
|
|
4
|
-
"description": "Minimal project memory and validation harness for AI coding agents.",
|
|
5
|
-
"license": "MIT",
|
|
6
|
-
"author": "Seven128",
|
|
7
|
-
"homepage": "https://github.com/Seven128/project-tiny-context-harness#readme",
|
|
8
|
-
"repository": {
|
|
9
|
-
"type": "git",
|
|
10
|
-
"url": "git+https://github.com/Seven128/project-tiny-context-harness.git",
|
|
11
|
-
"directory": "packages/ty-context"
|
|
12
|
-
},
|
|
13
|
-
"bugs": {
|
|
14
|
-
"url": "https://github.com/Seven128/project-tiny-context-harness/issues"
|
|
15
|
-
},
|
|
16
|
-
"keywords": [
|
|
17
|
-
"ai-agents",
|
|
18
|
-
"coding-agent",
|
|
19
|
-
"codex",
|
|
20
|
-
"claude-code",
|
|
21
|
-
"cursor",
|
|
22
|
-
"gemini-cli",
|
|
23
|
-
"opencode",
|
|
24
|
-
"agent-context",
|
|
25
|
-
"context-engineering",
|
|
26
|
-
"context-management",
|
|
27
|
-
"agents-md",
|
|
28
|
-
"project-memory",
|
|
29
|
-
"agent-memory",
|
|
30
|
-
"ai-coding",
|
|
31
|
-
"multi-agent",
|
|
32
|
-
"llm",
|
|
33
|
-
"developer-tools",
|
|
34
|
-
"developer-productivity",
|
|
35
|
-
"cli",
|
|
36
|
-
"ty-context",
|
|
37
|
-
"workflow"
|
|
38
|
-
],
|
|
39
|
-
"type": "module",
|
|
40
|
-
"bin": {
|
|
41
|
-
"ty-context": "dist/cli.js"
|
|
42
|
-
},
|
|
43
|
-
"files": [
|
|
44
|
-
"README.md",
|
|
45
|
-
"dist",
|
|
46
|
-
"assets",
|
|
47
|
-
"migrations",
|
|
48
|
-
"source-mappings.yaml"
|
|
49
|
-
],
|
|
50
|
-
"scripts": {
|
|
51
|
-
"build": "node -e \"require('node:fs').rmSync('dist',{recursive:true,force:true})\" && tsc -p tsconfig.json",
|
|
52
|
-
"typecheck": "tsc -p tsconfig.json --noEmit",
|
|
53
|
-
"test": "
|
|
54
|
-
"
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
"
|
|
62
|
-
"
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
"
|
|
67
|
-
|
|
68
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"name": "project-tiny-context-harness",
|
|
3
|
+
"version": "0.2.70",
|
|
4
|
+
"description": "Minimal project memory and validation harness for AI coding agents.",
|
|
5
|
+
"license": "MIT",
|
|
6
|
+
"author": "Seven128",
|
|
7
|
+
"homepage": "https://github.com/Seven128/project-tiny-context-harness#readme",
|
|
8
|
+
"repository": {
|
|
9
|
+
"type": "git",
|
|
10
|
+
"url": "git+https://github.com/Seven128/project-tiny-context-harness.git",
|
|
11
|
+
"directory": "packages/ty-context"
|
|
12
|
+
},
|
|
13
|
+
"bugs": {
|
|
14
|
+
"url": "https://github.com/Seven128/project-tiny-context-harness/issues"
|
|
15
|
+
},
|
|
16
|
+
"keywords": [
|
|
17
|
+
"ai-agents",
|
|
18
|
+
"coding-agent",
|
|
19
|
+
"codex",
|
|
20
|
+
"claude-code",
|
|
21
|
+
"cursor",
|
|
22
|
+
"gemini-cli",
|
|
23
|
+
"opencode",
|
|
24
|
+
"agent-context",
|
|
25
|
+
"context-engineering",
|
|
26
|
+
"context-management",
|
|
27
|
+
"agents-md",
|
|
28
|
+
"project-memory",
|
|
29
|
+
"agent-memory",
|
|
30
|
+
"ai-coding",
|
|
31
|
+
"multi-agent",
|
|
32
|
+
"llm",
|
|
33
|
+
"developer-tools",
|
|
34
|
+
"developer-productivity",
|
|
35
|
+
"cli",
|
|
36
|
+
"ty-context",
|
|
37
|
+
"workflow"
|
|
38
|
+
],
|
|
39
|
+
"type": "module",
|
|
40
|
+
"bin": {
|
|
41
|
+
"ty-context": "dist/cli.js"
|
|
42
|
+
},
|
|
43
|
+
"files": [
|
|
44
|
+
"README.md",
|
|
45
|
+
"dist",
|
|
46
|
+
"assets",
|
|
47
|
+
"migrations",
|
|
48
|
+
"source-mappings.yaml"
|
|
49
|
+
],
|
|
50
|
+
"scripts": {
|
|
51
|
+
"build": "node -e \"require('node:fs').rmSync('dist',{recursive:true,force:true})\" && tsc -p tsconfig.json",
|
|
52
|
+
"typecheck": "tsc -p tsconfig.json --noEmit",
|
|
53
|
+
"test:built": "node --test ../../tests/ty-context/*.test.mjs",
|
|
54
|
+
"test": "npm run build && node --test ../../tests/ty-context/*.test.mjs",
|
|
55
|
+
"prepack": "npm run build"
|
|
56
|
+
},
|
|
57
|
+
"engines": {
|
|
58
|
+
"node": ">=20"
|
|
59
|
+
},
|
|
60
|
+
"dependencies": {
|
|
61
|
+
"@google/design.md": "^0.2.0",
|
|
62
|
+
"impeccable": "^2.3.2",
|
|
63
|
+
"yaml": "^2.9.0"
|
|
64
|
+
},
|
|
65
|
+
"devDependencies": {
|
|
66
|
+
"@types/node": "^24.0.0",
|
|
67
|
+
"typescript": "^5.5.0"
|
|
68
|
+
}
|
|
69
|
+
}
|