Update to taskplane

{
  "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.",
  "included_files": [],
  "skill_md_contents": "---\nname: tp-engineering\ndescription: 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.\n---\n\n# Engineering review\n\nBefore creating state, apply the [workspace and execution contract](../tp-go/references/shared-flow.md#workspace-and-execution-contract),\nincluding for read-only reviews. Bind Cowork's selected project and validate command\nand worker locality independently against the user's policy; report missing\ncapability without substituting serial work for required native reviews.\nThen resolve this installed plugin's runtime and run\n`flow activate --workspace <checkout> --phase tp-engineering --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\nUse the current conversation and native tools to inspect the requested repository.\nPreserve the user's scope and existing decisions. Follow\n[the shared flow](../tp-go/references/shared-flow.md) for every review, standalone or\nwithin delivery: reuse a relevant run or start at Engineering, inspect dependency\nimpact and source decomposition, attach the review task decomposition and evidence,\nand 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.\n\n1. Select the readable checkout and the requested revision or comparison. A whole\n   repository request includes its tracked source and needs no artificial diff.\n   Reuse an available checkout; acquire or transfer source only when it is unavailable.\n2. Inspect relevant source with native file, search, and command tools. Follow the\n   host's permissions and agent lifecycle. Select useful independent lenses and apply the native dispatch default below,\n   respecting explicit serial constraints and observed capacity.\n3. Report concrete findings with severity, triggering conditions, file locations,\n   and consequences. Distinguish confirmed defects from questions and missing evidence.\n   Reuse applicable CI results. Run additional checks only for a specific evidence gap\n   or changed behavior, respecting a static-review request.\n4. Present the findings and shared dashboard, including an honest coverage summary\n   and remaining uncertainty. Update the task and review evidence before rendering;\n   acceptance under the shared approval policy is required before advancement. A\n   dashboard edit cannot grant it. Apply fixes only through an approved Build scope.\n5. When findings lead to Product work, retain their IDs, severity, source locations\n   and evidence as Product inputs. Continue the same active run through Product,\n   Design and the remaining authorized phases. Engineering is a valid starting\n   point, not only a final review stage.\n\nIf a pinned inventory is useful, resolve the installed plugin's `taskplane/tp.py`\nfrom its supplied root or this skill's location and invoke it with Python:\n\n- `review start --scope repository --workspace <checkout>` for tracked source.\n- `review start --base <ref> --workspace <checkout>` for a comparison.\n\nThe response references the selected source artifact; read it through native tools.\nThe inventory captures source only. Reviewers use native tools and the host's permissions.\nAttach 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\nroot orchestrator prepares and carries out that approved transition.\n\n## Shared delivery state\n\nThese defaults apply equally to standalone Engineering and delivery. Use one run,\ntask decomposition, dependency graph and dashboard for the requested scope. The\nroot orchestrator owns stage advancement; a review-only request still ends at review.\n\nThe shared flow defaults to explicit human approval at each phase checkpoint.\nA recorded, explicit run policy may authorize automatic approval as described there. Use\nthe dependency graph with source component decomposition, task DAG and shared\ndashboard throughout. Unsupported host authority must be reported, never bypassed.\n\n## Consume bounded context\n\nAfter activation, start, advancement or resumption, use the installed runtime's\n`flow context --workspace <checkout> --run <run>` and consume the returned\nhandoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for\nfocused work. Read every omitted required input using `--read <ref-sha256>`;\nfollow index children and page cursors until all required bodies are returned.\nA fresh consumer receives these bodies, scoped source and relevant findings;\ndo not copy the predecessor conversation or tool history into its instructions.\nNo context operation authorizes dispatch or a phase transition.\n\nFor phase submission, obtain a current whole-phase receipt (without `--task`)\nand include the returned `context_receipt` object in the phase output. Renew it\nafter source, scope, revision or accepted input changes. New bounded/v1 runs\nreject missing, partial, foreign or stale receipts. Legacy runs keep their\noriginal evidence contract. A receipt proves returned data, not model attention.\n\nRoutine command summaries preserve the current gate and reference full details.\nExpand specific references when needed; request `--full` only for a consumer that\nrequires the complete legacy report. Native dashboards retain complete evidence.\nReuse a prior passing check only when its verification record matches current\nsource/dependency, tests, runtime, environment, command and criteria fingerprints.\nRetain failed/unknown results and findings; reuse never transfers approval.\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"
}