docs(skill): require agents to claim only monitors they actually scheduled (#10064)

## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work, and the shared `skills/paperclip/SKILL.md` is the behavioral
contract every managed agent follows each heartbeat.
> - Issue continuation between heartbeats depends on real, persisted
state: an issue only auto-resumes when it has a scheduled **issue
monitor** (`monitorNextCheckAt` + an execution-policy `monitor` block)
that the server's `tickDueIssueMonitors` scheduler polls and re-wakes
via `issue_monitor_due`.
> - A run/heartbeat is an ephemeral execution window — nothing keeps
"watching" after it exits — but the skill never said this, so agents
narrated a "watcher in this run" as if a live subscription existed.
> - That gap produced a concrete user-facing failure: an agent claimed
"a watcher in this run wakes me when CI + Greptile complete," then the
run ended with no monitor scheduled and nothing ever resumed, leaving
the user unsure whether a watcher existed at all.
> - This PR closes the gap by documenting what a monitor actually is and
adding hard rules so agents only claim a watcher they have actually
scheduled, describe it in checkable terms, and never imply a live
watcher on a task they mark `done`.
> - The benefit is that agent narration stays consistent with the
disposition guard and recovery classifier that already enforce these
paths in state, so users get accurate expectations about whether and
when a task will resume.

## Linked Issues or Issue Description

This is a documentation-only change to a shared agent skill, so no code
issue is required. The underlying problem it addresses:

**Problem or motivation** — Agents were telling users that a "watcher in
this run" would wake them when external checks (CI, Greptile) finished,
when no persisted issue monitor had been scheduled. Because a heartbeat
is ephemeral, no such watcher exists after the run exits, so the task
silently never resumed and the user was left confused about what would
happen next.

**Proposed solution** — Document, in the shared skill, exactly what an
issue monitor is (durable `monitorNextCheckAt` + execution-policy
`monitor` block, polled by `tickDueIssueMonitors`, re-woken via
`issue_monitor_due`) and add rules that agents may only claim a
watcher/monitor after actually scheduling one, must describe it in
checkable terms (kind / next check / timeout / attempts), and must never
imply a live watcher on a task being marked `done`.

**Alternatives considered** — Enforcing purely in server state (the
disposition guard and recovery classifier already reject
`in_review`/parked issues without a real wake path). That enforcement
exists but does not stop an agent from *narrating* a non-existent
watcher in a comment; aligning the skill guidance with the existing
state enforcement is the missing piece.

## What Changed

- Added a **"Monitors and Watchers (say only what you actually
scheduled)"** subsection to `skills/paperclip/SKILL.md` explaining that
a watcher does not live inside a run, and that only a persisted issue
monitor can auto-resume an issue (with the concrete fields and the
`tickDueIssueMonitors` / `issue_monitor_due` polling path).
- Added three behavioral rules: only claim a monitor after scheduling
one (and how to schedule/confirm it via `PATCH /api/issues/{id}` and
`monitor/check-now`); describe monitors in checkable terms; never imply
a live watcher on a task marked `done`.
- Cross-referenced the rule from the **Critical Rules** list.
- Tightened the final-disposition checklist so `in_review` /
`in_progress` continuation requires a real, non-null
`monitorNextCheckAt` rather than a merely described one.

## Verification

- Docs-only change to `skills/paperclip/SKILL.md`; no code paths are
affected.
- Confirmed every identifier referenced in the new text is real in the
codebase: `monitorNextCheckAt`, `monitorScheduledBy`,
`executionPolicy.monitor`, `tickDueIssueMonitors`, and the
`issue_monitor_due` wake reason.
- Rendered the Markdown to confirm the new subsection and the Critical
Rules bullet display correctly and links resolve within the document.
- `git diff` confirms the change is limited to the single skill file (14
insertions, 2 deletions).

## Risks

Low risk. This is guidance text in a shared agent skill with no runtime
or schema impact. Worst case is stylistic wording that can be refined in
a follow-up; it cannot break builds, migrations, or behavior. It
strengthens (never loosens) the existing disposition guarantees.

## Model Used

Claude Opus 4.8 (model id `claude-opus-4-8`, 1M-context variant) running
in an agent harness with extended thinking and tool use (file edit,
shell, git, GitHub CLI).

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [ ] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

skills/paperclip/SKILL.md

@@ -112,10 +112,10 @@ If you are blocked at any point, you MUST update the issue to `blocked` before e
 Before ending any heartbeat, apply this final-disposition checklist:
 
 - `done`: the requested work is complete, verification is recorded, and no follow-up remains on this issue.
-- `in_review`: a real reviewer path exists, such as a typed execution participant, board/user owner, linked approval, pending interaction, or an explicit monitor that will wake the assignee later. Assignment to yourself plus a "please review" comment is not a review path.
+- `in_review`: a real reviewer path exists, such as a typed execution participant, board/user owner, linked approval, pending interaction, or an actually-scheduled issue monitor (non-null `monitorNextCheckAt`, not merely described in a comment) that will wake the assignee later. Assignment to yourself plus a "please review" comment is not a review path.
 - `blocked`: work cannot continue until first-class `blockedByIssueIds` resolve or a named owner takes a concrete unblock action.
 - Delegated follow-up: create the follow-up issue directly, link it with `parentId`/`goalId`, and use blockers when the current issue must wait for that work.
-- Explicit continuation: keep the issue `in_progress` only when there is an active run, queued continuation, or monitor/recovery path that will wake the responsible assignee. Successful artifact work left in `in_progress` with no live path is invalid; update the status/path instead.
+- Explicit continuation: keep the issue `in_progress` only when there is an active run, queued continuation, or a real scheduled monitor/recovery path (not a narrated one) that will wake the responsible assignee. Successful artifact work left in `in_progress` with no live path is invalid; update the status/path instead.
 
 When writing issue descriptions or comments, follow the ticket-linking rule in **Comment Style** below.
 
@@ -148,6 +148,17 @@ Status values: `backlog`, `todo`, `in_progress`, `in_review`, `done`, `blocked`,
 - `done` — work complete, no follow-up on this issue.
 - `cancelled` — intentionally abandoned, not to be resumed.
 
+### Monitors and Watchers (say only what you actually scheduled)
+
+A "watcher" or "monitor" is not something that lives inside a run. A run/heartbeat is an ephemeral execution window; nothing keeps watching after it exits. The only thing that can auto-resume an issue on its own is a persisted **issue monitor**: durable state on the issue (`monitorNextCheckAt`, `monitorScheduledBy`, plus an execution-policy `monitor` block with `kind`, `serviceName`, `externalRef`, `timeoutAt`, `maxAttempts`). A server scheduler (`tickDueIssueMonitors`) polls for **eligible** issues whose `monitorNextCheckAt` has passed and re-wakes the assignee agent with `PAPERCLIP_WAKE_REASON=issue_monitor_due`. Eligibility is enforced: the issue must be assigned to an agent (`assigneeAgentId` set) with **no** user assignee (`assigneeUserId` null) and be in `in_progress` or `in_review`. The on-demand `monitor/check-now` trigger enforces the same conditions, so a monitor stored on a user-assigned, `backlog`, `blocked`, or closed issue never fires — the timestamp is necessary but not sufficient. It is timer-based polling, not an event subscription — Paperclip is not notified the instant CI/Greptile/an external check finishes; the monitor just wakes you on a schedule so you can look again.
+
+Because of that, follow these rules:
+
+- **Only claim a watcher/monitor exists after you have actually scheduled one.** Describing a watcher in a comment does not create it. Schedule it by setting `executionPolicy.monitor.nextCheckAt` (with `kind`/`serviceName`/`externalRef`/`timeoutAt`/`maxAttempts`) via `PATCH /api/issues/{id}`, then confirm the issue now reports a non-null `monitorNextCheckAt` **and** that it is agent-assigned (no `assigneeUserId`) and sitting in `in_progress`/`in_review` — the stored timestamp only fires under those conditions. Run a check on demand with `POST /api/issues/{id}/monitor/check-now`.
+- **Describe it in checkable terms.** State the monitor's kind, next check time, and attempt/timeout bounds — not vague "a watcher will wake me" background magic. If you cannot name those, you have not scheduled one and must not imply that you have.
+- **Never imply a live watcher on a task you are marking `done`.** `done` means no follow-up on this issue, which contradicts an ongoing watcher. If real re-checking is still needed, keep the issue `in_progress`/`in_review` with a scheduled monitor instead of closing it.
+- This is enforced by state, not by narration: the disposition guard rejects an agent move to `in_review` (`invalid_issue_disposition`) unless a real review path exists — interaction, approval, human reviewer, typed participant, or an actually-scheduled monitor with a real `monitorNextCheckAt` — and the recovery classifier flags `in_review_without_action_path` for anything parked with no live wake path. Keep your comments consistent with that real state.
+
 **Step 9 — Delegate if needed.** Create subtasks with `POST /api/companies/{companyId}/issues`. Always set `parentId` and `goalId`. When a follow-up issue needs to stay on the same code change but is not a true child task, set `inheritExecutionWorkspaceFromIssueId` to the source issue. Set `billingCode` for cross-team work.
 
 ## Managing A User's Inbox
@@ -390,6 +401,7 @@ Exact response fields are documented in `skills/paperclip/references/api-referen
 - **Preserve workspace continuity for follow-ups.** Child issues inherit execution workspace from `parentId` server-side. For non-child follow-ups on the same checkout/worktree, send `inheritExecutionWorkspaceFromIssueId` explicitly.
 - **Never cancel cross-team tasks.** Reassign to your manager with a comment.
 - **Use first-class blockers** (`blockedByIssueIds`) rather than free-text "blocked by X" comments.
+- **Say only what you actually scheduled.** Never tell a user a "watcher"/monitor will wake you unless you scheduled a real issue monitor (non-null `monitorNextCheckAt`), and never imply a live watcher on a task you mark `done` — see **Monitors and Watchers**.
 - **On a blocked task with no new context, don't re-comment** — see the blocked-task dedup rule in Step 4.
 - **@-mentions** trigger heartbeats — use sparingly, they cost budget. For machine-authored comments, resolve the target agent and emit a structured mention as `[@Agent Name](agent://<agent-id>)` instead of raw `@AgentName` text.
 - **Budget**: auto-paused at 100%. Above 80%, focus on critical tasks only.