Diagnose Why Work Stopped

>.

You say
Install this skill Read the source first Free Written by paperclipai · unverified publisher
Context cost
2.9k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 11.7 kBtext throughout, nothing executable
Licence
MITfree to use
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

How to handle "why did this work stop / why is this looping?" assignments. Forensics first on the named tree, surface the exact stop-point, frame the fix as a general product rule that respects three invariants (productive work continues, only real blockers stop work, no infinite loops), and deliver a plan — no code changes — gated by board/CTO approval before child issues are created. Use whenever the issue title or body asks for forensics on a stalled, looping, or "went too deep" tree.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

productivity

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md11.7 kB · 162 lines
--- name: diagnose-why-work-stopped description: > How to handle "why did this work stop / why is this looping?" assignments. Forensics first on the named tree, surface the exact stop-point, frame the fix as a general product rule that respects three invariants (productive work continues, only real blockers stop work, no infinite loops), and deliver a plan — no code changes — gated by board/CTO approval before child issues are created. Use whenever the issue title or body asks for forensics on a stalled, looping, or "went too deep" tree. ---
13# Diagnose Why Work Stopped
14
15A repeatable procedure for the recurring class of issues where the user (or a manager) points at a stalled / looping / over-recovered issue tree and asks "why did this stop / why is this looping / how do we make sure this doesn't happen again?"
16
17This skill is **diagnostic + product-design**, not engineering. The output is a written root cause and an approved plan. No code changes leave this skill.
18
19Canonical execution model: read doc/execution-semantics.md before diagnosing or proposing a new liveness/recovery rule. Use that document as the source of truth for status, action-path, post-run disposition, bounded continuation, productivity review, pause-hold, watchdog, and explicit recovery semantics. If the investigation finds a true product-rule gap, the plan should say whether doc/execution-semantics.md needs a matching update.
20
21## When to use
22
23Trigger on an assignment whose title or body matches any of:
24
25- "why did this work stop", "why did this stall", "why did this just stop"
26- "infinite loop", "looping", "spinning", "going too deep", "recovery went too deep"
27- "liveness — what happened here", "this tree stopped working", "stuck"
28- "approach it from a product perspective", "general product principle / rule"
29- An attached link to a specific stalled / looping / over-recovered issue tree
30
31Also use when the user asks for forensics, root cause, or a write-up *before* any product change.
32
33## When NOT to use
34
35- The assignment asks you to ship a code change directly. Use normal engineering flow.
36- The assignment is a normal bug report against a specific feature. Use normal investigation.
37- You are the original implementer being asked to fix your own bug. Use normal debugging.
38
39## Three invariants you must preserve
40
41Every diagnosis and every proposed rule must hold these three invariants together. The user has restated them on at least four issues; treat them as load-bearing:
42
431. **Productive work continues.** Agents that have a clear next action must keep working without needing the user to wake them. ([PAP-2674](/PAP/issues/PAP-2674), [PAP-2708](/PAP/issues/PAP-2708))
442. **Only real blockers stop work.** Stops happen when something genuinely cannot proceed (missing approval, missing dependency, human owner). Pseudo-stops (in_review with no action path, cancelled leaves, malformed metadata) must be detected and routed, not left silent. ([PAP-2335](/PAP/issues/PAP-2335), [PAP-2674](/PAP/issues/PAP-2674))
453. **No infinite loops.** Stranded-work recovery and continuation loops must be bounded and distinguishable from genuinely productive continuation. ([PAP-2602](/PAP/issues/PAP-2602), [PAP-2486](/PAP/issues/PAP-2486))
46
47If a proposed rule violates any of the three, drop it or rework it. State explicitly in the plan how each invariant is held.
48
49## Procedure
50
51### 0. Read the current execution contract
52
53Before walking the tree, read doc/execution-semantics.md and keep its terms intact:
54
55- live path / waiting path / recovery path
56- post-run disposition: terminal, explicitly live, explicitly waiting, invalid
57- bounded run_liveness_continuation
58- productivity review vs liveness recovery
59- active subtree pause holds
60- silent active-run watchdog
61
62Do not invent a new rule until you can state how it differs from the current execution semantics document.
63
64### 1. Forensics on the named tree — before anything else
65
66Do this in the same heartbeat. Do not propose a rule until you have a concrete stop point.
67
68- Open the linked issue (and its blocker chain, parents, recovery siblings, recent runs).
69- Walk the tree node-by-node and find the exact issue + state combination that stops the world. Common shapes seen in the company so far:
70 - in_review with no typed execution participant, no active run, no pending interaction, no recovery issue ([PAP-2335](/PAP/issues/PAP-2335), [PAP-2674](/PAP/issues/PAP-2674)).
71 - in_progress after a successful run with no future action path queued ([PAP-2674](/PAP/issues/PAP-2674)).
72 - Blocker chain whose leaf is cancelled / malformed / cross-company-inaccessible ([PAP-2602](/PAP/issues/PAP-2602)).
73 - issue.continuation_recovery waking the same issue >N times after successful runs ([PAP-2602](/PAP/issues/PAP-2602)).
74 - Stranded-work recovery treating its own recovery issues as more recoverable source work ([PAP-2486](/PAP/issues/PAP-2486)).
75- Quote the evidence: run ids, comment timestamps, status transitions. "Inferred" is acceptable only when an API boundary blocks direct evidence — say so explicitly and mark the claim provisional ([PAP-2631](/PAP/issues/PAP-2631)).
76
77Respect the API boundary. If the linked issue is in another company and your agent token returns 403, do not bypass scoping. Either request a board-approved diagnostic path or proceed from inferred PAP-side evidence and label it.
78
79### 2. Survey recent related work
80
81Before proposing a new product rule, read what already shipped this week in the same area. The user has explicitly called this out: ([PAP-2602](/PAP/issues/PAP-2602)) "review our recent work on liveness that we shipped in the last couple of days." A new rule that contradicts code merged 48 hours ago is rework, not improvement.
82
83Quick survey:
84- Recent merged PRs in the affected area.
85- Recent done issues whose title mentions liveness, recovery, productivity, continuation, or the affected subsystem.
86- Any active plan documents on parent issues. The fix may belong as a revision to an existing plan, not as a new top-level proposal.
87
88State in the forensics: "I reviewed X, Y, Z. The new gap is …"
89
90### 3. Classify each non-progressing issue in the tree
91
92For every issue in the affected tree that is not done / cancelled / actively running, decide:
93
94- **Truly needs human or board intervention** — name the owner and the action.
95- **Agent-actionable but not currently routed** — name the rule that would have routed it, and the agent that should have been waked.
96- **Already covered** — point at the active run, queued wake, recovery issue, or pending interaction.
97
98This is the table the user has asked for repeatedly ([PAP-2335](/PAP/issues/PAP-2335)). Without it the plan is abstract.
99
100### 4. Frame as a general product rule
101
102The user does not want a one-off patch on the named tree. They want the rule. Two checks:
103
104- The rule is **stated as a contract**, not as an if/else patch. Example contract: "every agent-owned non-terminal issue must finish each heartbeat with a terminal state, an explicit waiting path, or an explicit live path" ([PAP-2674](/PAP/issues/PAP-2674)).
105- The rule is reconciled against doc/execution-semantics.md. Prefer citing and applying the existing contract; propose a document change only when the current doc is incomplete or contradicted by accepted/implemented behavior.
106- The rule **explicitly preserves the three invariants** above. Show the work.
107
108If the rule would have blocked a recent productive run from succeeding, drop or narrow it.
109
110### 5. Plan, do not code
111
112Write the plan into the issue's plan document. Cover:
113
114- Forensics summary (root cause + evidence).
115- The general product rule, stated as a contract.
116- Whether the existing doc/execution-semantics.md contract already covers the case, or what exact documentation update is needed.
117- Phased subtasks: typically Phase 0 resolves the named live tree (carefully, not destructively), Phase 1 codifies the contract in docs, then implementation phases for detection, recovery, UI surfacing, security review, QA, and CTO review.
118- Explicit assignees per phase; favor team specialty (CodexCoder for server, ClaudeCoder for FE, UXDesigner for visible state, SecurityEngineer for ownership/permissions, QA for validation).
119- Blocking dependencies wired with blockedByIssueIds, parallel branches identified.
120
121Do not create the child issues yet. Do not push code.
122
123### 6. Request approval, then decompose
124
125- Open a request_confirmation interaction targeting the latest plan revision. Idempotency key confirmation:{issueId}:plan:{revisionId}.
126- Wait for board/CTO acceptance. If the user posts a new comment that supersedes the plan, the prior confirmation is invalidated — open a fresh confirmation tied to the new revision ([PAP-2602](/PAP/issues/PAP-2602) cycled three revisions; that is fine).
127- Only after acceptance: create the phased child issues with the right assignees and dependencies, then block this parent on the final QA / CTO review issue so the parent only wakes when the chain finishes.
128
129### 7. Phase 0 hygiene on the named tree
130
131Phase 0 cleans up the live tree without papering over evidence:
132
133- Move stalled in_review leaves with no participant to todo with a precise next action and named owner ([PAP-2335](/PAP/issues/PAP-2335)).
134- Detach cancelled/dead blockers from chains they were holding hostage; do not silently mark issues done to clear backlog.
135- Leave a comment on the original named issue summarizing what changed and why; never hide the recovery chain history.
136
137### 8. Final close-out
138
139When the phase chain is complete, post a board-level summary comment on the parent issue: what changed, what the new contract is, what the rollout step is (e.g. "restart the control-plane to pick up the new response shape"), and the live state of the originally-named tree. Then close the parent.
140
141## Pitfalls
142
143- **Coding before approval.** The user has said "make a plan first" on every recent diagnostic issue. Producing code in the forensic phase wastes the round-trip.
144- **Restating one invariant at the cost of another.** Bound continuation too tightly and productive work stalls; loosen recovery and infinite loops return. Always check all three.
145- **Skipping the recent-work survey.** Proposing a contract that contradicts what shipped 24 hours ago is the easiest way to get the plan rejected.
146- **Letting "in_review" mean done.** A leaf assigned to another agent with no participant or active run is not progress; treat it as a stop.
147- **Bypassing company scoping.** Cross-company forensics needs a board-approved diagnostic path, not a database read.
148- **Recursive recovery.** Stranded-work recovery that recovers its own recovery issues is the canonical infinite loop ([PAP-2486](/PAP/issues/PAP-2486)). Detect it and refuse to deepen.
149- **Hiding the chain.** Don't silently delete or hide the symptomatic recovery issues — the operator needs the audit trail.
150
151## Verification checklist (before posting the plan)
152
153- [ ] The exact stop point in the named tree is identified with run ids / comment ids.
154- [ ] Recent shipped work in the same area was surveyed and is referenced.
155- [ ] Every non-progressing issue is classified human-needed / agent-actionable / already-covered.
156- [ ] The proposed rule is stated as a contract, not a patch.
157- [ ] All three invariants are explicitly preserved.
158- [ ] No code change has landed in this heartbeat.
159- [ ] A request_confirmation against the latest plan revision is open.
160- [ ] Phase 0 of the plan addresses the live named tree without destroying evidence.
161- [ ] Implementation phases name specialty-appropriate assignees and blockedByIssueIds dependencies.
162
In the file
SKILL.md1,766 words
Files1
LicenceMIT
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈140
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
2,785
on trigger
The instruction body, read only when the skill fires.
1.5%
of a 200k window
Ten skills this size would take about 15% of the window before you open a file.
050k100k150k200k context window

2.9k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 11.7 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md11.7 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Diagnose Why Work Stopped · 2.9k tokens when loaded npx mcprush@latest skill add paperclipai/diagnose-why-work-stopped

Writes to .claude/skills/diagnose-why-work-stopped/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencepaperclipai/diagnose-why-work-stopped

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

PA
paperclipai

Publishes on mcprush.

0 servers listed1 skill listednot claimed
Profile
Publisher
Servers0
Claim this skill