Update to 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.",
  "included_files": [],
  "name": "taskplane",
  "skill_md_contents": "---\nname: taskplane\ndescription: 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.\n---\n\n# Taskplane\n\nBefore creating state, apply the [workspace and execution contract](../tp-go/references/shared-flow.md#workspace-and-execution-contract).\nCowork requires an explicit selected-project binding; honor the user's storage,\ncommand and worker location restrictions separately. Missing mapping or required\nlocality evidence is a blocker, not permission to use a session directory.\nThen resolve this installed plugin's runtime and run\n`flow activate --workspace <checkout> --phase taskplane --request-reference <actual-user-request>`.\nInspect `flow report`: reuse the matching active visit or initialize the appropriate\nscoped run before continuing. This requirement includes standalone work and resumed\nstages; loading a skill alone grants no phase approval. See the shared flow for\nbootstrap, native dashboard handoff and legitimate user waits.\n\nRoute the requested work directly. Product, Design, and Engineering always use the\nshared dependency graph, task decomposition, and dashboard, including standalone\nrequests. Read [the shared flow](../tp-go/references/shared-flow.md) for these defaults.\nHelp and status inspect existing state without starting a run. The default native_workflow\nprofile enforces Taskplane gates using observed human responses and local state. Host-wide\nprotection is unavailable; explicitly requested protected_host execution still refuses\nwithout a verified owner. Never substitute one profile for the other.\n\n- Source review, architecture/security review, or validation: read\n  [engineering](../tp-engineering/SKILL.md) and use native tools in the available checkout.\n- Status: read [status](../tp-status/SKILL.md). Inspect existing state without initializing it.\n- Help: read [help](../tp-help/SKILL.md). Answer the question without setup.\n- Product requirements: read [product](../tp-product/SKILL.md).\n- Design before implementation: read [design](../tp-design/SKILL.md).\n- Build or fix an approved delivery plan: read [delivery](../tp-go/SKILL.md).\n  For a new feature or explicit A/B prototype, use [build](../tp-build/SKILL.md).\n- Explicit installation, setup, or configuration diagnostics: read\n  [CLI reference](../../docs/cli-reference.md).\n\nProduct, Design, Plan, Build, Evaluate, Engineering and Retro each require acceptance\nof their concrete output before advancement: human approval by default, or a valid\nexplicitly authorized policy decision under the shared flow. Engineering can be the entry point: its findings can define subsequent\nProduct scope, Design, and implementation when authorized. Keep native execution,\npermissions, waiting, and session identity with the\nhost. Load only the selected workflow's references; don't recite internal setup or\nintroduce approval steps that the user has already satisfied.\n\nNative discovery is observational. Use the installed named hook entry points and\nreport their actual capability status; restoring native routines does not admit\na host owner or change any human checkpoint.\n\n## Scoped native workers\n\nNative dispatch is the default for useful independent work under this skill.\nEvery new run scope must declare `execution_contract: \"native-default/v1\"`; this\nis mandatory in this entry flow. Publish typed `execution: \"native_required\"`\ntasks for ready independent work and one worker per selected Engineering lens,\nwith a unique `review_lens` on each lens task. This instruction authorizes that\nbounded delegation; do not ask again solely because the user did not name agents.\n\nExplicit user serial/no-delegation constraints take priority. Dependencies,\nread/write conflicts and trivial scope can justify `execution: \"root\"` with a\nsubstantive `execution_reason` and `execution_reference`. Root lens coverage is\n`serial_scope`, never native independence. Observe host capacity, launch ready\nindependent tasks together and refill slots as prerequisites complete. Limited\ncapacity queues distinct workers; reusing one identity for several lenses does\nnot satisfy independence. An unavailable adapter needs an observed reason/reference;\nrequired native tasks remain incomplete and block sealing.\n\nUse the installed prepare/claim/context/join/result protocol. Execute the exact\nreturned `next_action` with the installed runtime launcher; it retains workspace,\nrun and task. Follow `--read-required` actions until `remaining_required` is zero.\nWorkers return scoped evidence. Only the root verifies and accepts joined fresh\nresults and advances phases under the existing approval policy. `native_verified`\nlens coverage binds `task_id`, `grant` and the actual worker `reviewer`; labels alone\ncannot satisfy frozen requirements. Historical untyped evidence stays unverified.\n\n\n## Efficient native startup and context\n\nFor every new native task, declare exact `read_inputs` from the run verification\ninputs or accepted Build paths, a concise `purpose`, and `context_budget_bytes`\n(default 128 KiB of unique required bodies). Include source dependencies and tests\nneeded for the conclusion; narrow inputs must not hide a relevant dependency.\nMissing read inputs retain conservative legacy coverage. Inspect preparation's\n`context_preflight` before launch. Declare source/log/test detail artifacts as\n`source`, `raw-log`, `verification` or `supporting`; keep concise requirements and\nreports normative. Use `required_for` when supporting bodies are mandatory.\n\nAlways supply `fork_turns: \"none\"` explicitly. Start the first useful scoped task,\nthen observe its successful claim, complete context and matching automatic pre/post\nhook pair before preparing the rest of the cohort. Scoped preparation enforces\nthis automatically; `readiness_after` can name an additional same-phase startup\nprerequisite. Release remaining ready work together while the first task works.\nDo not use throwaway probes or relaunch unchanged failures. A repeated scoped\nattempt needs `retry_reason` naming the observed defect or changed input.\n\nExecute the exact returned context action. New scoped workers use `--drain`, which\nreturns at most 32 KiB including bodies and receipt. Return every response to the\nconsumer, then follow `next_action` only while `remaining_required` is nonzero.\nTerminal responses have `done: true` and no action. Accumulate all subprocess/tool\nchunks until exit before parsing; never parse a running handle's partial output.\nKeep the combined response budget large enough and use bounded long waits (up to\n60 seconds between user updates), not repeated short model-facing polls.\n\nAfter a narrow repair, repeat affected checks and reviewers only. Unchanged\nscoped results remain fresh within their original binding; across visits use\nindependently fingerprinted check evidence and a fresh scoped delta review.\nNever transfer approval, worker identity or a context receipt to another binding.\nInspect attempt purposes, retry causes and delivered bytes in worker status and\nthe dashboard. Delivered bytes, native tokens and Codex allowance are different\nmeasurements; no allowance saving can be inferred from byte counts alone.\n"
}