feat: adopt T3 0.1.3-nightly.20261026.3717 changes in the shared skills

skills/implement-spec/SKILL.md

@@ -44,7 +44,10 @@ If the PRD alters anything a user sees, capture its **before** now, from this wo
 Spawn one Agent per frontier ticket, all in one message: `subagent_type: "implementer"`,
 `isolation: "worktree"`, `run_in_background: true`. These worktrees are the one exception to
 "never create a worktree of your own" in the `implement` skill's
-[THREADS.md](../implement/THREADS.md): the PR stays on this thread's worktree. The prompt is pointers only:
+[THREADS.md](../implement/THREADS.md): the PR stays on this thread's worktree. They are also
+this skill's exception to T3's injected rules that a Claude `Agent` runs in the foreground and
+that background work or a child's checkout goes through `delegate_task`: follow this step as
+written. The prompt is pointers only:
 
 ```
 Ticket #<n>, part of PRD #<PRD>. Integration branch: <branch>.
@@ -71,7 +74,8 @@ For each report with `status: done`:
 2. Comment `Implemented in <sha>. Part of #<PRD>.` on the sub-issue, which stays open
    (`docs/agents/issue-tracker.md` § PRD workflow).
 3. Push. After the first merge, open the PR as a **draft** with the PRD PR body of the `pr` skill
-   (§ PRD PRs there) and link it to the thread; after that, tick the sub-issue's box in its body.
+   (§ PRD PRs there), linked to the thread as the `implement` skill's
+   [THREADS.md](../implement/THREADS.md) says; after that, tick the sub-issue's box in its body.
    The chain pays one review at the end instead of one per slice.
 4. Remove the implementer's worktree and branch (`git worktree remove <path>`,
    `git branch -d <branch>`).

skills/implement/PREVIEW.md

@@ -5,6 +5,10 @@ tools, rather than a browser CLI the project installs. A project's `docs/agents/
 § Launch says what to start and § Feature map which flows to drive; this file says how to drive
 them. Outside T3 (no preview tools), § Drive's fallback applies.
 
+Driving the change is browser work the request asks for: `implement` step 4 and the project's
+`verification.md` require it, so T3's injected rule against using the preview tools on your own
+edit unasked does not apply to this loop.
+
 The preview tools are on trial (`preview-tools-verification` in the shared
 `t3-dependencies.md`). Note every place they fall short in the final report, so the trial has
 its numbers.
@@ -26,8 +30,7 @@ and open the final report with the refusal's exact text.
 3. **Capture the before**, before the first edit: `preview_snapshot` with `save: true`, its
    `screenshotPath` the evidence file, or the browser CLI when `docs/agents/verification.md`
    § Evidence names it. The preview saves every capture at most 1280 px wide, scaling a wider
-   viewport down, and at any viewport wider than 640 px draws a blurred backdrop (behind a
-   dialog or sheet) as mirrored tiles of the page: a capture artifact, not an app bug.
+   viewport down.
 4. **Drive** the flow with `preview_click`, `preview_type`, `preview_select`, `preview_press` and
    `preview_navigate`, targeting elements by the `aria-ref` refs of the latest `preview_snapshot`.
    Refresh the snapshot after a navigation. Before every capture or assertion, `preview_wait_for`

skills/implement/SKILL.md

@@ -152,8 +152,8 @@ in the thread: the PR carries none.
 
 When the run started from an issue or the user asked for a PR: push the branch, open it ready for
 review (never a draft; a PRD run under `implement-spec` keeps its PR a draft until the last slice
-lands) with a body written by calling the Skill tool with "pr", carrying `Closes #N`, and link it
-to the thread. An issue is the unit of work here, so a run that starts from one ends in the PR
+lands) with a body written by calling the Skill tool with "pr", carrying `Closes #N`, linked to
+the thread as [THREADS.md](THREADS.md) says. An issue is the unit of work here, so a run that starts from one ends in the PR
 that closes it unless the user says otherwise.
 Done when `gh pr view` shows it open and it is linked.
 

skills/implement/THREADS.md

@@ -18,10 +18,11 @@ directory: T3's Automatically pull keeps it current only while it is clean and o
   thread starts, so read it with `git branch --show-current`, never from the worktree's folder
   name. A session that renames it or creates one uses `feat/`, `fix/`, `docs/`, `chore/`,
   `refactor/`, `research/` or `prototype/`.
-- **One thread, one branch, one PR.** After `gh pr create`, register the PR with the thread
-  through the `link_pull_request` tool, so T3 shows its status and settles the thread when it
-  merges. To keep working on an existing PR, start the thread on that branch (or link the PR)
-  instead of checking it out in another worktree.
+- **One thread, one branch, one PR.** T3 links a PR that `gh pr create` opens to the thread that
+  ran it, shows its status and settles the thread when it merges. A PR opened another way (`gh
+  api`, a loop creating several) is linked with the `link_pull_request` tool, as is one missing
+  from `t3_thread_read`'s `pullRequests`. To keep working on an existing PR, start the thread on
+  that branch (or link the PR) instead of checking it out in another worktree.
 - **A launched thread reports to its own inbox.** A thread started with `t3_thread_launch`
   babysits its own PR, merges it when the merge is the agent's (the `babysit-pr` skill) and
   otherwise hands back to the user; its `unwatch_pull_request` wakes nobody else, so the launcher

skills/t3-update-review/SKILL.md

@@ -55,7 +55,7 @@ The review writes down what it learns and proposes what to change. What it learn
    python3 -I <this-skill-dir>/scripts/changes.py <serverVersion> --mark
    ```
 
-10. **Bookkeeping PR**, when the report changes anything in the shared `t3-dependencies.md`. In a thread on the shared-workflow repo, on a `docs/t3-<serverVersion>` branch from the default branch, write the evidence, status moves and new entries the report gives for the shared file, run the lint (`python3 -I tests/lint_skills.py`), and open a PR whose body is the report. Link it to the thread with `link_pull_request`. Proposed edits to skills and projects stay in the body as proposals, never in the diff. The user's merge accepts the bookkeeping; their edits to it are final.
+10. **Bookkeeping PR**, when the report changes anything in the shared `t3-dependencies.md`. In a thread on the shared-workflow repo, on a `docs/t3-<serverVersion>` branch from the default branch, write the evidence, status moves and new entries the report gives for the shared file, run the lint (`python3 -I tests/lint_skills.py`), and open a PR whose body is the report. Check it is linked to the thread, as the `implement` skill says. Proposed edits to skills and projects stay in the body as proposals, never in the diff. The user's merge accepts the bookkeeping; their edits to it are final.
 
 ## Cadence
 

t3-dependencies.md

@@ -208,8 +208,9 @@ T3 source paths below are in pingdotgg/t3code.
   0.1.3-nightly.20261025.3669 T3's injected instructions steer away from it
   (pingdotgg/t3code#24850, `orchestrationInstructions.ts`): "Claude `Agent` always with
   `run_in_background:false`", and "Use `delegate_task` for ... a separate checkout
-  (`isolation:"worktree"`), background work". Both users below contradict that text, so an agent
-  reads two opposite rules until they change or the skill names itself the exception.
+  (`isolation:"worktree"`), background work". Since 2026-10-26 `implement-spec` § 2 names its
+  background implementers as the exception to that text, until `implementer-worktrees` moves
+  them to `delegate_task`; the parallel subagents in `PREVIEW.md` step 1 are those implementers.
 - **Used by:** `skills/implement/PREVIEW.md` § The loop step 1 (parallel subagents each open their
   own tab); `skills/implement-spec/SKILL.md` § 2 (the orchestrator ends its turn while its
   background implementers run)
@@ -357,25 +358,6 @@ T3 source paths below are in pingdotgg/t3code.
   remove; then each project moves its teardown there and the resources row moves to T3.
 - **Watch:** `packages/contracts/src/t3ProjectFile.ts`; no upstream issue found yet
 
-### implementer-worktrees
-
-- **Workaround:** `implement-spec` runs each implementer as an Agent-tool worktree under
-  `.claude/worktrees/`, sets it up by hand (`agents/implementer.md` step 2), and removes it itself
-  (`skills/implement-spec/SKILL.md` § 3 step 4, and § 4 step 6).
-- **Used by:** `agents/implementer.md`; `skills/implement-spec/SKILL.md`;
-  `skills/implement/THREADS.md` (the exception)
-- **Would improve if:** a `delegate_task` child with `isolation: worktree` (a checkout of the
-  parent's local commit, with project setup done before the child starts) can commit to its own
-  named branch that the orchestrator merges. Its result has no branch field today
-  (`OrchestratorMcpDelegateTaskResult` in `packages/contracts/src/orchestratorMcp.ts`). Not tried
-  yet: needs a trial. Since pingdotgg/t3code#20213 such a call is refused when the project's repo
-  lacks the parent checkout's commit. Since 0.1.3-nightly.20261025.3669 T3 points agents at it:
-  the `delegate_task` description says "Separate checkout or PR per child:
-  `isolation:'worktree'`", and the injected instructions say "Never make a child's checkout in the
-  shell or in `task`" (pingdotgg/t3code#24850), which this workaround does in
-  `agents/implementer.md` step 2. The trial is now the way to end that conflict.
-- **Watch:** `apps/server/src/mcp/toolkits/orchestrator/tools.ts` (`delegate_task`)
-
 ### pr-watch-unreported-checks
 
 - **Workaround:** `babysit-pr` reads the round on every wake and treats a required check not
@@ -446,19 +428,52 @@ T3 source paths below are in pingdotgg/t3code.
   captures at full scale and shrinks the finished PNG in the page, since Chromium "mirrors the
   top-left of the page into a `backdrop-filter` in any capture it shrinks"
   (`shrinkPng` in `ServerBrowserPage.ts`). The 1280 px cap stands (`MAX_SCREENSHOT_WIDTH`), so
-  the user's call on 1280 px images and en-escena's dialog probe remain. The same build's injected
+  en-escena's dialog probe remains: the user accepted images 1280 px wide on 2026-10-26. The same build's injected
   instructions add a hurdle (pingdotgg/t3code#24850): "Never use `preview_*` to verify or show
   your own edit, even a frontend edit ... Use them only when the current request asks for browser
   work", and the browser section dropped its exception for "a skill or documented repository
-  workflow that names one". `PREVIEW.md` must say why its use is asked for, or a T3 agent may
-  skip step 4's drive.
+  workflow that names one". Since 2026-10-26 `PREVIEW.md` says why its use is asked for: step 4
+  and the project's `verification.md` require the drive.
 - **Watch:** pingdotgg/t3code#20899 (the blur, fixed; no issue asks to lift the size cap, and #10141,
   which tried, closed unmerged); `apps/server/src/preview/ServerBrowserPage.ts`
   (`MAX_SCREENSHOT_WIDTH`, `captureViewport`); `apps/server/src/mcp/toolkits/preview/tools.ts`;
   the trial's notes in the final reports of en-escena's and rubens' PRs
 
 ## Ready
 
+### implementer-worktrees
+
+- **Workaround:** `implement-spec` runs each implementer as an Agent-tool worktree under
+  `.claude/worktrees/`, sets it up by hand (`agents/implementer.md` step 2), and removes it itself
+  (`skills/implement-spec/SKILL.md` § 3 step 4, and § 4 step 6).
+- **Used by:** `agents/implementer.md`; `skills/implement-spec/SKILL.md`;
+  `skills/implement/THREADS.md` (the exception)
+- **Would improve if:** a `delegate_task` child with `isolation: worktree` (a checkout of the
+  parent's local commit, with project setup done before the child starts) can commit to its own
+  named branch that the orchestrator merges. Its result has no branch field today
+  (`OrchestratorMcpDelegateTaskResult` in `packages/contracts/src/orchestratorMcp.ts`). Not tried
+  yet: needs a trial. Since pingdotgg/t3code#20213 such a call is refused when the project's repo
+  lacks the parent checkout's commit. Since 0.1.3-nightly.20261025.3669 T3 points agents at it:
+  the `delegate_task` description says "Separate checkout or PR per child:
+  `isolation:'worktree'`", and the injected instructions say "Never make a child's checkout in the
+  shell or in `task`" (pingdotgg/t3code#24850), which this workaround does in
+  `agents/implementer.md` step 2. Tried 2026-10-26 (a Sonnet child, `role: test`): the child got
+  a checkout in T3's managed folder at the parent's local commit, made and committed to a branch
+  of its own name, and that branch was a fast-forward of the parent's from the parent's worktree;
+  the result still carries no branch field, so the report names it, as an implementer's does now.
+  One catch: T3 had renamed the child's branch (`t3/<id>` to `t3/<slug>`), and a child that
+  switches away from it is one storage cleanup keeps (`storage-cleanup-renamed-branches`), so the
+  child commits on the branch T3 gave it.
+- **Met in:** 0.1.3-nightly.20261026.3717, by the trial above.
+- **Adopting:** `implement-spec` § 2 spawns each implementer with `delegate_task`
+  (`isolation: worktree`, `mode: async`, the implementer brief as `task`), the implementer
+  commits on its own branch and reports it, `agents/implementer.md` step 2 (setup by hand) and
+  § 3 step 4's removal go, and `THREADS.md` drops its exception. Then the conflict in
+  `background-subagents-keep-t3-tools` ends too.
+- **Watch:** `apps/server/src/mcp/toolkits/orchestrator/tools.ts` (`delegate_task`)
+
+## Resolved
+
 ### pr-auto-link
 
 - **Workaround:** the session calls `link_pull_request` right after `gh pr create`.
@@ -473,11 +488,10 @@ T3 source paths below are in pingdotgg/t3code.
   Tried 2026-10-26 on this review's own PR (#28): `gh pr create`, run as the last of several
   shell commands, was linked with source `created` before any call, and `link_pull_request`
   afterwards returned `alreadyLinked: true`.
-- **Adopting:** the three places stop calling `link_pull_request` after `gh pr create`, and keep
-  it for a PR opened another way (`gh api`, a loop) or missing from `t3_thread_read`'s
-  `pullRequests`. A repeat call is harmless (`alreadyLinked`), so the risk is one unlinked PR.
-
-## Resolved
+- **Adopted:** 2026-10-26; `THREADS.md` ("One thread, one branch, one PR") says T3 links a PR
+  `gh pr create` opens, and keeps `link_pull_request` for a PR opened another way or missing from
+  `t3_thread_read`'s `pullRequests`; `implement` § 7, `implement-spec` § 3 step 3 and
+  `t3-update-review` step 10 point at it.
 
 ### storage-cleanup-archived-threads