taskplane

View saved version →

---
name: taskplane
description: Route requests to review code, design a change, implement work, inspect Taskplane status, or explain Taskplane. Preserve the user's requested scope and existing decisions.
---

# Taskplane

Before creating state, apply the [workspace and execution contract](../tp-go/references/shared-flow.md#workspace-and-execution-contract).
Cowork requires an explicit selected-project binding; honor the user's storage,
command and worker location restrictions separately. Missing mapping or required
locality evidence is a blocker, not permission to use a session directory.
Then resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase taskplane --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Route the requested work directly. Product, Design, and Engineering always use the
shared dependency graph, task decomposition, and dashboard, including standalone
requests. Read [the shared flow](../tp-go/references/shared-flow.md) for these defaults.
Help and status inspect existing state without starting a run. The default native_workflow
profile enforces Taskplane gates using observed human responses and local state. Host-wide
protection is unavailable; explicitly requested protected_host execution still refuses
without a verified owner. Never substitute one profile for the other.

- Source review, architecture/security review, or validation: read
  [engineering](../tp-engineering/SKILL.md) and use native tools in the available checkout.
- Status: read [status](../tp-status/SKILL.md). Inspect existing state without initializing it.
- Help: read [help](../tp-help/SKILL.md). Answer the question without setup.
- Product requirements: read [product](../tp-product/SKILL.md).
- Design before implementation: read [design](../tp-design/SKILL.md).
- Build or fix an approved delivery plan: read [delivery](../tp-go/SKILL.md).
  For a new feature or explicit A/B prototype, use [build](../tp-build/SKILL.md).
- Explicit installation, setup, or configuration diagnostics: read
  [CLI reference](../../docs/cli-reference.md).

Product, Design, Plan, Build, Evaluate, Engineering and Retro each require acceptance
of their concrete output before advancement: human approval by default, or a valid
explicitly authorized policy decision under the shared flow. Engineering can be the entry point: its findings can define subsequent
Product scope, Design, and implementation when authorized. Keep native execution,
permissions, waiting, and session identity with the
host. Load only the selected workflow's references; don't recite internal setup or
introduce approval steps that the user has already satisfied.

Native discovery is observational. Use the installed named hook entry points and
report their actual capability status; restoring native routines does not admit
a host owner or change any human checkpoint.

## Scoped native workers

Native dispatch is the default for useful independent work under this skill.
Every new run scope must declare `execution_contract: "native-default/v1"`; this
is mandatory in this entry flow. Publish typed `execution: "native_required"`
tasks for ready independent work and one worker per selected Engineering lens,
with a unique `review_lens` on each lens task. This instruction authorizes that
bounded delegation; do not ask again solely because the user did not name agents.

Explicit user serial/no-delegation constraints take priority. Dependencies,
read/write conflicts and trivial scope can justify `execution: "root"` with a
substantive `execution_reason` and `execution_reference`. Root lens coverage is
`serial_scope`, never native independence. Observe host capacity, launch ready
independent tasks together and refill slots as prerequisites complete. Limited
capacity queues distinct workers; reusing one identity for several lenses does
not satisfy independence. An unavailable adapter needs an observed reason/reference;
required native tasks remain incomplete and block sealing.

Use the installed prepare/claim/context/join/result protocol. Execute the exact
returned `next_action` with the installed runtime launcher; it retains workspace,
run and task. Follow `--read-required` actions until `remaining_required` is zero.
Workers return scoped evidence. Only the root verifies and accepts joined fresh
results and advances phases under the existing approval policy. `native_verified`
lens coverage binds `task_id`, `grant` and the actual worker `reviewer`; labels alone
cannot satisfy frozen requirements. Historical untyped evidence stays unverified.


## Efficient native startup and context

For every new native task, declare exact `read_inputs` from the run verification
inputs or accepted Build paths, a concise `purpose`, and `context_budget_bytes`
(default 128 KiB of unique required bodies). Include source dependencies and tests
needed for the conclusion; narrow inputs must not hide a relevant dependency.
Missing read inputs retain conservative legacy coverage. Inspect preparation's
`context_preflight` before launch. Declare source/log/test detail artifacts as
`source`, `raw-log`, `verification` or `supporting`; keep concise requirements and
reports normative. Use `required_for` when supporting bodies are mandatory.

Always supply `fork_turns: "none"` explicitly. Start the first useful scoped task,
then observe its successful claim, complete context and matching automatic pre/post
hook pair before preparing the rest of the cohort. Scoped preparation enforces
this automatically; `readiness_after` can name an additional same-phase startup
prerequisite. Release remaining ready work together while the first task works.
Do not use throwaway probes or relaunch unchanged failures. A repeated scoped
attempt needs `retry_reason` naming the observed defect or changed input.

Execute the exact returned context action. New scoped workers use `--drain`, which
returns at most 32 KiB including bodies and receipt. Return every response to the
consumer, then follow `next_action` only while `remaining_required` is nonzero.
Terminal responses have `done: true` and no action. Accumulate all subprocess/tool
chunks until exit before parsing; never parse a running handle's partial output.
Keep the combined response budget large enough and use bounded long waits (up to
60 seconds between user updates), not repeated short model-facing polls.

After a narrow repair, repeat affected checks and reviewers only. Unchanged
scoped results remain fresh within their original binding; across visits use
independently fingerprinted check evidence and a fresh scoped delta review.
Never transfer approval, worker identity or a context receipt to another binding.
Inspect attempt purposes, retry causes and delivered bytes in worker status and
the dashboard. Delivered bytes, native tokens and Codex allowance are different
measurements; no allowance saving can be inferred from byte counts alone.

View saved version →

---
name: tp-build
description: Build a requested feature through to verified output. Reuse existing product decisions and use optional alternatives only when requested or needed.
---

# Build a feature

Before substantive work, resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-build --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Read [delivery](../tp-go/SKILL.md) and execute its flow. The root orchestrator
owns completion. Clarify the outcome, inspect the existing implementation, make
the smallest sufficient design, build, verify, and deliver.

Use a visual when it helps settle a UI decision; do not require one for backend
work. Discuss alternatives when a consequential trade-off needs a decision.
Build A/B variants only when requested, in separate checkouts, and let the user
select before integrating mutually exclusive variants. Do not create multiple
implementations or review waves by default.

Reuse authorization already given. Missing telemetry or a
review quota must not block authorized implementation. Native host permissions
remain in force.

## Shared delivery state

Follow [the shared flow](../tp-go/references/shared-flow.md) for every execution.
Use the shared run, task decomposition, dependency graph and dashboard, including
work originating in a standalone phase. Return evidence to that run; the root
orchestrator owns stage advancement.

The shared flow defaults to explicit human approval at each phase checkpoint.
A recorded, explicit run policy may authorize automatic approval as described there. Use
the dependency graph with source component decomposition, task DAG and shared
dashboard throughout. Unsupported host authority must be reported, never bypassed.

## Consume bounded context

After activation, start, advancement or resumption, use the installed runtime's
`flow context --workspace <checkout> --run <run>` and consume the returned
handoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for
focused work. Read every omitted required input using `--read <ref-sha256>`;
follow index children and page cursors until all required bodies are returned.
A fresh consumer receives these bodies, scoped source and relevant findings;
do not copy the predecessor conversation or tool history into its instructions.
No context operation authorizes dispatch or a phase transition.

For phase submission, obtain a current whole-phase receipt (without `--task`)
and include the returned `context_receipt` object in the phase output. Renew it
after source, scope, revision or accepted input changes. New bounded/v1 runs
reject missing, partial, foreign or stale receipts. Legacy runs keep their
original evidence contract. A receipt proves returned data, not model attention.

Routine command summaries preserve the current gate and reference full details.
Expand specific references when needed; request `--full` only for a consumer that
requires the complete legacy report. Native dashboards retain complete evidence.
Reuse a prior passing check only when its verification record matches current
source/dependency, tests, runtime, environment, command and criteria fingerprints.
Retain failed/unknown results and findings; reuse never transfers approval.

## Scoped native workers

When authorized, use the installed native dispatch protocol: root prepares a run-bound
task grant, the observed worker claims its identity and consumes its own task context,
and root verifies the joined result before satisfying dependencies. Fill observed
capacity with useful independent work; two is only the minimum live acceptance test.
Workers return evidence and cannot operate root phase controls or publish task definitions.
Require actual loaded-runtime and native execution evidence for live claims.

View saved version →

---
name: tp-design
description: Design how a requested change should work before implementation, with proportionate alternatives, dependencies, trade-offs, and validation.
---

# Design the requested change

Before substantive work, resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-design --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Inspect the relevant requirements and current code with native tools. Reuse
existing decisions. Describe the smallest workable approach, the interfaces and
data it changes, meaningful alternatives, risks, and how success will be tested.
Use a diagram or mockup only if it makes a decision easier.

Follow [the shared flow](../tp-go/references/shared-flow.md) for standalone Design
and delivery alike. Start/reuse the relevant run at Design, inspect dependencies
and source decomposition, attach the design task decomposition and evidence, and
render the shared dashboard. Reuse Product criteria or Engineering findings.

Keep detail proportionate to the change. Do not require a lens quota, signed
artifact, or separate designer. The root
orchestrator owns the handoff and assesses readiness from the actual design.
A design-only request ends with the design; it does not authorize implementation.
Present the design and resolve this checkpoint through the shared approval policy before continuing
via [delivery](../tp-go/SKILL.md). Reuse an existing valid Design approval.

Record useful milestones and refresh the shared dashboard throughout Design.
Missing observations are advisory and do not invalidate the design.

## Shared delivery state

Standalone and delivery Design use the same run, task decomposition, dependency
graph and dashboard defaults. Return evidence to that run; the root orchestrator
owns stage advancement and respects Design-only scope.

The shared flow defaults to explicit human approval at each phase checkpoint.
A recorded, explicit run policy may authorize automatic approval as described there. Use
the dependency graph with source component decomposition, task DAG and shared
dashboard throughout. Unsupported host authority must be reported, never bypassed.

## Consume bounded context

After activation, start, advancement or resumption, use the installed runtime's
`flow context --workspace <checkout> --run <run>` and consume the returned
handoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for
focused work. Read every omitted required input using `--read <ref-sha256>`;
follow index children and page cursors until all required bodies are returned.
A fresh consumer receives these bodies, scoped source and relevant findings;
do not copy the predecessor conversation or tool history into its instructions.
No context operation authorizes dispatch or a phase transition.

For phase submission, obtain a current whole-phase receipt (without `--task`)
and include the returned `context_receipt` object in the phase output. Renew it
after source, scope, revision or accepted input changes. New bounded/v1 runs
reject missing, partial, foreign or stale receipts. Legacy runs keep their
original evidence contract. A receipt proves returned data, not model attention.

Routine command summaries preserve the current gate and reference full details.
Expand specific references when needed; request `--full` only for a consumer that
requires the complete legacy report. Native dashboards retain complete evidence.
Reuse a prior passing check only when its verification record matches current
source/dependency, tests, runtime, environment, command and criteria fingerprints.
Retain failed/unknown results and findings; reuse never transfers approval.

## Scoped native workers

When authorized, use the installed native dispatch protocol: root prepares a run-bound
task grant, the observed worker claims its identity and consumes its own task context,
and root verifies the joined result before satisfying dependencies. Fill observed
capacity with useful independent work; two is only the minimum live acceptance test.
Workers return evidence and cannot operate root phase controls or publish task definitions.
Require actual loaded-runtime and native execution evidence for live claims.

View saved version →

---
name: tp-engineering
description: Review source code, changes, architecture, or security and report actionable findings. Also consumes Engineering evidence when explicitly invoked by a Taskplane delivery stage. Review does not implement fixes.
---

# Engineering review

Before creating state, apply the [workspace and execution contract](../tp-go/references/shared-flow.md#workspace-and-execution-contract),
including for read-only reviews. Bind Cowork's selected project and validate command
and worker locality independently against the user's policy; report missing
capability without substituting serial work for required native reviews.
Then resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-engineering --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Use the current conversation and native tools to inspect the requested repository.
Preserve the user's scope and existing decisions. Follow
[the shared flow](../tp-go/references/shared-flow.md) for every review, standalone or
within delivery: reuse a relevant run or start at Engineering, inspect dependency
impact and source decomposition, attach the review task decomposition and evidence,
and maintain the shared dashboard. Standalone code review starts with `--standalone --phase engineering`; it does not require a full delivery route. The ordinary native workflow uses cooperative local guards; protected host authority remains separately unavailable.

1. Select the readable checkout and the requested revision or comparison. A whole
   repository request includes its tracked source and needs no artificial diff.
   Reuse an available checkout; acquire or transfer source only when it is unavailable.
2. Inspect relevant source with native file, search, and command tools. Follow the
   host's permissions and agent lifecycle. Select useful independent lenses and apply the native dispatch default below,
   respecting explicit serial constraints and observed capacity.
3. Report concrete findings with severity, triggering conditions, file locations,
   and consequences. Distinguish confirmed defects from questions and missing evidence.
   Reuse applicable CI results. Run additional checks only for a specific evidence gap
   or changed behavior, respecting a static-review request.
4. Present the findings and shared dashboard, including an honest coverage summary
   and remaining uncertainty. Update the task and review evidence before rendering;
   acceptance under the shared approval policy is required before advancement. A
   dashboard edit cannot grant it. Apply fixes only through an approved Build scope.
5. When findings lead to Product work, retain their IDs, severity, source locations
   and evidence as Product inputs. Continue the same active run through Product,
   Design and the remaining authorized phases. Engineering is a valid starting
   point, not only a final review stage.

If a pinned inventory is useful, resolve the installed plugin's `taskplane/tp.py`
from its supplied root or this skill's location and invoke it with Python:

- `review start --scope repository --workspace <checkout>` for tracked source.
- `review start --base <ref> --workspace <checkout>` for a comparison.

The response references the selected source artifact; read it through native tools.
The inventory captures source only. Reviewers use native tools and the host's permissions.
Attach findings and verification to the shared run. The review follows the shared approval policy. A human must accept any explicit repair or delivery extension; the
root orchestrator prepares and carries out that approved transition.

## Shared delivery state

These defaults apply equally to standalone Engineering and delivery. Use one run,
task decomposition, dependency graph and dashboard for the requested scope. The
root orchestrator owns stage advancement; a review-only request still ends at review.

The shared flow defaults to explicit human approval at each phase checkpoint.
A recorded, explicit run policy may authorize automatic approval as described there. Use
the dependency graph with source component decomposition, task DAG and shared
dashboard throughout. Unsupported host authority must be reported, never bypassed.

## Consume bounded context

After activation, start, advancement or resumption, use the installed runtime's
`flow context --workspace <checkout> --run <run>` and consume the returned
handoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for
focused work. Read every omitted required input using `--read <ref-sha256>`;
follow index children and page cursors until all required bodies are returned.
A fresh consumer receives these bodies, scoped source and relevant findings;
do not copy the predecessor conversation or tool history into its instructions.
No context operation authorizes dispatch or a phase transition.

For phase submission, obtain a current whole-phase receipt (without `--task`)
and include the returned `context_receipt` object in the phase output. Renew it
after source, scope, revision or accepted input changes. New bounded/v1 runs
reject missing, partial, foreign or stale receipts. Legacy runs keep their
original evidence contract. A receipt proves returned data, not model attention.

Routine command summaries preserve the current gate and reference full details.
Expand specific references when needed; request `--full` only for a consumer that
requires the complete legacy report. Native dashboards retain complete evidence.
Reuse a prior passing check only when its verification record matches current
source/dependency, tests, runtime, environment, command and criteria fingerprints.
Retain failed/unknown results and findings; reuse never transfers approval.

## Scoped native workers

Native dispatch is the default for useful independent work under this skill.
Every new run scope must declare `execution_contract: "native-default/v1"`; this
is mandatory in this entry flow. Publish typed `execution: "native_required"`
tasks for ready independent work and one worker per selected Engineering lens,
with a unique `review_lens` on each lens task. This instruction authorizes that
bounded delegation; do not ask again solely because the user did not name agents.

Explicit user serial/no-delegation constraints take priority. Dependencies,
read/write conflicts and trivial scope can justify `execution: "root"` with a
substantive `execution_reason` and `execution_reference`. Root lens coverage is
`serial_scope`, never native independence. Observe host capacity, launch ready
independent tasks together and refill slots as prerequisites complete. Limited
capacity queues distinct workers; reusing one identity for several lenses does
not satisfy independence. An unavailable adapter needs an observed reason/reference;
required native tasks remain incomplete and block sealing.

Use the installed prepare/claim/context/join/result protocol. Execute the exact
returned `next_action` with the installed runtime launcher; it retains workspace,
run and task. Follow `--read-required` actions until `remaining_required` is zero.
Workers return scoped evidence. Only the root verifies and accepts joined fresh
results and advances phases under the existing approval policy. `native_verified`
lens coverage binds `task_id`, `grant` and the actual worker `reviewer`; labels alone
cannot satisfy frozen requirements. Historical untyped evidence stays unverified.


## Efficient native startup and context

For every new native task, declare exact `read_inputs` from the run verification
inputs or accepted Build paths, a concise `purpose`, and `context_budget_bytes`
(default 128 KiB of unique required bodies). Include source dependencies and tests
needed for the conclusion; narrow inputs must not hide a relevant dependency.
Missing read inputs retain conservative legacy coverage. Inspect preparation's
`context_preflight` before launch. Declare source/log/test detail artifacts as
`source`, `raw-log`, `verification` or `supporting`; keep concise requirements and
reports normative. Use `required_for` when supporting bodies are mandatory.

Always supply `fork_turns: "none"` explicitly. Start the first useful scoped task,
then observe its successful claim, complete context and matching automatic pre/post
hook pair before preparing the rest of the cohort. Scoped preparation enforces
this automatically; `readiness_after` can name an additional same-phase startup
prerequisite. Release remaining ready work together while the first task works.
Do not use throwaway probes or relaunch unchanged failures. A repeated scoped
attempt needs `retry_reason` naming the observed defect or changed input.

Execute the exact returned context action. New scoped workers use `--drain`, which
returns at most 32 KiB including bodies and receipt. Return every response to the
consumer, then follow `next_action` only while `remaining_required` is nonzero.
Terminal responses have `done: true` and no action. Accumulate all subprocess/tool
chunks until exit before parsing; never parse a running handle's partial output.
Keep the combined response budget large enough and use bounded long waits (up to
60 seconds between user updates), not repeated short model-facing polls.

After a narrow repair, repeat affected checks and reviewers only. Unchanged
scoped results remain fresh within their original binding; across visits use
independently fingerprinted check evidence and a fresh scoped delta review.
Never transfer approval, worker identity or a context receipt to another binding.
Inspect attempt purposes, retry causes and delivered bytes in worker status and
the dashboard. Delivered bytes, native tokens and Codex allowance are different
measurements; no allowance saving can be inferred from byte counts alone.

View saved version →

---
name: tp-go
description: Carry delivery through seven explicitly accepted phases with shared graph, decomposition, dashboard and verified evidence.
---

# Delivery with explicit approval policy

Before creating state, apply the [workspace and execution contract](references/shared-flow.md#workspace-and-execution-contract).
Bind Cowork's selected project and validate the user's execution policy before
activation or bootstrap writes. A local mount does not establish command or worker
locality. Then resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-go --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Read [the shared flow](references/shared-flow.md) before execution. It owns the
phase policy, shared artifacts, required evidence and host capability boundary.
Product, Design, Plan, Build, Evaluate, Engineering and Retro each require acceptance
of concrete output before the next phase. Human approval is the default; explicit
run-bound authorization may enable policy decisions under the shared flow. The orchestrator
prepares evidence and advances only after that valid decision; it never self-accepts.

At each phase use the shared dependency graph, source component decomposition,
task DAG and dashboard. Standalone Product, Design and Engineering use the same
defaults. Engineering findings can define Product inputs after a human-approved
route extension that retains the finding evidence.

Do useful work within the current authorized phase until its output is reviewable.
Build follows the accepted Plan's exact paths and prerequisites. Verify affected
behavior; repeat checks only after changed inputs, failure or a specific gap.
Evaluate and Engineering do not silently fix source: propose a scoped repair visit
for acceptance. Finish only after every required visit has valid human or authorized policy acceptance.

Use native_workflow inside Codex/Claude: start with an exact scope JSON and the actual
user-request reference; submit evidence and record the explicit response using the
observed-decision envelope documented in the CLI reference. Every transition still
requires a validated checkpoint and the applicable human or policy decision. The local store and provenance are cooperative workflow
controls, not host-authenticated approval or containment. Show workflow availability
separately from the four unavailable host protections. An explicitly requested
protected_host profile must refuse without its trusted owner; never silently downgrade.

Usage remains advisory. Record meaningful progress and evidence, keep unknown usage
visible and use waste advisories to simplify the next deliverable. A telemetry
failure does not erase acceptance; missing required phase evidence blocks submission.
Use [native delegation](references/codex-native-dispatch.md) only when authorized.

Keep event references and observed command handles bound to their conversation,
checkpoint and phase revision. Actor labels and hook activity alone never approve.
Known live work prevents sealing; a cancellation request is not a completion event.
Incomplete native process coverage stays unknown in native_workflow and blocks
protected_host execution. See [CLI contracts](../../docs/cli-reference.md).

Use `flow policy` only for explicit additional user instructions; preserve their actual
provenance, phases, stops and conditions. After each submission, use `flow auto-decide`
only when the current policy permits it, then advance. Pause on refusal; never invent
a human response or ask again when a valid explicit policy already authorizes the
checkpoint. See the shared flow and CLI reference for the exact envelopes.

## Consume bounded context

After activation, start, advancement or resumption, use the installed runtime's
`flow context --workspace <checkout> --run <run>` and consume the returned
handoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for
focused work. Read every omitted required input using `--read <ref-sha256>`;
follow index children and page cursors until all required bodies are returned.
A fresh consumer receives these bodies, scoped source and relevant findings;
do not copy the predecessor conversation or tool history into its instructions.
No context operation authorizes dispatch or a phase transition.

For phase submission, obtain a current whole-phase receipt (without `--task`)
and include the returned `context_receipt` object in the phase output. Renew it
after source, scope, revision or accepted input changes. New bounded/v1 runs
reject missing, partial, foreign or stale receipts. Legacy runs keep their
original evidence contract. A receipt proves returned data, not model attention.

Routine command summaries preserve the current gate and reference full details.
Expand specific references when needed; request `--full` only for a consumer that
requires the complete legacy report. Native dashboards retain complete evidence.
Reuse a prior passing check only when its verification record matches current
source/dependency, tests, runtime, environment, command and criteria fingerprints.
Retain failed/unknown results and findings; reuse never transfers approval.

## Scoped native workers

When authorized, use the installed native dispatch protocol: root prepares a run-bound
task grant, the observed worker claims its identity and consumes its own task context,
and root verifies the joined result before satisfying dependencies. Fill observed
capacity with useful independent work; two is only the minimum live acceptance test.
Workers return evidence and cannot operate root phase controls or publish task definitions.
Require actual loaded-runtime and native execution evidence for live claims.


## Efficient native startup and context

For every new native task, declare exact `read_inputs` from the run verification
inputs or accepted Build paths, a concise `purpose`, and `context_budget_bytes`
(default 128 KiB of unique required bodies). Include source dependencies and tests
needed for the conclusion; narrow inputs must not hide a relevant dependency.
Missing read inputs retain conservative legacy coverage. Inspect preparation's
`context_preflight` before launch. Declare source/log/test detail artifacts as
`source`, `raw-log`, `verification` or `supporting`; keep concise requirements and
reports normative. Use `required_for` when supporting bodies are mandatory.

Always supply `fork_turns: "none"` explicitly. Start the first useful scoped task,
then observe its successful claim, complete context and matching automatic pre/post
hook pair before preparing the rest of the cohort. Scoped preparation enforces
this automatically; `readiness_after` can name an additional same-phase startup
prerequisite. Release remaining ready work together while the first task works.
Do not use throwaway probes or relaunch unchanged failures. A repeated scoped
attempt needs `retry_reason` naming the observed defect or changed input.

Execute the exact returned context action. New scoped workers use `--drain`, which
returns at most 32 KiB including bodies and receipt. Return every response to the
consumer, then follow `next_action` only while `remaining_required` is nonzero.
Terminal responses have `done: true` and no action. Accumulate all subprocess/tool
chunks until exit before parsing; never parse a running handle's partial output.
Keep the combined response budget large enough and use bounded long waits (up to
60 seconds between user updates), not repeated short model-facing polls.

After a narrow repair, repeat affected checks and reviewers only. Unchanged
scoped results remain fresh within their original binding; across visits use
independently fingerprinted check evidence and a fresh scoped delta review.
Never transfer approval, worker identity or a context receipt to another binding.
Inspect attempt purposes, retry causes and delivered bytes in worker status and
the dashboard. Delivered bytes, native tokens and Codex allowance are different
measurements; no allowance saving can be inferred from byte counts alone.

Referenced files: 2

View saved version →

---
name: tp-help
description: Explain Taskplane capabilities, commands, and existing workflow state when the user asks for help. Does not initialize or activate a workflow.
---

# Taskplane help

Answer the user's question directly. Use only the relevant installed documentation
or a command's `--help` output. Do not run onboarding, inventory tools, activate a
contract, or render a setup dashboard just to explain the product.

Ordinary code review uses native tools and [engineering](../tp-engineering/SKILL.md).
The orchestrator prepares delivery; humans accept checkpoints by default.
Explicit user instructions can authorize run-bound automatic phase approvals. Hooks
separate mandatory workflow refusals from advisory usage. The default native_workflow
profile uses local state and observed human provenance. Host-wide protections are
unavailable; protected_host requires a verified owner. Native permissions remain separate. Use `flow report`
for human decisions, recorded milestones and available token usage.
For actual setup or a concrete installation failure, consult
[onboarding](../../docs/onboarding.md) and [CLI reference](../../docs/cli-reference.md).
Explain only the requested concept; load no full manuals or hook manifests as a tour.
For a question about phase policy, consult [the shared flow](../tp-go/references/shared-flow.md).

Explain that plugin installation, hook trust, phase acceptance and host tool permissions
are separate. Automatic mode requires explicit additional instructions; show a concise
example and how to return to manual mode when requested.

View saved version →

---
name: tp-northstar
description: Give an on-demand strategic review of a task, design or change against the project's direction.
---

# Strategic review

Before substantive work, resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-northstar --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Read the requested target and existing product direction. If the direction is not
available, state that limitation. Assess alignment, leverage, reversibility,
opportunity cost, and coherence. Identify the sharpest tension and recommend a
concrete next action. Keep the note proportionate to the decision.

This is advisory and does not authorize code changes. Without a matching active run, use a standalone Engineering visit. For an active delivery,
follow [the shared flow](../tp-go/references/shared-flow.md), inspect its dependencies
and task decomposition, and attach the note to the same run and dashboard.

The shared flow defaults to explicit human approval at each phase checkpoint.
A recorded, explicit run policy may authorize automatic approval as described there. Use
the dependency graph with source component decomposition, task DAG and shared
dashboard throughout. Unsupported host authority must be reported, never bypassed.

View saved version →

---
name: tp-product
description: Define the requested product outcome, scope, acceptance criteria, and material dependencies without changing implementation.
---

# Define what should be built

Before substantive work, resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-product --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Use the user's request and relevant existing product context. State the problem,
intended user behavior, scope, acceptance criteria, material dependencies, and
unresolved decisions. Reuse settled answers and keep the artifact proportionate
to the task. Write a document when requested or useful for downstream work.

Follow [the shared flow](../tp-go/references/shared-flow.md) even for Product-only
work. Start/reuse the relevant run at Product, inspect the dependency graph and
source decomposition, record a proportionate task decomposition, attach criteria,
and render the shared dashboard. If Engineering initiated the work, use its findings
and evidence to define the problem and acceptance criteria; preserve finding IDs
and prior decisions rather than restarting discovery.

Distinguish product readiness from delivered implementation. A completed spec
means the outcome is defined; it does not mean the product has been built or
validated. Surface only questions that materially affect the result.

Use native tools for inspection and document authoring. Product-only work does
not authorize implementation. For an already authorized delivery, return the
criteria and dashboard for Product checkpoint acceptance under the shared policy before
continuing through [delivery](../tp-go/SKILL.md). Reuse a valid prior acceptance.
A completed document or telemetry receipt cannot authorize advancement.

## Shared delivery state

Standalone and delivery Product use the same run, task decomposition, dependency
graph and dashboard defaults. Return evidence to that run; the root orchestrator
owns stage advancement and respects Product-only scope.

The shared flow defaults to explicit human approval at each phase checkpoint.
A recorded, explicit run policy may authorize automatic approval as described there. Use
the dependency graph with source component decomposition, task DAG and shared
dashboard throughout. Unsupported host authority must be reported, never bypassed.

## Consume bounded context

After activation, start, advancement or resumption, use the installed runtime's
`flow context --workspace <checkout> --run <run>` and consume the returned
handoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for
focused work. Read every omitted required input using `--read <ref-sha256>`;
follow index children and page cursors until all required bodies are returned.
A fresh consumer receives these bodies, scoped source and relevant findings;
do not copy the predecessor conversation or tool history into its instructions.
No context operation authorizes dispatch or a phase transition.

For phase submission, obtain a current whole-phase receipt (without `--task`)
and include the returned `context_receipt` object in the phase output. Renew it
after source, scope, revision or accepted input changes. New bounded/v1 runs
reject missing, partial, foreign or stale receipts. Legacy runs keep their
original evidence contract. A receipt proves returned data, not model attention.

Routine command summaries preserve the current gate and reference full details.
Expand specific references when needed; request `--full` only for a consumer that
requires the complete legacy report. Native dashboards retain complete evidence.
Reuse a prior passing check only when its verification record matches current
source/dependency, tests, runtime, environment, command and criteria fingerprints.
Retain failed/unknown results and findings; reuse never transfers approval.

## Scoped native workers

When authorized, use the installed native dispatch protocol: root prepares a run-bound
task grant, the observed worker claims its identity and consumes its own task context,
and root verifies the joined result before satisfying dependencies. Fill observed
capacity with useful independent work; two is only the minimum live acceptance test.
Workers return evidence and cannot operate root phase controls or publish task definitions.
Require actual loaded-runtime and native execution evidence for live claims.

View saved version →

---
name: tp-status
description: Show delivery progress, the responsible owner, actual outcomes, and available token usage without initializing a workflow.
---

# Delivery status

Use current task context first. For recorded delivery, invoke the installed
`taskplane/tp.py flow report --workspace <checkout>` once. Show the orchestrator
as owner, the latest meaningful milestone, actual verification, remaining work,
and useful token or waste observations. An advisory is not a blocking gate.
Missing usage means unknown, not zero. A recorded milestone is not proof that
acceptance criteria passed; check the cited evidence when making that claim.

Do not start a flow or mutate evidence to answer status. Distinguish work produced,
evidence validated, human or policy approval, stale state and legacy unverified observations.
Show workflow_available separately from authority_verified. Native workflow gates
can be active with host protections unavailable; capability_blocked applies to an
explicit protected_host request without a verified integration.

## Shared delivery state

For an active delivery, follow [the shared flow](../tp-go/references/shared-flow.md).
Use its existing run, task decomposition, dependency graph and dashboard. Return
evidence to that run; the root orchestrator owns stage advancement.

Show native discovery separately from protected storage, human origin, tool
containment and process revocation. A plugin version or observed hook is not
proof of those capabilities; an unavailable native owner stays unverified.

Select the current task’s run explicitly when available. Report approval mode, policy
version and pause reason, current visit versus run tokens, unknown/unallocated usage,
snapshot timestamp and graph freshness. Never equate old tab contents with current state.

## Consume bounded context

After activation, start, advancement or resumption, use the installed runtime's
`flow context --workspace <checkout> --run <run>` and consume the returned
handoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for
focused work. Read every omitted required input using `--read <ref-sha256>`;
follow index children and page cursors until all required bodies are returned.
A fresh consumer receives these bodies, scoped source and relevant findings;
do not copy the predecessor conversation or tool history into its instructions.
No context operation authorizes dispatch or a phase transition.

For phase submission, obtain a current whole-phase receipt (without `--task`)
and include the returned `context_receipt` object in the phase output. Renew it
after source, scope, revision or accepted input changes. New bounded/v1 runs
reject missing, partial, foreign or stale receipts. Legacy runs keep their
original evidence contract. A receipt proves returned data, not model attention.

Routine command summaries preserve the current gate and reference full details.
Expand specific references when needed; request `--full` only for a consumer that
requires the complete legacy report. Native dashboards retain complete evidence.
Reuse a prior passing check only when its verification record matches current
source/dependency, tests, runtime, environment, command and criteria fingerprints.
Retain failed/unknown results and findings; reuse never transfers approval.

## Scoped native workers

When authorized, use the installed native dispatch protocol: root prepares a run-bound
task grant, the observed worker claims its identity and consumes its own task context,
and root verifies the joined result before satisfying dependencies. Fill observed
capacity with useful independent work; two is only the minimum live acceptance test.
Workers return evidence and cannot operate root phase controls or publish task definitions.
Require actual loaded-runtime and native execution evidence for live claims.

View saved version →

---
name: tp-tag
description: Use the shared Taskplane delivery flow in a Claude channel task.
---

# Delivery in a channel task

Before substantive work, resolve this installed plugin's runtime and run
`flow activate --workspace <checkout> --phase tp-tag --request-reference <actual-user-request>`.
Inspect `flow report`: reuse the matching active visit or initialize the appropriate
scoped run before continuing. This requirement includes standalone work and resumed
stages; loading a skill alone grants no phase approval. See the shared flow for
bootstrap, native dashboard handoff and legitimate user waits.

Follow [delivery](../tp-go/SKILL.md) and [the shared flow](../tp-go/references/shared-flow.md).
Keep the requested scope and native permissions. Each phase requires checkpoint acceptance; human approval is the default and
explicit run-bound policies may authorize automatic decisions. The orchestrator
advances only after that valid decision.
Claude and Codex share native_workflow gates and explicit host limits. Requests for
protected_host refuse without a verified native owner; there is no silent downgrade.
Use the same task decomposition, dependency graph, evidence and dashboard.
Where native counters are unavailable, report unknown usage and continue.
Share messages or artifacts with other people only when explicitly authorized.