Pinboard

---
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 coding-agent runtime adapters](references/runtime-adapters.md) for identity, checkout isolation, subagents and reviewers, permission declarations, waiting, and optional messaging. This skill owns the shared decisions in both integrations.

## Route common requests

Load this complete main skill before answering about saved work, including a quick read-only status: use the native skill loader, or read its actual resolved `SKILL.md` completely when no loader is available. 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.

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.

A missing required tool stops that operation; it never invites shell commands or temporary payload files. A Claude, Codex, 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.

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.

## 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 | [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 or interrupted transition | [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.

**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`, or `merged` 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`.” 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, end with one short `Still open:` line 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. 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 reply already asks or lists everything that is open. Never list routine agent-owned steps in it. Keep an 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 decisions; keep mechanics invisible.** Put the decision or material state first and state each fact once; never repeat “not in `main`” or a pending decision elsewhere in the same reply. Raise at most two decisions per reply, each with your recommendation, and give every other open item your default in a few words. 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 the human says they are still typing or asks you to slow down, stop questions and tool work until they signal readiness. After readiness, ask one conversational question about the current point, with your recommendation or default; do not open a question widget during exploration. Carry settled decisions into the accepted definition or brief when authorized work begins, keeping unresolved points visible.

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 overview title, effect, and unlock unless the immediate context already supplies it. When the overview 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 `overview` 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. 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.

## 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.

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. 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.

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` or `review by a separate Claude Code 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

Before presenting a discovered out-of-scope concern as planned, preserved, covered, queued, deferred, or future work, determine the disposition of that exact concern. A broader item with a compatible theme is not exact coverage. Every planned fix or follow-up-worthy observation needs a verified fix, an exact live linked Pinboard owner, or a deliberate drop agreed with the human. Private runtime memory and a terminal item's history cannot own future work. Read the exact definition and current status before claiming an existing owner; carry an unresolved ownership decision to the human with your recommendation. Mere discussion points remain conversational until they become accepted work or a follow-up-worthy observation.

Use one of these durable 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 `not recorded` disposition is unresolved and must not end as a bare receipt. State the concern, exact cause, durable state, current-work impact, and next action owner. Then produce exactly one resolution:

- If preservation lacks authorization, ask one concrete preserve-or-dismiss question: `This needs a decision — <concern> is not saved because <cause>. Current work <impact>. I recommend preserving it for later. Should I preserve it or dismiss it?`
- 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 once.
- If retry needs new authority, changes scope, or overrides another owner, ask one concrete approval question that names the action and consequence.
- If persistence still fails after the permitted retry, report the same four facts and ask the one decision that can actually resolve it. Never leave `not recorded` as a terminal aside.

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.

Never absorb the prerequisite silently into the current attempt.

## 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.

## 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/v3` 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, or interrupted transitions.