---
name: pinboard
description: Use before answering status, planning or ideation about saved Pinboard work, including quick read-only status, or any product, roadmap or architecture discussion in a Pinboard-managed project. Coach discussion points and preserve decisions even when no implementation is requested. Also coordinate next-work selection, parallel work, worker dispatch and continuation, lifecycle, review, recovery and long-running continuity. Do not implement an assigned worker attempt; use $pinboard-deliver.
---

# Coordinate with the pinboard

Coordinate shared work through one project-local ledger while keeping execution isolated by attempt. Any task may apply an atomic project transition. Preparation and attempt leases fence the longer operations that genuinely need retained authority.

Use [the shared runtime adapters](references/runtime-adapters.md) with your own runtime's reference, [Codex](references/runtime-codex.md), [Claude Code](references/runtime-claude-code.md) or [Antigravity](references/runtime-antigravity.md), for identity, checkout isolation, subagents and reviewers, permission declarations, waiting, and optional messaging. This skill owns the shared decisions in every integration.

## Route common requests

Load this complete main skill before answering about saved work, including a quick read-only status. A native skill loader or native `read_file` suffices when it delivers this complete body through the final section: in Antigravity, whose skill catalog carries only each skill's path and description, read its actual resolved `SKILL.md` completely with native `read_file` first (calling `read_file` again with `ByteOffset=46080` when a file exceeds 46,080 bytes so the full file is loaded through the final section), and fall back to `pinboard_startup_text` with operation `file-start`, that absolute `path`, exact `project_root` and `work_root`, and `max_batch_bytes: "host-profile"` only if native `read_file` is unavailable or refused. When using `pinboard_startup_text`, follow each returned continuation verbatim under `request` until null, one page per outer response without aggregation. EOF establishes delivery only. Then load the reference for the current request before its phase mechanics; load no unrelated phase. Call every Pinboard operation through its connected MCP tool, selected by its full advertised name and then called directly. Never reach Pinboard state through Bash, Python, or `.pinboard/state.sqlite3`; the launcher serves only the CLI-only operations named by the selected phase.

Loaded Pinboard skills own adoption and personal workflow policy. Keep project use in private local state; do not add or recommend Pinboard routes, notices, or policy in a managed project's committed `AGENTS.md`, documentation, or configuration merely to adopt Pinboard. Setup and guidance assessment follow this owner without retrofitting existing projects. Preserve genuine project-specific guidance and explicit human requests for contributor documentation; limit those edits to their named content.

Classify the current request before entering delivery. When the human asks only for an answer, explanation, review assessment, diagnosis, named context, orientation, or a wait, inspect and report without implementation repository writes: ordinary status reads remain available, but do not change lifecycle state, acquire authority, plan brief sources, dispatch work, or launch review. An explicit human request to review a human-owned PR follows the separate [human-owned PR review route](references/review-and-disposition.md), which may record review evidence and commission its brief reviewer but authorizes no implementation edits. After a human implementation change request, choose an existing or new Pinboard item or direct implementation outside Pinboard, and announce that route before the first implementation repository write; the announcement is not edit authority, and already authorized direct work needs no repeat approval. When the agreed work spans several steps or will outlive the current turn, save it on the board before that first write so it cannot be lost with the conversation: use the existing item or campaign that already carries it, or save it as a new item through `$pinboard-intake`'s immediate-start route, which the implementation request itself authorizes. Direct implementation outside Pinboard remains for a change the current turn can finish, or when the human explicitly declines saving. A campaign may later group that item with unrelated saved work; it never holds agreed work that exists only in the conversation.

A missing required tool stops that operation; it never invites shell commands or temporary payload files. Only the advertised [verified record file inputs](references/runtime-adapters.md#verified-record-file-inputs) permit a caller-selected brief or review file for oversized records; they require the connected tool and preserve every other authority and recovery rule. Apply the shared [public-contract and source-scope boundary](references/runtime-adapters.md#public-contracts-and-source-scope) to missing values as well as tools: installed Pinboard internals cannot supply an undocumented protocol answer for another project; explicitly assigned Pinboard development and authorized investigation remain available. A Claude, Codex, Antigravity, or other client reachable through computer control is not part of the current session's tool surface and cannot act for it: ask the human to restore the current client's connection or explicitly authorize diagnosis, and use another client only as the subject of an accepted compatibility run against its named target. Workers and reviewers launched through an exact returned `native_launch` recipe remain valid participants but cannot replace a coordinator capability missing from this session. Static CLI contract discovery, full validation, initialization, project export, and view repair remain CLI-only. Never infer an unadvertised tool from a neighboring name.

Before the first implementation write, read the actual human invocation and identify its requested effect, selected route, checkout, and exact destinations for source changes, private evidence, and any external effect. Skill access, intake, status, and later registration supply context rather than implementation authority. Follow the chosen route through its owning caller before editing; when a proposed change propagates across owners, trace the concrete producer and consumer only as far as needed to expose a genuine product or scope choice. Reuse settled authority and decide routine reversible details yourself. For test access and substitution, apply [the test-seam distinction](../slop-cleanup/references/structural-consolidation.md#choose-explicit-test-seams); surface material evasions or actual instruction conflicts without turning ordinary permitted dependency choices into approval requests.

If implementation already began before that classification, recover the actual prior effects and changed surfaces from available invocation and repository evidence. State what was observed and what remains unknown; a later item or brief does not retroactively authorize the earlier effects or make a narrower recorded file list truthful. Continue only the effects the current request authorizes.

## Human-confirmed cancellation

Cancellation releases a live commitment as **dropped**, preserving its work and history. Only the human's explicit cancellation request starts this route. Never initiate cancellation or infer it from cleanup, completion, vague wording, silence or an obsolete-looking item. Use the [cancellation procedure](references/setup-and-transitions.md#cancel-after-separate-exact-item-confirmation), show the exact item and consequences, then stop for a separate explicit confirmation. Ordinary close and reviewed successful completion keep their independent requirements.

Before ending a planned-replaced item, follow [replacement coverage before ending work](references/setup-and-transitions.md#read-replacement-coverage). Bring every uncovered obligation to the human as an explicit decision. Coverage adds no permission to close or cancel and no veto when the human explicitly chooses an otherwise-legal ending despite the uncovered work.

## Phase index

Use only the phase needed now. A reference supplies concrete mechanics; this core remains the conversation owner.

| Request | Load before that phase |
| --- | --- |
| Status, saved-item planning, what next, detail or history | [Status and selection](references/status-and-selection.md) |
| Save work | `$pinboard-intake`; [setup and transitions](references/setup-and-transitions.md) when setup, mutation or nested continuation is needed |
| Start, fix or resume saved work | [Preparation and dispatch](references/preparation-and-dispatch.md); `$pinboard-deliver` implements the accepted attempt |
| Review, merge, correction, landing, cleanup or completion | [Review and repository disposition](references/review-and-disposition.md) |
| Combine saved items or shape a campaign | [Consolidation](references/consolidation.md) |
| Preview or launch independent work | [Parallel work](references/parallel-work.md) |
| Exact capture or consequential invocation anomaly | [Invocation evidence](references/invocation-evidence.md) |
| Lease revocation, invalid state, interrupted transition or work inherited from an unavailable session | [State and recovery](references/state-and-recovery.md) |

Plain merge requests remain repository actions on the existing change, not new intake. The selected review phase preserves its review and authority requirements. Paused work stays pending on its recorded decision until the human answers with a recommendation beside the question.

## Keep the human's picture current

The human decides what reaches the product and often returns after hours with only your replies to go on. Keep four facts true in them: the **agreed outcome and where its results are meant to land**; **what is happening now** and who acts next, including which task to follow when another task was created or responsibility would otherwise be unclear; **where results live and whether they reach users**, meaning the integration target such as `main`; and **what remains open** for the human. This section owns what the human is told; intake, delivery, parallel-work, and runtime guidance report through it. Spend the human's attention on decisions and material state, not volume.

**Verify consequential assumptions before costly work.** Before selecting a setup that would commit substantial time or money, establish what the human expects to be able to do with its result. A proposed method, intermediate artifact, or convenient extra does not settle that outcome. When another plausible reading would produce a materially different result, expose that difference and its consequence before asking how to implement a selected interpretation. Cheap inspection may establish facts while the outcome remains open. Verify observable assumptions yourself with the cheapest decisive evidence, and check that the selected setup can produce the accepted outcome before costly execution.

For a human-owned choice, reuse settled decisions and authority. Ask one concrete question with your recommended default only when the consequential choice remains unresolved; keep dependent costly work pending until it is settled. This includes where work lands, an irreversible or externally visible effect such as a merge, push, publication, or deletion, or a change to agreed scope. Decide routine and reversible choices yourself and continue without a general assumptions inventory or approval step. Permission to experiment is neither a commitment to merge nor a decision to discard useful results; an experiment may end in isolation when that is the agreed outcome.

**Start and change.** Before any implementation or exploration begins, including a throwaway experiment, say in one sentence what will be produced and where it will land, for example “This stays on branch `x`; nothing reaches `main` unless you choose.” For broad work—repository-wide, or spanning several principal product, documentation, agent, tooling, packaging, or CI surfaces—the sentence also names the main surfaces to read and touch, the approximate magnitude, and any surprising exclusion. Give it before a preparation claim, implementation reads, a brief, or a worker launch; in a one-shot client, put it before the next tool call and keep working. It confirms the interpretation and asks no permission. Ask one concrete question only when it exposes an unresolved choice that would materially change product behavior, architecture, scope, compatibility, or verification; the later brief preserves the agreed magnitude. While planning, also apply the [opportunity checkpoint](#resolve-material-architecture-limitations-before-preparation). When one of the four facts later changes—an item closes while its changes stay off `main`, a branch is merged, scope widens, a worker finishes—say so in one line in your next reply.

**Read before you report.** Board states do not say who acts next or where changes live. Before saying what waits on the human, what a review found, whether a worker is running, or whether changes reached users, load [status and selection](references/status-and-selection.md) and perform its exact reads. Overview omits review verdicts and reports preparation separately from worker authority; neither omission nor a preparation status supports a review or worker claim. A rejected or malformed read supplies no observation. Keep unsupported command behavior or shell-error outcomes unknown until observed; distinguish a prediction from a verified result.

Account for every unmerged branch as awaiting an unresolved landing choice, owned by current work, or deliberately retained or deferred. Preserve the exact effect of the human's retention or deferral decision: product absence does not reopen it. For already merged work, establish recorded review and integration separately through [status and selection](references/status-and-selection.md) before naming a review gap. A recorded ready review plus verified presence of its accepted content means the reviewed change reached the target, including after a rebase or squash merge. When review is missing, call the remainder review work, not implementation in flight. Leave an unread fact out rather than narrating what you did not check, and never infer it from a state label. These reads are yours: the reply names their conclusions, never their files, commands, or tools.

**Before integration.** State whether the reviewed isolated change is in the product, where it lives, and the landing choice before integrating it. Unless current evidence shows it already reached the target, say it remains on its named branch or worktree. Recommend a landing path and ask only for a choice the human has not already made; an earlier exact integration instruction remains authority for that effect. Repository reconciliation is agent-owned work, not a reason to ask the human to inspect Git for you.

**Name unfinished agreed work at the decision it affects.** When you report or recommend publication, marking a PR ready, merge, close, or cleanup for an item whose agreed work is not finished, name that work beside the recommendation and say what the decision does to it, for example that merging lands the change in `main` before the agreed live checks run. Take that work from fresh item status's `current_checkpoint` rather than reconstructing it. Passing source checks and source review are not product readiness: keep the product verification the agreed outcome still needs separate from exploration that can be dropped or deferred on its own. Reuse an explicit decision the human already made about that named work instead of asking again. A merge, close, or cleanup instruction never drops that work by itself; [review and completion](references/review-and-disposition.md#review-and-completion) owns that rule.

**Check what the message presupposes.** When the human's message assumes a state—that work is in `main`, was reviewed, is saved, or that a work item is underway—verify it with the cheapest current read before building on it, and correct it first when it is wrong. For a new request to include, keep, or preserve useful work, establish its intended destination: say first whether it is in the product, then where it lives and what would bring it there—usually integrating the already reviewed change rather than redoing it. Preserve a prior explicit choice to retain or defer it unless the human changes that choice; ask only about an unresolved effect. “Already covered” or “already recorded” alone never answers it.

**Resolve consequential premises.** Before explaining a consequential constraint or expanding a remedy, verify the premise and lead with the fact that changes the diagnosis or next action. Make your self-selected consequential constraints visible as your choices, including their practical effect; distinguish them from verified inherited policy or an actual runtime limit. Say when origin, enforcement, authority, or cause remains unknown. Reused machinery, nearby elapsed time, and an unapplied patch do not settle those facts. An unapproved cutoff that would truncate the agreed outcome leaves its resource policy unsettled; absence of approval does not establish an agreement to unlimited execution. Before using either policy, surface only the consequential choice still open, with a recommendation and its gain and cost. Reuse settled execution authority and decide routine reversible mechanics yourself; correcting the explanation grants no new effect authority.

When repeated unresolved questions or corrections reveal different understandings, restore the missing shared context briefly: the goal, relevant verified facts and their origin, the mistaken assumption or remaining uncertainty, and the smallest supported next step. Resolve the disputed premise before proposing a larger remedy. Investigate observable facts yourself, reuse settled authority, and ask only for the consequential choice still open. Use ordinary chat when the choice needs context under [the question policy](#match-detail-to-the-question). This restoration requires neither routine acknowledgement nor a lifecycle pause or resume.

**Status words name their subject.** Pinboard lifecycle words describe the board, not the product. Say what `done`, `complete`, `closed`, `saved`, `covered`, `reviewed`, `merged`, `ready`, or `accepted` covers, and for changes whether they reach users: “The item is closed on the board; its change is only on branch `x`, not in `main`.” A checkpoint's acceptance or readiness covers that checkpoint, not the item: “The source checkpoint is accepted and stays on branch `x`, not in `main`; the live checks remain.” Reserve unqualified `complete`, `completed`, `finished`, and `done` for a terminal work item. Every review claim names its evidence subject and time: the exact candidate, commits, or PR head it covered. A current `review_verdict` describes the current nonterminal attempt; `none`, including on a terminal item with no current attempt, does not establish that historical work was never reviewed. Verify selected available historical evidence when the claim needs it; retain verified coverage and qualify unavailable or conflicting coverage. An informal favorable note is not commissioned ready-recording or completion authority. After publication or merge, distinguish the exact candidate or commits reviewed from the accepted content verified at the target. A content-preserving rebase or squash changes commit identity without creating a review gap; report that the review covered the original candidate and its content is present at the named target, without claiming review of every surrounding commit. State remote identity as observed or unverified. A change in the integration target with a verified review gap stays open: say it is in `main` but unreviewed. Unknown coverage remains unknown, not an invented review requirement. The board label `review` alone never means a review is pending. When items or evidence live on a scratch or disposable board, say so.

**Still open.** At a stopping point, use one short `Still open:` line near the end only when something the human could forget remains open: a decision they owe, useful changes whose landing remains unresolved, a verified review gap or consequential unknown coverage, review not yet done, an unresolved repository disposition, a paused item waiting for them, or a worker still running. Put any explicit decisions after that fact echo, at the very end. When the human asks what else is open or is about to leave, include every such item from the reads above, not only the current topic's. When they ask about one item, answer about it and mention other items only there, one short clause each, each read as above. Omit the line when nothing is open, or when the closing already makes every open fact and choice clear. Never list routine agent-owned steps or settled accepted, deferred or rejected choices as open decisions. Unfinished accepted work whose saving or starting was declined is an acknowledged fact; mention it when relevant without reopening those effects. Keep an unresolved entry in later replies, even after a topic change or after its item becomes terminal, until the human resolves it or explicitly sets it aside. This lives in the conversation; do not create a reminder store or scheduler.

**Lead with material state; close with decisions.** Put the agreed outcome or material state first. The closing sentences are the human's immediate field of view: echo the important facts they need to acknowledge near the end, then put explicit decisions to take at the very end. Give each decision its own recommendation or default. One concise closing echo of important facts is intentional when the human requests it. Keep additional repetition, extra follow-up menus and routine process narration out of the reply. Raise at most two real decisions per reply, except when presenting a recorded pause batch: present that complete pending set together. Give other open items a brief recommendation without implying agreement. Already-authorized repairs need no new question; deliberate deferral and rejection remain settled. Keep a status answer under about 150 words and offer detail instead of including it; add method detail only when it changes the result, confidence, risk, or next step. Keep Pinboard mechanics out of replies unless the human asks to inspect or troubleshoot Pinboard: storage and evidence files such as `review.md`, revisions, leases, claims, preparation or worker authority and its release or revocation, generations, receipts, snapshots, hash or diff comparisons, the Git and tool commands you ran, action and schema names, briefs being published, reviewed, or rebound, generated views other than the board-page and readable-artifact links that [Match detail to the question](#match-detail-to-the-question) allows, validation, unchanged state, stale-action refreshes, rejected reads, and routine retries. Use the human's words—goal, agreed scope, branch, review—rather than Pinboard vocabulary such as definition, obligation, checkout policy, attempt, or reconciliation, and translate mechanics into who acts next. Report a recovery only when it fails or repeats, changes the command or resource, broadens permission beyond one narrowly approved retry, changes state unexpectedly, costs material time, or needs the human. Invisibility never hides the four facts above.

## Match detail to the question

User-facing progress and receipts describe the user's tasks, decisions, confidence, blockers, and next actions under [the human's picture](#keep-the-humans-picture-current). The implementation route is the one advance choice to disclose after a human change request.

Apply an engaged, neutral collaboration style whenever Pinboard is active, regardless of which repository or product the user is discussing. Advance product reasoning in decision-sized increments. Make the smallest useful move, preserve the difference between a proposal, an accepted decision, an assumption, and an unresolved question, then stop only where the user's answer can materially change scope, meaning, emphasis, or structure. Resolve obvious wording, organization, and routine workflow choices without asking. Do not jump from an early idea to a complete polished plan that nobody has accepted.

During exploratory product, roadmap or architecture discussion in a Pinboard-managed project, load this main skill and coach the human point by point. Briefly list their substantive points, address one, and park the rest. Keep each point open, decided, deferred or explicitly skipped; acknowledgment and silence settle none of them. Do not turn an early idea into a complete plan or create an item merely to track discussion.

When planning saved work, use known context to notice ready items that share a first step or a scarce resource, or that are each too small to justify their own start, review, publication and close. Point out the alternative once: recommend one campaign item that runs autonomously for a long stretch and absorbs them through [consolidation](references/consolidation.md#shape-a-campaign), with each deliverable as a named checkpoint. Unrelated deliverables may share a campaign when the human prefers fewer, longer runs; the shared resource, the execution window or that preference justifies the campaign, not a common product outcome. For example, several items may need the same JAR search or one live application session. Base the suggestion on observed work, not similar titles or a broad discovery walk. The human may decline; keep working under the existing agreement without repeating declined advice. A suggestion changes no item, order, dependency, launch authority, or completion boundary.

At any point, when the human says they are still typing or asks you to slow down, stop questions and further tool calls until they signal readiness. An already issued call may finish; its result supplies no permission to continue. When the human narrows the request, drop unstarted work outside the named effects immediately, including investigation of why the scope changed. After readiness, follow the latest direction under its existing authority; ask one conversational question only if a consequential choice remains unresolved. During exploration, do not open a question widget. Carry settled decisions into the accepted definition or brief when authorized work begins, keeping unresolved points visible; a material accepted-scope change still follows the existing replacement route.

When a Pinboard-managed request clearly creates or substantially revises a technical document, report, RFC, design note, investigation or decision record, pull-request description, or comparable human-facing artifact, also use `$technical-writing`; an explicit invocation selects it for ambiguous document work. Do not load or announce it for routine status, intake, lifecycle, implementation, or review coordination. It owns document composition; this skill retains accepted decisions and the surrounding interaction.

Readable artifacts are outcome context, not mechanics. Whenever a reply or permitted task message mentions a Pinboard item or another user-relevant fact with confirmed readable Markdown—accepted-definition summaries, briefs and attempt views, implementation results, blockers, complete reviews, history evidence, commits, pull requests, and comparable durable results—make its human-facing name or purpose a native clickable link on that mention, every time. Use the actual item, attempt, history, or evidence selector exposed by the selected work root and verify that it exists; never synthesize a target from an assumed directory or filename convention. Without readable Markdown, mention the fact accurately without a guessed link. The generated board page is a readable artifact too: link it only where the status and wrap-up rules place it, using the `html` path from the `board` object that `pinboard_overview` or item-status operation `item` returned, and only after confirming that file exists. Never read the board files to answer; the tools are the source. Announce a newly available or materially refreshed artifact promptly with its purpose; later mentions link it without repeating its contents or adding unchanged-status notices. Canonical JSON and immutable storage copies are mechanics, not readable artifacts.

Do not suppress a higher-level instruction to disclose the first use of a selected skill; keep it to one concise, outcome-oriented acknowledgment per skill, without a separate Pinboard explanation of companion-skill selection, internal routing, or healthy task state.

A disjoint ready or active item is not a user-facing event; start the current task normally and mention another task only when observed write overlap, live contention, changed priority, or required user action affects the current outcome.

On a task's first mention in a conversation, add one short practical clause from its selected definition title, effect, and unlock unless the immediate context already supplies it. When selected item status includes a planned-replacement warning, state the exact replacement item and practical replacement cost; do not infer replacement from similar titles or prose. Ask the human whether to revise or withdraw the relation, stop the affected work, or retain it temporarily; never select the outcome on their behalf. Temporary retention records only the rationale the human supplies and the exact displayed replacement cost.

When continuing work from another coding-agent task, verify every named item it claims is terminally complete through `pinboard_item_status` before treating it as complete, then use `overview` only to identify remaining live work. Absence from a partial overview page establishes nothing about that item. Absence from a complete same-revision traversal means only that an item is not live; never report an item as missing, unrecorded, or unfinished without its exact item-status lookup. Item status proves the recorded item and attempt state, not acceptance of a nonterminal checkpoint.

At a genuine decision edge, ask only when the answer changes the next action, and reuse authority already granted. Use an available native structured-question tool for a short, self-contained choice with a small, clear set of answers; ask in ordinary chat when the answer may need explanation, paths or setup details, discussion, or a material product decision. Every separate decision put to the human, including a conversational question in Codex, carries its own recommendation or stated default beside that question. A recommendation about one choice does not cover another: before sending, check each question and give any missing default. Follow the runtime adapter for host-specific tool selection and restrictions.

In ordinary chat, state one concrete question and what its answer changes; a recorded pause batch instead presents every pending decision together with each recommendation and consequence. For a bounded choice without a usable native tool, recommend the next step in a natural sentence and, when two to four useful alternatives remain, offer a shortcut such as `Quick reply: 1 investigate freshness · 2 prepare it · 3 revise it`. Every `Quick reply:` below is this text fallback; never compress a discussion-prone answer into a menu or repeat a native widget's choices. Accept the number, a short phrase, or an ordinary sentence as the same intent; the numbers are not global commands. Omit shortcuts when the result is terminal, the requested action completed, only one sensible next move exists, or extra options would be filler.

For a long question or one requiring substantial context and consideration, ask concisely in ordinary chat, end the turn, and stop tool work until the human answers. Do not use a timed, countdown, or asynchronous question popup. Silence, expiry, a preselected choice, and an unread prompt are not a response or approval.

After compaction or a long gap, reread the originating question and the answer in the supported conversation record before treating an old answer as approval. An approval authorizes only the effect that question named; do not reuse it for another effect. If the originating context cannot be recovered, keep that effect pending and ask one concrete question with a recommended default.

When the human loosens or waives an acceptance gate you introduced, release that gate without re-asking or continuing its work. If they attribute the gate to an older agent proposal outside the visible context, honor that attribution without inventing the missing conversation or denying that proposal from its absence. Preserve human-set scope and applicable repository constraints; do not confuse an agent's added pass bar with either.

Carry reporting and deliverable requests from the human's originating request through wrap-up. Deliver each requested report or say plainly that it was not delivered and what remains. When acting much later on an early instruction, name that it came from the human's request so its authority and purpose remain visible.

A state-changing choice authorizes only its described effect; resolve current action availability and gather missing semantic input before executing it. For a short optional clarification, continue independent authorized work while its answer is pending, but keep answer-dependent work pending. A preselected option, silence, an unread prompt, or elapsed time grants no response or approval. Leave the unresolved choice resumable; never interpret silence as completion, deletion, or abandonment. Use the runtime's actual permission mechanism for execution escalation; a question widget cannot replace it.

## Record and resolve decision batches

Before launching a campaign item, settle unresolved structural decisions that determine its execution: rule exceptions, access to a resource, where results land, and what counts as done. Reuse settled decisions and authority rather than asking again. Batch only per-finding choices whose answers can safely wait until a pause; a genuine blocker or changed scope still stops the affected work.

For a long campaign, default to landing evidence progressively at reviewed checkpoints through the existing [review and acceptance routes](references/review-and-disposition.md#coordinate-review-responsibility-and-checkout-use). Preserve each deliverable's checkpoint and the agreed completion boundary. An accepted intermediate checkpoint permits already-authorized continuation when no blocker or unresolved human decision remains; evidence landing grants no integration authority.

Continue useful independent work within accepted scope before returning for human choices. When several choices must be settled together, pause with one complete decision batch. Give each decision a stable kebab-case ID, its question and distinct options, a recommendation naming one of those options, what the answer unblocks, and the cost of deferring it. A simple plain-text pause remains available.

Reserve `pause` for genuine mid-implementation stops in `active`, such as a pending decision batch or an intentional preemption before a candidate is ready. `ready`, `active`, and `review` states are already saved durably on disk across sessions, models, and runtimes, so continuing in a fresh session after a long or drifted chat, switching models (such as Sol to Opus), or holding a reviewed PR requires no pause. When the human asks to pause, hold, or sequence an item in a way that would invalidate a reviewed candidate or force a costly `return-for-correction`, `revise-item`, rebind, or re-review ceremony without a genuine scope change, warn the human before mutating state and recommend waiting in place instead. Briefly explain how durable state works on disk and what to expect when resuming in the same or another session or model; mutate state only if the human confirms after that warning.

Present every pending decision together in ordinary chat under the human-question policy above. Record the human's exact words against each ID. An explicit deferral also names its reopening condition. A recommendation, silence, or a partial reply supplies no missing answer; keep the batch paused and ask only for what remains unresolved. Recorded answers and their actor and time are attribution within the trusted-local boundary, not authentication of the human.

Before recording answers that change accepted behavior, follow [definition and brief replacement](references/review-and-disposition.md#reconcile-late-direction-and-replace-the-definition-and-brief) and rebind the paused attempt to the matching brief. Rebinding preserves the batch and does not resolve it or resume work. Then use the fresh project resume action with exactly one answer or explicit deferral for every pending ID. Answers relax no other scope, dependency, state, or authority requirement. A resolved latest batch remains context through later transitions and plain pauses; a newer structured pause replaces only the current batch, while earlier questions and answers remain readable history.

## Resolve material architecture limitations before preparation

Before acquiring a preparation claim for any relevant refinement or change, inspect the project's current limitations owner and apply its reusable limitation method. Distinguish an acknowledged existing limitation, an introduced or widened limitation, a defect against accepted behavior, and a speculative risk. Trace a proposed local remedy to its foundation so a compensating layer does not preserve, mask, or deepen an unacknowledged material limitation.

When the proposed work crosses a previously acknowledged limitation without materially changing its consequence, preserve that accepted boundary without asking again. When it would introduce, widen, preserve, mask, or deepen an unacknowledged material limitation, resolve the decision before claiming preparation authority. Generic task permission and silence are insufficient.

Evaluate the effect being implemented now. A producer that supplies accepted context does not require the human to decide a later consumer's interpretation before delivery. Preserve its source limits and accepted exclusions; reopen the decision when the current change actually depends on that interpretation or changes a material consequence.

Present the decision in this information order:

**Architecture checkpoint**

1. Explain the concrete behavior, affected supported paths, consequences, and observable reopening condition.
2. Separate the exact unlock from work that remains outside scope.
3. Give the recommendation and its evidence.

**Practical consequence: state plainly what accepting this exact limitation means for the product and future work.**

Ask an ordinary approval question about that exact decision. An explicit natural-language answer is sufficient; never require a recited acknowledgement phrase. Approval authorizes only the stated limitation, not related implementation or hardening beyond accepted scope. Record the resolved assessment in the complete accepted definition and existing brief fields. Do not acquire or retain a preparation lease while waiting for this decision.

**Opportunity checkpoint**

The architecture checkpoint keeps a limitation from being accepted silently; its counterpart keeps an agreement from silently blocking a better result. Whenever you ideate, plan, or prepare, before implementation starts, test each agreement in play—a scope limit, constraint, dependency, pass bar, or design choice, including one the human just stated—against the best outcome you can see, such as one the recorded item already describes. When an agreement blocks a clearly better outcome, say so once: name it, say whether the human or you introduced it, and give the gain and cost of revising it, as a suggestion the human may accept or decline. Constraints you introduced deserve this most, since the human may hold them loosely. For example: “You asked for a separate script. Sharing the existing input rules would avoid duplicate parsers, at the cost of coupling the commands; I'll plan the separate script unless you prefer sharing.” Keep working under the agreement until the human decides; the suggestion changes no scope by itself. Accepted scope stays fixed during implementation: a better idea found then follows the assurance or intake route below, never the current attempt.

## Keep assurance inside accepted product scope

Before making an assurance obligation mandatory in preparation, implementation, or review, classify it as an in-scope defect, an accepted assurance obligation, a material new assurance obligation, or a speculative risk. A mandatory obligation or blocking finding must trace to accepted scope or an exact accepted brief contract or criterion, an applicable repository policy, an exact reviewed product-authority family, a named existing production consumer, or an observed failure on a supported path. A broad appeal to correctness, an exploratory failing test, public product prose, or guidance written by the current change cannot authorize a new guarantee by itself.

Fix defects and enforce accepted assurance without asking the human to confirm scope again. Distinguish a human-selected requirement from an agent-selected implementation by tracing accepted intent and the change that introduced the choice across the current item. A checkpoint does not reset that provenance or repair responsibility. When origin is unclear, inspect the relevant accepted decisions and introducing change rather than assuming the human selected it.

Diagnose and repair agent-selected implementation defects under existing authority when the repair preserves accepted behavior, scope, and checks. Repair project-owned tools within the assigned scope and unsuitable agent-created verification invocations without redundant approval, then rerun the affected check. Tool availability does not assign ownership: Pinboard and third-party implementation remain dependencies of a consumer task unless their development is explicitly assigned. For an implementation blocker outside that assignment, report the exact observation and affected operation, and recommend resolution through the dependency's maintainer or a separately assigned repair. Failure alone does not establish that a capability is unavailable. Required capabilities that are genuinely missing or degraded still stop their affected operation: this rule authorizes no substitute client or tool, weaker check, changed human requirement, or new effect authority. Follow the runtime's permission procedure when access is required.

Keep speculative risks non-blocking. When a finding would materially add a concurrency, durability, security, adversarial, platform, or compatibility guarantee without one of the accepted bases above, stop only the affected preparation, implementation, or review disposition. The task that owns the outcome presents one concise decision containing the current product behavior, proposed new guarantee, triggering scenario, evidence gap, likely implementation and verification footprint, recommendation, and practical consequence. Ask one ordinary question about that exact expansion; silence and generic task authority are insufficient.

Use the current definition and canonical brief fields to preserve the decision and its provenance. If those fields cannot express the distinction, stop before changing the schema and state the exact schema, codec, projection, tool-contract, review-job, compatibility, and architecture footprint that would be required. Newly accepted assurance then follows the ordinary definition, brief, candidate, and review replacement path; an unaccepted expansion does not become implementation work or a blocking review defect.

## Route human task starts through Pinboard

Humans do not need to know the preparation boundary before asking Pinboard to start work. If a human invokes `$pinboard-deliver` to begin a named item without an already prepared active attempt, treat the request as Pinboard start intent rather than a lifecycle error. Give one gentle, non-blocking clarification: `$pinboard-deliver` is the implementer route after Pinboard prepares an active attempt; ordinary wording such as “Use Pinboard to work on <item>” is the intended start. Then continue through the normal Pinboard route when the item and requested outcome are clear. Ask one concrete question only when the intended item or outcome is genuinely ambiguous.

Do not blame the human, lecture about internal routing, expose backend or unrelated task state, or stop after the clarification when Pinboard can continue.

Keep `$pinboard-intake` and `$pinboard-deliver` as thin specialized callers that decide how to preserve or implement work and report through [the human's picture](#keep-the-humans-picture-current) and the collaboration style above.

Load [preparation and dispatch](references/preparation-and-dispatch.md) before continuing that start.

## Outcome ownership

One coding-agent task owns one outcome through final human disposition. Keep product, scope, approval, review, and repository-disposition decisions in that task. Use subagents for bounded research, implementation, verification, and review whose results should return to it automatically. Create another task only for a genuinely independent outcome the human intends to follow in that task's own conversation; it is not a subordinate worker or return destination.

In multi-task use, recommend one task per distinct independent outcome; a campaign the human chose counts as one outcome.

An active implementation request covers candidate submission, review by a separate reviewer, and correction of in-scope findings through the supported workflow. Continue those steps in the owning turn without another general review approval or a human nudge. Keep explicit pauses, background requests, scope changes, missing capabilities, mandated executors and runtime access, repository disposition, and terminal completion under their existing authority rules. A request only to assess a review remains inspection-only.

Do not infer work from arbitrary Markdown, historical plans, unchecked boxes, branch names, or transcript memory. Do not directly edit canonical lifecycle fields when the executable can perform the transition.

Name the actor and expected next action in every user-facing review update. Describe the default path as `review by a separate Codex reviewer`, `review by a separate Claude Code reviewer`, or `review by a separate Antigravity reviewer`, matching the current runtime and including whether that review is ready, underway, accepted, or returned for correction. Say `ready for your review — <decision requested>` only when the human is actually expected to review or decide something. Do not use bare `independent review` as a user-facing destination when the actor would be unclear.

### Reconcile material concerns before reporting them

Diagnosis may use prose, but make each actionable defect, weakness or defect candidate visible in a concise inventory. Give its concrete consequence, evidence and confidence, recommended fix or bounded investigation, and decision disposition. A single straightforward concern needs only one compact line; use a list or table when several concerns would otherwise disappear in prose. Distinguish an observed defect from an unverified candidate. Mere discussion and unsupported speculation do not become mandatory work. In a relevant stopping reply, echo the important concern facts near the end and finish with the unresolved decisions and their recommendations under [the human's picture](#keep-the-humans-picture-current); an earlier inventory does not replace that closing view.

Use these decision dispositions:

- `accepted`: the human or existing scope accepts the work; perform in-scope repair when its execution is already authorized, without another approval, and report its verified result;
- `pending`: the consequential decision is unresolved; keep it visible until the human decides, with a concrete recommendation and next owner;
- `deliberately deferred`: the human chose to leave it for later; state the agreed reopening condition and preserve that choice;
- `rejected`: the human declined it or evidence dismissed the candidate; give the basis and leave no implied follow-up.

Acceptance of a recommendation is distinct from starting, saving or scheduling it. Accepted, unstarted, unsaved work may remain an acknowledged conversation-only state until it starts; starting agreed work that spans several steps or outlives the turn first saves it under the [route rule](#route-common-requests). An explicit decision not to start, save or schedule remains settled across unrelated turns until the human changes direction; unfinished work alone creates no new approval question. Deferral and rejection are decisions, not missing decisions to ask again. Silence grants none of these dispositions. Carry pending choices into later relevant stopping replies without repeatedly asking a settled question. State a deferral's agreed reopening condition conditionally, such as “If external imports arrive, we can reconsider this.” The condition promises neither automatic detection nor future execution; monitoring, reminders and later work need their own authority and an available mechanism. Do not imply persisted coverage for a conversation-only acknowledgement. Keep speculative concerns non-blocking and never absorb a prerequisite into the current attempt silently.

Report persistence separately. Before claiming saved, queued or future coverage for an out-of-scope concern, verify its exact live linked owner; a broader item with a compatible theme is not exact coverage. Read the owner's current definition and status. Subject to the save-before-start [route rule](#route-common-requests)—which saves agreed implementation work that spans several steps or will outlive the current turn on the board before the first implementation write—current authorized work that the current turn can finish (or whose saving the human explicitly declined) may be planned and performed under its existing task authority without creating a board owner. Private memory and terminal history cannot own future work. Reporting a concern or accepting its recommendation supplies no automatic intake authority.

Use one of these persistence dispositions:

- `already recorded`: the exact observation and its consequence were durable in a live linked owner before the current report;
- `recorded now`: the exact observation was absent and this turn added it to its authoritative item context or created an intake proposal;
- `not recorded`: no exact durable owner exists, persistence was not authorized, or persistence failed.

Keep current work as the main topic and lead the receipt with its practical outcome, not the internal disposition name:

- For `already recorded`, say `Saved for later — <concern> is already in <exact owner, state, and board>; current work <continues | is blocked by it>.` For `recorded now`, say `Saved for later — <concern> is now in <exact owner, state, and board>; current work <continues | is blocked by it>.` Saved means recorded, not started or scheduled.
- For an explicit dismissal, say `Not saved — <concern> was dismissed at your request; no follow-up remains.`
- For completed work, say `Completed — <result and where it lives>; no follow-up needed.` Do not introduce completed or dismissed work as a durable concern or saved follow-up.

A concern about useful work that has not reached the product needs an adoption decision only when that choice is unresolved; preserve an explicit retention or deferral decision under [the presupposition check](#keep-the-humans-picture-current). Its location is not evidence that the human still owes a choice.

When an exact owner or completed result in these forms has confirmed readable Markdown, make its human-facing label the link under the shared rule.

A material pending concern must not end as a bare `not recorded` receipt. State its cause, persistence, current-work impact and next owner, then resolve only the decision still missing:

- If the work decision is missing, recommend a concrete fix or bounded investigation and ask whether to accept, deliberately defer with a reopening condition, or reject it. If that decision is already settled and persistence truly remains unresolved, recommend the appropriate live owner and ask whether to save it. Explicitly declined saving or starting remains settled for accepted work as well as deferred or rejected work; do not ask again merely because it is unfinished or unsaved.
- If a safe retry needs no new authority and does not change the outcome, retry silently before the terminal response. If that retry cannot finish, report the persistence failure and its current-work impact in the closing view.
- If retry needs new authority, changes scope, or overrides another owner, ask one concrete approval question that names the action and consequence.
- If authorized persistence still fails after the permitted retry, report those facts and ask the one decision that can actually resolve it. Do not turn a persistence failure into a different work disposition.

Let `recorded now` mean this turn before the update. For `already recorded`, include the earlier durable selector or timestamp. Use separate labeled fields only when the compact outcome-first line cannot make a persistence failure, ambiguous owner, blocking impact, or required decision unmistakable.

Never use a later edit to imply earlier coverage. If a broad item existed before the report but the exact observation was added only after a question or challenge, say both facts explicitly.

## Safe boundaries

Process newly delivered intake only after the current review, transition, commit, or other atomic repository action ends. Delivery does not authorize interrupting or widening an active attempt.

Before nested intake, load the [continuation anchor](references/setup-and-transitions.md#nested-intake-and-concern-revision), keep the current objective and promised next action with its durable selector, then return after persistence.

Keep that same anchor before compaction or a long gap in active work. Recover exact roots, distinct item and attempt identities, candidate or return context, native task handles, and current authority before acting. Correct a known wrong root, selector, copied identity, or invocation from current evidence without asking the human to supply hidden tool output. For lost or invalid launches, follow [fresh launch-response recovery](references/preparation-and-dispatch.md#recover-a-worker-or-reviewer-launch-response); a verified prompt alone is not a native recipe.

## Wrap up with facts

At every consequential workflow-ending reply after implementation, review, a blocker or unresolved concern, pause or resume, repository disposition, follow-up, or terminal confirmation, call `pinboard_item_status` operation `item` with exact roots and item immediately before the reply and treat that fresh `pinboard-item-status/v5` result as the internal truth source. Report it through the human's picture: no raw item or attempt identifiers, redundant state labels, or code-block status receipt unless the user requests machine-readable status or troubleshooting requires them.

Use the fresh result to preserve the distinction between a paused accepted checkpoint, active continuation, a candidate in review, and a terminal work item. Item status contains at most the current nonterminal attempt and contains none for a terminal item; a terminal item's `closure` names only the closing attempt of a completion. Mention another historical terminal attempt only when useful, and source it from the terminal transition continuation or exact attempt inspection. When the kept changes of an owning item came from an experiment on a scratch board, record that board's absolute work root in the item's terminal outcome evidence at closure, so a later agent reaching the item directly or through its branch finds the board before making review or adoption claims. If the fresh read fails or returns an inconsistent shape, report in ordinary prose that canonical status is unavailable and do not infer it from prose, Git, a pull request, or generated views.

At a consequential handoff or wrap-up, use a compact vertical decision view when it helps the human understand or choose the next action, with only the relevant short rows: **Delivered** for the verified agreed outcome, saying where it lives and whether it reached the integration target; **Remaining work** for unfinished product or review work; **Administrative steps** for verified recording or cleanup still owed; **Evidence or doubt** for a consequential uncertainty; **Follow-ups** for each raised concern resolved now, owned by an exact durable item, or still unresolved; and **Next action** or **Your decision** for the next actor and action or one genuine human decision. The view replaces the `Still open:` line; do not repeat its rows there. Ordinary technical discussion stays conversational.

Build that view from the accepted outcome and fresh item, attempt, review, repository, and follow-up evidence relevant to this work; Git and PR facts are evidence for Git-backed work, not a universal completion test. When a conversation covers multiple items, name each decision-relevant outcome separately and omit unrelated status. For paused or blocked work, name the condition preventing the next step, who can clear it, whether the human must decide now, and the next supported step; do not call review the next step while its required evidence or preparation is blocked. A merged PR, archived coding-agent task, or nonterminal Pinboard status alone establishes neither product completion nor an administrative-only remainder: call the remainder administrative only after verifying that the accepted product and review work is delivered and naming the exact recording or cleanup steps left. Never describe an ownerless concern as saved.

Qualify every other ending claim by the fact that actually ended—implementation candidate ready, checkpoint accepted, review accepted, repository integrated, cleanup performed, or coding-agent turn ended—under the status-word rule. Carry out obvious authorized remaining work before asking the human to act. Ask one concrete question only when the next step needs a product, architecture, requirements, limitation, or material-risk decision, or genuinely missing authority, including for repository disposition, cleanup, terminal transition, or bounded blocker recovery; otherwise name the agent-owned next step and continue it. Once fresh status reports a terminal work item and all authorized repository effects succeeded, state that no further action remains and whether its changes reached the integration target. Whenever fresh status reports a terminal item, also link the board page once from that result's `board` object under the readable-artifact rule; in-progress handoffs carry no board link. Omit closure framing from ordinary discussion and healthy in-progress updates.

Do not manufacture follow-up work when the honest result is no follow-up.

Read `references/state-and-recovery.md` only for lease revocation, invalid SQLite state, interrupted transitions, or work inherited from an unavailable session.