agentleFS
synaptiaisynaptiai/agent-capability-standard/skills/debug-workflow/SKILL.md

debug-workflow

Skill6 starsChanged 13 days agoApache-2.0View on GitHub

Execute the Debug Code Change workflow end-to-end with safety gates. Use when debugging code changes, investigating issues, or performing root cause analysis with audit trail.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 6 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run the composed workflow debug_code_change (reference/workflow_catalog.yaml) using atomic capability skills to diagnose and fix a bug with …

    line 14
  2. Distinctive:

    Every step output is grounded with evidence anchors

    line 17
  3. Distinctive:

    All issues are traced to root cause with supporting evidence

    line 19
  4. Distinctive:

    Create checkpoint marker: if mutation might occur:

    line 35
  5. Very specific:

    Create .claude/checkpoint.ok after confirming rollback strategy

    line 36
  6. Very specific:

    If the fix command fails or times out (R401/R402), roll back to checkpoint_out and end the run with that error

    line 62
  7. Distinctive:

    Run targeted verification: tests pass, the symptom is resolved, and public interfaces are unchanged

    line 65
  8. Very specific:

    If verification cannot run (R401/R402 after its retries), roll back to checkpoint_out and end the run with that error

    line 67
  9. Very specific:

    NEVER proceed to execute without checkpoint and explicit plan

    line 276
  10. Distinctive:

    STOP and request clarification if any step produces confidence < 0.3

    line 277
  11. Distinctive:

    ALWAYS verify fix before marking workflow complete

    line 278
  12. Very specific:

    Never skip /observe to jump directly to /plan

    line 293
  13. Very specific:

    Never proceed past /critique without addressing identified weaknesses

    line 294
  14. Very specific:

    Never run /execute without prior /checkpoint

    line 295
  15. Very specific:

    Never mark complete without /verify confirmation

    line 296

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Intent

Run the composed workflow debug_code_change (reference/workflow_catalog.yaml) using atomic capability skills to diagnose and fix a bug with full safety and audit capabilities.

Success criteria:

  • Every step output is grounded with evidence anchors
  • Safety gates are respected (checkpoint before any mutation)
  • All issues are traced to root cause with supporting evidence
  • Final result includes complete audit trail
  • Rollback runs only when verification fails

Compatible schemas:

  • reference/workflow_catalog.yaml

Inputs

ParameterRequiredTypeDescription
bugYesobjectThe failure to diagnose and fix: component (where it is), symptom (what goes wrong), fix_command (the command that applies and tests the fix)
user_inputNoobjectdomain and constraints (e.g. time budget, files to exclude)

Procedure

  1. Create checkpoint marker if mutation might occur:
    • Create .claude/checkpoint.ok after confirming rollback strategy
  2. Invoke /observe on bug.component and store output as observe_out
    • Observe failing behavior, logs, and relevant code paths
  3. Invoke /search for bug.symptom and store output as search_out
    • Find related code, configs, and error patterns
  4. Invoke /attribute with bug.symptom as the effect and store output as attribute_out
    • Build the dependency graph and identify causal relationships around the failing component
  5. Invoke /constrain on bug.component and store output as constrain_out
    • Define the invariants the fix must keep (existing tests pass, public interfaces unchanged)
  6. Invoke /critique on attribute_out.causes and store output as critique_out
    • List likely failure modes and edge cases
  7. Invoke /plan with user_input.constraints, and the observation, related code, causes and critique (critique_out.issues, critique_out.suggestions) as context, and store output as plan_out
    • Produce a minimal fix plan with checkpoints
  8. Invoke /checkpoint on bug.component and store output as checkpoint_out
    • Save a restore point before mutation
  9. Invoke /execute with bug.fix_command and store output as execute_out
    • Apply the fix, run tests, and produce a diff summary
    • Skip this step when plan_out.steps is empty: no fix is applied, and the run goes on to the audit
    • If the fix command fails or times out (R401/R402), roll back to checkpoint_out and end the run with that error
  10. Invoke /verify on the component and execute_out, and store output as verify_out
    • Run targeted verification: tests pass, the symptom is resolved, and public interfaces are unchanged
    • Skip this step when the fix was not applied (execute_out is null)
    • If verification cannot run (R401/R402 after its retries), roll back to checkpoint_out and end the run with that error
  11. Invoke /rollback to checkpoint_out.checkpoint_id if verify_out.passed is false, and store output as rollback_out
    • The step is skipped when no fix was applied or verification passes
    • The step does not take a checkpoint of its own (requires_checkpoint: false): it restores the one taken at step 7, which the fix consumed
  12. Invoke /audit and store output as audit_out
    • Record what changed and why: the component, the causes, the plan, the exit code, the verdict, and whether it was rolled back (rollback_out.restored; null when the rollback was skipped)

Output Contract

Return a structured object:

workflow_id: string  # Unique workflow execution ID
bug: object  # The bug as given
status: completed | failed | rolled_back
steps:
  observe_out:
    observation: object
    evidence_anchors: array[string]
  search_out:
    results: array[object]
    evidence_anchors: array[string]
  attribute_out:
    causes: array[object]
    strengths: object  # Causal strength per cause
    evidence_anchors: array[string]
  constrain_out:
    compliant: boolean
    violations: array[object]
    evidence_anchors: array[string]
  critique_out:
    issues: array[object]
    evidence_anchors: array[string]
  plan_out:
    steps: array[object]
    risks: array[object]
    evidence_anchors: array[string]
  checkpoint_out:
    checkpoint_id: string
    evidence_anchors: array[string]
  execute_out:
    result: any
    evidence_anchors: array[string]
  verify_out:
    passed: boolean
    violations: array[object]
    evidence_anchors: array[string]
  rollback_out:  # null when no fix was applied or verification passed (the step was skipped)
    restored: boolean
    evidence_anchors: array[string]
  audit_out:
    audit_id: string
    recorded: boolean
    evidence_anchors: array[string]
root_cause:
  description: string
  evidence_anchors: array[string]
resolution:
  description: string
  files_changed: array[string]
verification: PASS | FAIL
audit_log_pointer: string  # Where the audit step appended its record (.claude/audit/records.jsonl)
confidence: number  # 0.0-1.0
evidence_anchors: array[string]
assumptions: array[string]

Field Definitions

FieldTypeDescription
workflow_idstringUnique identifier for this workflow execution
statusenumFinal workflow status
stepsobjectEach step's output, keyed by its store_as
root_causeobjectIdentified root cause with evidence
resolutionobjectWhat was done to fix the issue
verificationenumFinal PASS/FAIL after fix applied
confidencenumber0.0-1.0 based on evidence quality
evidence_anchorsarrayAll evidence references collected
assumptionsarrayExplicit assumptions made during debugging

Examples

Example 1: Debug Failing Test After Refactor

Input:

bug:
  component: "src/api/handlers/auth.py"
  symptom: "test_login_success fails with 401 after the handler refactor"
  fix_command: "git apply fix.patch && pytest tests/test_auth.py"
user_input:
  constraints:
    max_time: "30m"

Output:

workflow_id: "debug_20240115_143022"
bug:
  component: "src/api/handlers/auth.py"
  symptom: "test_login_success fails with 401 after the handler refactor"
  fix_command: "git apply fix.patch && pytest tests/test_auth.py"
status: completed
steps:
  observe_out:
    observation:
      failing_test: "tests/test_auth.py::test_login_success"
      expected_status: 200
      actual_status: 401
    evidence_anchors:
      - "file:tests/test_auth.py:45"
      - "file:src/api/handlers/auth.py:78"
  search_out:
    results:
      - location: "src/api/handlers/auth.py:validate_token"
      - location: "src/utils/jwt.py:decode_token"
    evidence_anchors:
      - "tool:grep:validate_token"
  attribute_out:
    causes:
      - id: signature_after_expiry
        cause: "Signature check moved after the expiry check"
    strengths:
      signature_after_expiry: 0.9
    evidence_anchors:
      - "tool:git:blame"
  constrain_out:
    compliant: true
    violations: []
    evidence_anchors: []
  critique_out:
    issues:
      - issue: "Signature validation after the expiry check rejects valid tokens"
        location: "src/api/handlers/auth.py:78-85"
    evidence_anchors:
      - "file:src/api/handlers/auth.py:78-85"
  plan_out:
    steps:
      - action: "Move the signature check before the expiry check"
        verification: "test_login_success passes; no other auth test regresses"
    risks: []
    evidence_anchors:
      - "file:src/api/handlers/auth.py:78"
  checkpoint_out:
    checkpoint_id: "chk_20240115_143000"
    evidence_anchors:
      - "tool:git:stash"
  execute_out:
    result: "patch applied; 12 passed"
    evidence_anchors:
      - "tool:bash:git apply fix.patch && pytest tests/test_auth.py"
  verify_out:
    passed: true
    violations: []
    evidence_anchors:
      - "tool:bash:pytest tests/test_auth.py"
  rollback_out: null  # skipped: verification passed
  audit_out:
    audit_id: "audit_20240115_143500"
    recorded: true
    evidence_anchors:
      - "file:.claude/audit/records.jsonl"
root_cause:
  description: "Token signature validation was moved after expiry check during refactor, causing valid tokens to be rejected before signature verification"
  evidence_anchors:
    - "file:src/api/handlers/auth.py:78-85"
    - "tool:git:blame"
resolution:
  description: "Restored original validation order: signature check before expiry check"
  files_changed:
    - "src/api/handlers/auth.py"
verification: PASS
audit_log_pointer: ".claude/audit/records.jsonl"
confidence: 0.95
evidence_anchors:
  - "file:tests/test_auth.py:45"
  - "file:src/api/handlers/auth.py:78-85"
  - "tool:bash:pytest"
  - "tool:git:diff"
assumptions:
  - "Test environment matches production configuration"
  - "No concurrent changes to auth module"

Evidence pattern: Combined code inspection, git blame for change attribution, test execution for verification.

Verification

  • Step Completeness: All 11 workflow steps executed with output (execute and verify skipped when the plan had no steps; rollback skipped when nothing was applied or verification passed)
  • Evidence Grounding: Every step output includes evidence_anchors
  • Checkpoint Created: Mutation steps preceded by checkpoint
  • Root Cause Identified: root_cause has specific description and evidence
  • Verification Passed: verify_out.passed is true before completion
  • Audit Trail: audit_log_pointer points to valid log file
  • Rollback Ready: checkpoint_out.checkpoint_id recorded before the fix ran

Verification tools: Bash (for test execution), Git (for change verification), Read (for audit log)

Safety Constraints

  • mutation: true
  • requires_checkpoint: true
  • requires_approval: true (the execute step that applies the fix)
  • risk: high

Capability-specific rules:

  • NEVER proceed to execute without checkpoint and explicit plan
  • STOP and request clarification if any step produces confidence < 0.3
  • ALWAYS verify fix before marking workflow complete
  • Record the checkpoint before any mutation
  • Preserve original error state for comparison

Composition Patterns

Commonly follows:

  • receive - After receiving bug report or error notification
  • retrieve - After fetching relevant context or logs

Commonly precedes:

  • explain - To create debug report for stakeholders
  • send - To notify team of resolution

Anti-patterns:

  • Never skip /observe to jump directly to /plan
  • Never proceed past /critique without addressing identified weaknesses
  • Never run /execute without prior /checkpoint
  • Never mark complete without /verify confirmation

Workflow references:

  • See reference/workflow_catalog.yaml#debug_code_change for step definitions
  • See reference/composition_patterns.md#checkpoint-act-verify-rollback for CAVR pattern

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.