agh-cleanup-failure-paths

Audit Go functions for partial-failure cleanup across all error returns.

182|8|Updated Apr 4, 2026
One-click install
npx skills add https://github.com/compozy/agh --skill agh-cleanup-failure-paths
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: agh-cleanup-failure-paths
Source: https://github.com/compozy/agh/tree/main/.agents/skills/agh/agh-cleanup-failure-paths
Command: npx skills add https://github.com/compozy/agh --skill agh-cleanup-failure-paths

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents resource leaks and cleanup regressions when editing multi-step Go functions that create contexts, claims, leases, registry entries, subprocesses, and HTTP calls across multiple error returns.

Core Features & Use Cases

  • Audits cleanup discipline across every error return in complex functions, ensuring each allocated resource has the correct cancel/close/release/stop behavior.
  • Enforces deterministic cleanup patterns like defer-adjacent rules for context cancelation, Close/Rollback pairings, subprocess stopping, and HTTP response draining.
  • Protects production HTTP hygiene by forbidding http.DefaultClient in production execution paths and requiring drained response bodies.
  • Supports failure-path regression testing by guiding how to trigger specific partial-failure scenarios and assert cleanup actually occurred.

Quick Start

Activate this skill while editing an AGH function that performs multi-step setup or teardown (especially in internal/session, internal/scheduler, internal/coordinator, internal/extension, internal/automation, internal/store, internal/memory, internal/api, or subprocess/registry handlers) to systematically verify every error return cleans up contexts, claims/leases, subprocesses, and HTTP bodies.

Frequently Asked Questions about agh-cleanup-failure-paths

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent resource leaks in Go functions with multiple error returns?

Prevent Go resource leaks by auditing every multi-step allocation across all error returns, ensuring each context, lease, subprocess, and HTTP body has paired defer-adjacent cleanup logic. This stops leaks on every partial failure.

Why does my Go subprocess leak when an earlier HTTP call fails?

Go subprocess leaks happen when error returns skip cleanup. You must pair subprocess spawning with stop logic at every error branch and drain HTTP response bodies on error to prevent connection exhaustion.

What is the best way to handle context cancellation and cleanup in Go multi-step functions?

The best way to handle context cleanup in Go is enforcing defer-adjacent pairing, placing cancel calls immediately after context creation so every error return triggers teardown of claims, leases, and subprocesses automatically.

Should I use http.DefaultClient in Go production code paths with error handling?

Do not use http.DefaultClient in Go production execution paths. Use custom HTTP clients and drain response bodies on every error return to maintain connection hygiene and prevent leaks during partial failures.

How do I test Go cleanup logic for partial failure paths?

Test Go partial-failure cleanup by writing tests that trigger each targeted error scenario individually and assert context cancellation, lease release, subprocess stop, and HTTP body draining actually occurred after failure.

Does this Go error handling approach work for registry and lease cleanup?

Yes, this Go error handling approach audits cleanup for registry entries, claims, and leases by verifying each allocated resource has correct cancel, close, release, or stop behavior across every error return.