Claude Skill

teamwork-debug

Use when a failure, regression, crash, flake, or unexpected result has an unknown cause that must be diagnosed before a safe fix; do not use when the cause and narrow fix are already clear.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download jinplu-teamwork-skills_teamwork-debug-8f23dcd.zip · 2 KB

jinplu/teamwork 12 0 forks MIT Updated 9d ago

Part of jinplu/teamwork — 8 skills

Install

skills CLI npx skills add https://github.com/JinPLu/Teamwork/tree/main/skills/teamwork-debug

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jinplu-teamwork@llmmart

Git git clone https://github.com/JinPLu/Teamwork.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jinplu/teamwork collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Teamwork Debug

Diagnose from the observed failure, not from a preset ceremony. Read references/runtime-diagnosis.md for the detailed evidence and document semantics.

Method

Reproduce or directly inspect the failure and bound the first bad behavior.
Form only hypotheses supported by evidence. One hypothesis is enough when a direct observation isolates the cause.
Run the smallest observation that distinguishes the live alternatives. For a runtime unknown, use structured logging first when it is that discriminator; keep non-runtime or already-isolated failures probe-minimal.
Locate the first bad owned boundary and state the supported cause.
If the user authorized a fix, make the smallest complete repair and verify the same failing path. Remove temporary instrumentation.
If evidence reveals a different failure, split it explicitly instead of silently changing scope.

freeze observe, instrument, and fix permission in any diagnosis brief. Diagnosis must not silently expand repair authority.

Do not guess a fix or retain temporary diagnostics.

Persistence

When a listed checkpoint fires, write in the same response cycle. If separate stable identities each cross a checkpoint, write each to its own path.

Cross-chat memory lives in one Markdown document from references/debug.md at docs/teamwork/debug/<slug>.md. Same identity means the same failure signature; reuse that path and name the document you read. A different subject gets a new path.

Checkpoints: a cause is confirmed; an authorized fix is verified on the same path; the case is blocked with a durable next discriminator; or evidence splits a new failure with its own identity.

Files (teamwork)

agents

openai.yaml 226 B

interface:
  display_name: "Teamwork Debug"
  short_description: "Diagnose unknown failures with causal evidence"
  default_prompt: "Use $teamwork-debug to diagnose this failure from evidence and verify the supported result."

references

debug.md 1.4 KB

---
status: active
superseded-by:
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
---

# Diagnosis: <failure signature>

## Identity and boundaries

- Failure signature: <symptom, trigger, environment/version>
- Authoritative owner: <diagnosis owner>
- Failure boundary: <expected/observed first divergence>
- Success signal: <directly observable result>

## Current diagnosis

<owner-certified synthesis; cause remains unconfirmed until isolated>

## Hypotheses

| Hypothesis | Standing | Discriminator | Evidence |
| --- | --- | --- | --- |
| <hypothesis> | <live/supported/weakened/rejected/superseded> | <distinguishing observation> | <direct evidence> |

## Observations

### <observation>

- Expected discriminating branches: <predicted alternatives>
- Raw result: <unaltered observation>
- Owner interpretation: <certified interpretation>

## Cause and owned boundary

<confirmed cause only after alternatives are distinguished and first bad owned boundary is located>

## Authorized repair and verification

- Authorization: <observe, instrument, and/or fix, as frozen in the brief>
- Repair: <exact change>
- Same-path verification: <observed result against success signal>
- Probe cleanup: <removed temporary diagnostics>

## History

<Append only. Never rewrite or remove; a correction is a new dated entry.>

### <date/time — semantic change>

<hypothesis, cause, repair, or verification delta>

runtime-diagnosis.md 411 B

# Runtime Diagnosis

Hypothesis standing is `live`, `supported`, `weakened`, `rejected`, or
`superseded`. Size follows live alternatives, not a quota. Retain the
discriminator for every standing change.

Keep three observation parts separate: the expected discriminating branch, the
raw result, and the diagnosis owner's interpretation. Writer may preserve those
statements but never supply the interpretation.

SKILL.md 1.9 KB

---
name: teamwork-debug
description: Use when a failure, regression, crash, flake, or unexpected result has an unknown cause that must be diagnosed before a safe fix; do not use when the cause and narrow fix are already clear.
---

# Teamwork Debug

Diagnose from the observed failure, not from a preset ceremony.
Read `references/runtime-diagnosis.md` for the detailed evidence and document
semantics.

## Method

1. Reproduce or directly inspect the failure and bound the first bad behavior.
2. Form only hypotheses supported by evidence. One hypothesis is enough when a
   direct observation isolates the cause.
3. Run the smallest observation that distinguishes the live alternatives. For a
   runtime unknown, use structured logging first when it is that discriminator;
   keep non-runtime or already-isolated failures probe-minimal.
4. Locate the first bad owned boundary and state the supported cause.
5. If the user authorized a fix, make the smallest complete repair and verify the
   same failing path. Remove temporary instrumentation.
6. If evidence reveals a different failure, split it explicitly instead of
   silently changing scope.

freeze observe, instrument, and fix permission in any diagnosis brief.
Diagnosis must not silently expand repair authority.

Do not guess a fix or retain temporary diagnostics.

## Persistence

When a listed checkpoint fires, write in the same response cycle. If separate
stable identities each cross a checkpoint, write each to its own path.

Cross-chat memory lives in one Markdown document from `references/debug.md`
at `docs/teamwork/debug/<slug>.md`. Same identity means the same
failure signature; reuse that path and name the document you read. A different
subject gets a new path.

Checkpoints: a cause is confirmed; an authorized fix is verified on the same
path; the case is blocked with a durable next discriminator; or evidence splits
a new failure with its own identity.