[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BXB3J5S5YYJ7CPYV14XAX":3,"skill-same:01M69BXB3J5S5YYJ7CPYV14XAX":52},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":51},"01M69BXB3J5S5YYJ7CPYV14XAX","diagnose-why-work-stopped",null,"How to handle \"why did this work stop \u002F 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\u002FCTO 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.","microsoft\u002Famplifier-app-paperclip","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BVQW2AS8MMMYW9A4DSSHW",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-why-work-stopped\u002FSKILL.md",[],[19,20,21,22,23],"diagnose","diagnose why work stopped","code","issues","product","2026-11-10 10:12:30",false,"---\nname: diagnose-why-work-stopped\ndescription: >\n  How to handle \"why did this work stop \u002F why is this looping?\" assignments.\n  Forensics first on the named tree, surface the exact stop-point, frame the\n  fix as a general product rule that respects three invariants (productive\n  work continues, only real blockers stop work, no infinite loops), and\n  deliver a plan — no code changes — gated by board\u002FCTO approval before\n  child issues are created. Use whenever the issue title or body asks for\n  forensics on a stalled, looping, or \"went too deep\" tree.\n---\n\n# Diagnose Why Work Stopped\n\nA repeatable procedure for the recurring class of issues where the user (or a manager) points at a stalled \u002F looping \u002F over-recovered issue tree and asks \"why did this stop \u002F why is this looping \u002F how do we make sure this doesn't happen again?\"\n\nThis skill is **diagnostic + product-design**, not engineering. The output is a written root cause and an approved plan. No code changes leave this skill.\n\nCanonical execution model: read `doc\u002Fexecution-semantics.md` before diagnosing or proposing a new liveness\u002Frecovery 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\u002Fexecution-semantics.md` needs a matching update.\n\n## When to use\n\nTrigger on an assignment whose title or body matches any of:\n\n- \"why did this work stop\", \"why did this stall\", \"why did this just stop\"\n- \"infinite loop\", \"looping\", \"spinning\", \"going too deep\", \"recovery went too deep\"\n- \"liveness — what happened here\", \"this tree stopped working\", \"stuck\"\n- \"approach it from a product perspective\", \"general product principle \u002F rule\"\n- An attached link to a specific stalled \u002F looping \u002F over-recovered issue tree\n\nAlso use when the user asks for forensics, root cause, or a write-up *before* any product change.\n\n## When NOT to use\n\n- The assignment asks you to ship a code change directly. Use normal engineering flow.\n- The assignment is a normal bug report against a specific feature. Use normal investigation.\n- You are the original implementer being asked to fix your own bug. Use normal debugging.\n\n## Three invariants you must preserve\n\nEvery 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:\n\n1. **Productive work continues.** Agents that have a clear next action must keep working without needing the user to wake them. ([PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674), [PAP-2708](\u002FPAP\u002Fissues\u002FPAP-2708))\n2. **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](\u002FPAP\u002Fissues\u002FPAP-2335), [PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674))\n3. **No infinite loops.** Stranded-work recovery and continuation loops must be bounded and distinguishable from genuinely productive continuation. ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-2602), [PAP-2486](\u002FPAP\u002Fissues\u002FPAP-2486))\n\nIf a proposed rule violates any of the three, drop it or rework it. State explicitly in the plan how each invariant is held.\n\n## Procedure\n\n### 0. Read the current execution contract\n\nBefore walking the tree, read `doc\u002Fexecution-semantics.md` and keep its terms intact:\n\n- live path \u002F waiting path \u002F recovery path\n- post-run disposition: terminal, explicitly live, explicitly waiting, invalid\n- bounded `run_liveness_continuation`\n- productivity review vs liveness recovery\n- active subtree pause holds\n- silent active-run watchdog\n\nDo not invent a new rule until you can state how it differs from the current execution semantics document.\n\n### 1. Forensics on the named tree — before anything else\n\nDo this in the same heartbeat. Do not propose a rule until you have a concrete stop point.\n\n- Open the linked issue (and its blocker chain, parents, recovery siblings, recent runs).\n- 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:\n  - `in_review` with no typed execution participant, no active run, no pending interaction, no recovery issue ([PAP-2335](\u002FPAP\u002Fissues\u002FPAP-2335), [PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674)).\n  - `in_progress` after a successful run with no future action path queued ([PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674)).\n  - Blocker chain whose leaf is `cancelled` \u002F malformed \u002F cross-company-inaccessible ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-2602)).\n  - `issue.continuation_recovery` waking the same issue >N times after successful runs ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-2602)).\n  - Stranded-work recovery treating its own recovery issues as more recoverable source work ([PAP-2486](\u002FPAP\u002Fissues\u002FPAP-2486)).\n- 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](\u002FPAP\u002Fissues\u002FPAP-2631)).\n\nRespect 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.\n\n### 2. Survey recent related work\n\nBefore proposing a new product rule, read what already shipped this week in the same area. The user has explicitly called this out: ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-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.\n\nQuick survey:\n- Recent merged PRs in the affected area.\n- Recent done issues whose title mentions liveness, recovery, productivity, continuation, or the affected subsystem.\n- 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.\n\nState in the forensics: \"I reviewed X, Y, Z. The new gap is …\"\n\n### 3. Classify each non-progressing issue in the tree\n\nFor every issue in the affected tree that is not `done` \u002F `cancelled` \u002F actively running, decide:\n\n- **Truly needs human or board intervention** — name the owner and the action.\n- **Agent-actionable but not currently routed** — name the rule that would have routed it, and the agent that should have been waked.\n- **Already covered** — point at the active run, queued wake, recovery issue, or pending interaction.\n\nThis is the table the user has asked for repeatedly ([PAP-2335](\u002FPAP\u002Fissues\u002FPAP-2335)). Without it the plan is abstract.\n\n### 4. Frame as a general product rule\n\nThe user does not want a one-off patch on the named tree. They want the rule. Two checks:\n\n- The rule is **stated as a contract**, not as an if\u002Felse 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](\u002FPAP\u002Fissues\u002FPAP-2674)).\n- The rule is reconciled against `doc\u002Fexecution-semantics.md`. Prefer citing and applying the existing contract; propose a document change only when the current doc is incomplete or contradicted by accepted\u002Fimplemented behavior.\n- The rule **explicitly preserves the three invariants** above. Show the work.\n\nIf the rule would have blocked a recent productive run from succeeding, drop or narrow it.\n\n### 5. Plan, do not code\n\nWrite the plan into the issue's `plan` document. Cover:\n\n- Forensics summary (root cause + evidence).\n- The general product rule, stated as a contract.\n- Whether the existing `doc\u002Fexecution-semantics.md` contract already covers the case, or what exact documentation update is needed.\n- 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.\n- Explicit assignees per phase; favor team specialty (CodexCoder for server, ClaudeCoder for FE, UXDesigner for visible state, SecurityEngineer for ownership\u002Fpermissions, QA for validation).\n- Blocking dependencies wired with `blockedByIssueIds`, parallel branches identified.\n\nDo not create the child issues yet. Do not push code.\n\n### 6. Request approval, then decompose\n\n- Open a `request_confirmation` interaction targeting the latest plan revision. Idempotency key `confirmation:{issueId}:plan:{revisionId}`.\n- Wait for board\u002FCTO 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](\u002FPAP\u002Fissues\u002FPAP-2602) cycled three revisions; that is fine).\n- Only after acceptance: create the phased child issues with the right assignees and dependencies, then block this parent on the final QA \u002F CTO review issue so the parent only wakes when the chain finishes.\n\n### 7. Phase 0 hygiene on the named tree\n\nPhase 0 cleans up the live tree without papering over evidence:\n\n- Move stalled `in_review` leaves with no participant to `todo` with a precise next action and named owner ([PAP-2335](\u002FPAP\u002Fissues\u002FPAP-2335)).\n- Detach cancelled\u002Fdead blockers from chains they were holding hostage; do not silently mark issues `done` to clear backlog.\n- Leave a comment on the original named issue summarizing what changed and why; never hide the recovery chain history.\n\n### 8. Final close-out\n\nWhen 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.\n\n## Pitfalls\n\n- **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.\n- **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.\n- **Skipping the recent-work survey.** Proposing a contract that contradicts what shipped 24 hours ago is the easiest way to get the plan rejected.\n- **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.\n- **Bypassing company scoping.** Cross-company forensics needs a board-approved diagnostic path, not a database read.\n- **Recursive recovery.** Stranded-work recovery that recovers its own recovery issues is the canonical infinite loop ([PAP-2486](\u002FPAP\u002Fissues\u002FPAP-2486)). Detect it and refuse to deepen.\n- **Hiding the chain.** Don't silently delete or hide the symptomatic recovery issues — the operator needs the audit trail.\n\n## Verification checklist (before posting the plan)\n\n- [ ] The exact stop point in the named tree is identified with run ids \u002F comment ids.\n- [ ] Recent shipped work in the same area was surveyed and is referenced.\n- [ ] Every non-progressing issue is classified human-needed \u002F agent-actionable \u002F already-covered.\n- [ ] The proposed rule is stated as a contract, not a patch.\n- [ ] All three invariants are explicitly preserved.\n- [ ] No code change has landed in this heartbeat.\n- [ ] A `request_confirmation` against the latest plan revision is open.\n- [ ] Phase 0 of the plan addresses the live named tree without destroying evidence.\n- [ ] Implementation phases name specialty-appropriate assignees and `blockedByIssueIds` dependencies.\n","# Diagnose Why Work Stopped\n\nA repeatable procedure for the recurring class of issues where the user (or a manager) points at a stalled \u002F looping \u002F over-recovered issue tree and asks \"why did this stop \u002F why is this looping \u002F how do we make sure this doesn't happen again?\"\n\nThis skill is **diagnostic + product-design**, not engineering. The output is a written root cause and an approved plan. No code changes leave this skill.\n\nCanonical execution model: read `doc\u002Fexecution-semantics.md` before diagnosing or proposing a new liveness\u002Frecovery 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\u002Fexecution-semantics.md` needs a matching update.\n\n## When to use\n\nTrigger on an assignment whose title or body matches any of:\n\n- \"why did this work stop\", \"why did this stall\", \"why did this just stop\"\n- \"infinite loop\", \"looping\", \"spinning\", \"going too deep\", \"recovery went too deep\"\n- \"liveness — what happened here\", \"this tree stopped working\", \"stuck\"\n- \"approach it from a product perspective\", \"general product principle \u002F rule\"\n- An attached link to a specific stalled \u002F looping \u002F over-recovered issue tree\n\nAlso use when the user asks for forensics, root cause, or a write-up *before* any product change.\n\n## When NOT to use\n\n- The assignment asks you to ship a code change directly. Use normal engineering flow.\n- The assignment is a normal bug report against a specific feature. Use normal investigation.\n- You are the original implementer being asked to fix your own bug. Use normal debugging.\n\n## Three invariants you must preserve\n\nEvery 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:\n\n1. **Productive work continues.** Agents that have a clear next action must keep working without needing the user to wake them. ([PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674), [PAP-2708](\u002FPAP\u002Fissues\u002FPAP-2708))\n2. **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](\u002FPAP\u002Fissues\u002FPAP-2335), [PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674))\n3. **No infinite loops.** Stranded-work recovery and continuation loops must be bounded and distinguishable from genuinely productive continuation. ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-2602), [PAP-2486](\u002FPAP\u002Fissues\u002FPAP-2486))\n\nIf a proposed rule violates any of the three, drop it or rework it. State explicitly in the plan how each invariant is held.\n\n## Procedure\n\n### 0. Read the current execution contract\n\nBefore walking the tree, read `doc\u002Fexecution-semantics.md` and keep its terms intact:\n\n- live path \u002F waiting path \u002F recovery path\n- post-run disposition: terminal, explicitly live, explicitly waiting, invalid\n- bounded `run_liveness_continuation`\n- productivity review vs liveness recovery\n- active subtree pause holds\n- silent active-run watchdog\n\nDo not invent a new rule until you can state how it differs from the current execution semantics document.\n\n### 1. Forensics on the named tree — before anything else\n\nDo this in the same heartbeat. Do not propose a rule until you have a concrete stop point.\n\n- Open the linked issue (and its blocker chain, parents, recovery siblings, recent runs).\n- 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:\n  - `in_review` with no typed execution participant, no active run, no pending interaction, no recovery issue ([PAP-2335](\u002FPAP\u002Fissues\u002FPAP-2335), [PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674)).\n  - `in_progress` after a successful run with no future action path queued ([PAP-2674](\u002FPAP\u002Fissues\u002FPAP-2674)).\n  - Blocker chain whose leaf is `cancelled` \u002F malformed \u002F cross-company-inaccessible ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-2602)).\n  - `issue.continuation_recovery` waking the same issue >N times after successful runs ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-2602)).\n  - Stranded-work recovery treating its own recovery issues as more recoverable source work ([PAP-2486](\u002FPAP\u002Fissues\u002FPAP-2486)).\n- 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](\u002FPAP\u002Fissues\u002FPAP-2631)).\n\nRespect 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.\n\n### 2. Survey recent related work\n\nBefore proposing a new product rule, read what already shipped this week in the same area. The user has explicitly called this out: ([PAP-2602](\u002FPAP\u002Fissues\u002FPAP-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.\n\nQuick survey:\n- Recent merged PRs in the affected area.\n- Recent done issues whose title mentions liveness, recovery, productivity, continuation, or the affected subsystem.\n- 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.\n\nState in the forensics: \"I reviewed X, Y, Z. The new gap is …\"\n\n### 3. Classify each non-progressing issue in the tree\n\nFor every issue in the affected tree that is not `done` \u002F `cancelled` \u002F actively running, decide:\n\n- **Truly needs human or board intervention** — name the owner and the action.\n- **Agent-actionable but not currently routed** — name the rule that would have routed it, and the agent that should have been waked.\n- **Already covered** — point at the active run, queued wake, recovery issue, or pending interaction.\n\nThis is the table the user has asked for repeatedly ([PAP-2335](\u002FPAP\u002Fissues\u002FPAP-2335)). Without it the plan is abstract.\n\n### 4. Frame as a general product rule\n\nThe user does not want a one-off patch on the named tree. They want the rule. Two checks:\n\n- The rule is **stated as a contract**, not as an if\u002Felse 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](\u002FPAP\u002Fissues\u002FPAP-2674)).\n- The rule is reconciled against `doc\u002Fexecution-semantics.md`. Prefer citing and applying the existing contract; propose a document change only when the current doc is incomplete or contradicted by accepted\u002Fimplemented behavior.\n- The rule **explicitly preserves the three invariants** above. Show the work.\n\nIf the rule would have blocked a recent productive run from succeeding, drop or narrow it.\n\n### 5. Plan, do not code\n\nWrite the plan into the issue's `plan` document. Cover:\n\n- Forensics summary (root cause + evidence).\n- The general product rule, stated as a contract.\n- Whether the existing `doc\u002Fexecution-semantics.md` contract already covers the case, or what exact documentation update is needed.\n- 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.\n- Explicit assignees per phase; favor team specialty (CodexCoder for server, ClaudeCoder for FE, UXDesigner for visible state, SecurityEngineer for ownership\u002Fpermissions, QA for validation).\n- Blocking dependencies wired with `blockedByIssueIds`, parallel branches identified.\n\nDo not create the child issues yet. Do not push code.\n\n### 6. Request approval, then decompose\n\n- Open a `request_confirmation` interaction targeting the latest plan revision. Idempotency key `confirmation:{issueId}:plan:{revisionId}`.\n- Wait for board\u002FCTO 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](\u002FPAP\u002Fissues\u002FPAP-2602) cycled three revisions; that is fine).\n- Only after acceptance: create the phased child issues with the right assignees and dependencies, then block this parent on the final QA \u002F CTO review issue so the parent only wakes when the chain finishes.\n\n### 7. Phase 0 hygiene on the named tree\n\nPhase 0 cleans up the live tree without papering over evidence:\n\n- Move stalled `in_review` leaves with no participant to `todo` with a precise next action and named owner ([PAP-2335](\u002FPAP\u002Fissues\u002FPAP-2335)).\n- Detach cancelled\u002Fdead blockers from chains they were holding hostage; do not silently mark issues `done` to clear backlog.\n- Leave a comment on the original named issue summarizing what changed and why; never hide the recovery chain history.\n\n### 8. Final close-out\n\nWhen 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.\n\n## Pitfalls\n\n- **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.\n- **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.\n- **Skipping the recent-work survey.** Proposing a contract that contradicts what shipped 24 hours ago is the easiest way to get the plan rejected.\n- **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.\n- **Bypassing company scoping.** Cross-company forensics needs a board-approved diagnostic path, not a database read.\n- **Recursive recovery.** Stranded-work recovery that recovers its own recovery issues is the canonical infinite loop ([PAP-2486](\u002FPAP\u002Fissues\u002FPAP-2486)). Detect it and refuse to deepen.\n- **Hiding the chain.** Don't silently delete or hide the symptomatic recovery issues — the operator needs the audit trail.\n\n## Verification checklist (before posting the plan)\n\n- [ ] The exact stop point in the named tree is identified with run ids \u002F comment ids.\n- [ ] Recent shipped work in the same area was surveyed and is referenced.\n- [ ] Every non-progressing issue is classified human-needed \u002F agent-actionable \u002F already-covered.\n- [ ] The proposed rule is stated as a contract, not a patch.\n- [ ] All three invariants are explicitly preserved.\n- [ ] No code change has landed in this heartbeat.\n- [ ] A `request_confirmation` against the latest plan revision is open.\n- [ ] Phase 0 of the plan addresses the live named tree without destroying evidence.\n- [ ] Implementation phases name specialty-appropriate assignees and `blockedByIssueIds` dependencies.\n",{"name":5,"description":7},"main","d1d0e5a045f856af95eb693add053cc329774806","skills\u002Fdiagnose-why-work-stopped",2,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-30 04:25:15",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add microsoft\u002Famplifier-app-paperclip --skill diagnose-why-work-stopped",{"tool":44,"command":45},"bunx","bunx skills add microsoft\u002Famplifier-app-paperclip --skill diagnose-why-work-stopped",{"tool":47,"command":48},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-app-paperclip --skill diagnose-why-work-stopped","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-why-work-stopped\u002FSKILL.md",true,[],[53,66,81,92,101,115],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":24},"01M69BXXE3997X52Z13XH9ZCK4","terminal-bench-loop","Run a single Terminal-Bench problem through Paperclip in a bounded, human-in-the-loop improvement cycle until the smoke passes, the board rejects the next fix, the iteration budget is exhausted, or a real blocker is named. Each iteration runs a bounded smoke against an isolated Paperclip App worktree, captures artifacts, diagnoses the exact stop point with `\u002Fdiagnose-why-work-stopped`, requests board confirmation before any product fix, then reruns against the same worktree. Use whenever an issue asks to \"run Terminal-Bench in a loop\", \"drive Terminal-Bench until it passes\", \"loop fix-git through Paperclip\", or otherwise points at a Terminal-Bench task and asks for bounded iteration with diagnosis.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fterminal-bench-loop\u002FSKILL.md",[],[60,61,62,63,64,19,65,23],"terminal bench loop","terminal","git","artifacts","paperclip","run",{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":24},"01M69BXV7WMFG9YEPBB50Q40JY","para-memory-files","File-based memory system using Tiago Forte's PARA method. Use this skill whenever you need to store, retrieve, update, or organize knowledge across sessions. Covers three memory layers: (1) Knowledge graph in PARA folders with atomic YAML facts, (2) Daily notes as raw timeline, (3) Tacit knowledge about user patterns. Also handles planning files, memory decay, weekly synthesis, and recall via qmd. Trigger on any memory operation: saving facts, writing daily notes, creating entities, running weekly synthesis, recalling past context, or managing plans.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fpara-memory-files\u002FSKILL.md",[],[73,74,75,76,77,78,79,80],"memory","para memory files","planning","update","notes","sessions","qmd","writing",{"skillNo":82,"name":64,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":24},"01M69BXRE769BJ5W05W2XQ85T6","Interact with the Paperclip control plane API to manage tasks, coordinate with other agents, and follow company governance. Use when you need to check assignments, update task status, delegate work, post comments, set up or manage routines (recurring scheduled tasks), or call any Paperclip API endpoint. Do NOT use for the actual domain work itself (writing code, research, etc.) — only for Paperclip coordination.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip\u002FSKILL.md",[],[64,87,21,76,88,89,90,91,80],"status","tasks","governance","research","routines",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":24},"01M69BXMREYNEVHE276GFTMFBZ","paperclip-dev","Develop and operate a local Paperclip instance — start and stop servers, pull updates from master, run builds and tests, manage worktrees, back up databases, and diagnose problems. Use whenever you need to work on the Paperclip codebase itself or keep a running instance healthy.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-dev\u002FSKILL.md",[],[99,64,100,65,19],"paperclip dev","dev",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":24},"01M69BXHSPWG60R76MMXJCBRG2","paperclip-create-plugin","Create and develop external Paperclip plugins with the CLI-first workflow. Use when scaffolding a new plugin, working on a local plugin against a running Paperclip instance, or updating plugin authoring docs. Covers `paperclipai plugin init`, the local install loop via `paperclipai plugin install \u003Cpath>`, worker\u002FUI rebuild and reload semantics, and the required success checklist.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-create-plugin\u002FSKILL.md",[],[108,64,109,110,111,112,113,114],"paperclip create plugin","plugin","create","init","workflow","docs","cli",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":24},"01M69BXF0D8J59MN3MF30F6NGW","paperclip-create-agent","Create new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt\u002Fconfig, and submit a hire request.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-paperclip\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-create-agent\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[127,110,64,128,89,129],"create agent","paperclip create agent","config"]