audithandoffdoc

SkillDocs & knowledge

Deep audit producing a handoff document to get another agent fully up to speed

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the audithandoffdoc skill

What this skill tells your AI

The instructions your AI receives, as published by sterlingcrispin/claude_slash_commands in audithandoffdoc/SKILL.md and read by ahel’s review.

Please perform a deep audit of our current task to produce a handoff document that gets another agent fully up to speed.

Deliverable: Create a file named AUDIT_HANDOFF.md at the project root.

Document your current understanding of:

  • what we are building
  • why we are building it
  • the project's telos (ultimate purpose/end-state)
  • how we are approaching implementation
  • what has been completed so far
  • how we define and measure success
  • current hypotheses
  • what is true (with evidence) vs what is assumed
  • what might be wrong
  • highest-risk areas
  • what we just tried and the outcome
  • next hypothesis
  • open questions

Required Structure (use these exact section headers)

  1. # Executive Summary
  • 5-10 bullets: current project state, trajectory, and key concerns.
  1. # Product Vision and Telos
  • What we are building.
  • Why it matters.
  • Desired end-state if the project fully succeeds.
  1. # Implementation Approach
  • Architecture and strategy.
  • Key technical decisions and tradeoffs.
  • Why this approach was chosen over alternatives.
  1. # Progress So Far
  • Completed work.
  • In-progress work.
  • Deferred/not started work.
  • Include concrete references (files, PRs, commits, tests, docs) where possible.
  1. # Success Metrics
  • Define primary and secondary metrics.
  • For each metric include: baseline, current value (if known), target, and measurement method.
  1. # Hypotheses
  • Current main hypothesis.
  • Supporting sub-hypotheses.
  • What would confirm or falsify each one.
  1. # Evidence vs Assumptions Include a table with columns: Claim | Type (Evidence/Assumption) | Source | Confidence (Low/Med/High) | Notes

  2. # Failure Modes and Risk Register

  • What could be wrong.
  • Highest-risk areas (ranked by impact x likelihood).
  • Detection signals and mitigation options for each risk.
  1. # Most Recent Experiment/Attempt
  • What was just tried.
  • Expected result.
  • Actual result.
  • Interpretation.
  • Artifacts (logs, test outputs, benchmark data, screenshots, etc.).
  1. # Next Hypothesis and Immediate Plan
  • Next best hypothesis to test.
  • Why this is the highest-leverage next step.
  • Step-by-step plan for the next iteration.
  1. # Open Questions
  • Unresolved technical, product, and operational questions.
  • For each: why it matters, blocking status, and who/what can resolve it.

Quality Bar

  • Clearly separate facts, inferences, and assumptions.
  • Prefer concrete evidence over narrative.
  • Cite sources directly (file paths, line refs, commands, outputs, tickets, PR links).
  • Be explicit about uncertainty and confidence.
  • Keep it concise but complete; optimize for fast onboarding and auditability.

Signals

GitHub stars
200
Forks
18
Last commit
Mar 2026
Advanced
Catalog kind
skill
Gateway key
audithandoffdoc
Source
github.com/sterlingcrispin/claude_slash_commands