audithandoffdoc

Name: audithandoffdoc
Author: sterlingcrispin

201stars18forks

How to install audithandoffdoc?

sterlingcrispin/claude_slash_commands/audithandoffdoc

$npx -y skills add sterlingcrispin/claude_slash_commands --skill audithandoffdoc

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	Please perform a deep audit of our current task to produce a handoff document that gets another agent fully up to speed.
2
3	Deliverable:
4	Create a file named `AUDIT_HANDOFF.md` at the project root.
5
6	Document your current understanding of:
7	- what we are building
8	- why we are building it
9	- the project's telos (ultimate purpose/end-state)
10	- how we are approaching implementation
11	- what has been completed so far
12	- how we define and measure success
13	- current hypotheses
14	- what is true (with evidence) vs what is assumed
15	- what might be wrong
16	- highest-risk areas
17	- what we just tried and the outcome
18	- next hypothesis
19	- open questions
20
21	Required Structure (use these exact section headers)
22
23	1. `# Executive Summary`
24	- 5-10 bullets: current project state, trajectory, and key concerns.
25
26	2. `# Product Vision and Telos`
27	- What we are building.
28	- Why it matters.
29	- Desired end-state if the project fully succeeds.
30
31	3. `# Implementation Approach`
32	- Architecture and strategy.
33	- Key technical decisions and tradeoffs.
34	- Why this approach was chosen over alternatives.
35
36	4. `# Progress So Far`
37	- Completed work.
38	- In-progress work.
39	- Deferred/not started work.
40	- Include concrete references (files, PRs, commits, tests, docs) where possible.
41
42	5. `# Success Metrics`
43	- Define primary and secondary metrics.
44	- For each metric include: baseline, current value (if known), target, and measurement method.
45
46	6. `# Hypotheses`
47	- Current main hypothesis.
48	- Supporting sub-hypotheses.
49	- What would confirm or falsify each one.
50
51	7. `# Evidence vs Assumptions`
52	Include a table with columns:
53	`Claim \| Type (Evidence/Assumption) \| Source \| Confidence (Low/Med/High) \| Notes`
54
55	8. `# Failure Modes and Risk Register`
56	- What could be wrong.
57	- Highest-risk areas (ranked by impact x likelihood).
58	- Detection signals and mitigation options for each risk.
59
60	9. `# Most Recent Experiment/Attempt`
61	- What was just tried.
62	- Expected result.
63	- Actual result.
64	- Interpretation.
65	- Artifacts (logs, test outputs, benchmark data, screenshots, etc.).
66
67	10. `# Next Hypothesis and Immediate Plan`
68	- Next best hypothesis to test.
69	- Why this is the highest-leverage next step.
70	- Step-by-step plan for the next iteration.
71
72	11. `# Open Questions`
73	- Unresolved technical, product, and operational questions.
74	- For each: why it matters, blocking status, and who/what can resolve it.
75
76	## Quality Bar
77
78	- Clearly separate facts, inferences, and assumptions.
79	- Prefer concrete evidence over narrative.
80	- Cite sources directly (file paths, line refs, commands, outputs, tickets, PR links).
81	- Be explicit about uncertainty and confidence.
82	- Keep it concise but complete; optimize for fast onboarding and auditability.

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

audithandoffdoc

201stars18forks

View on GitHub

How to install audithandoffdoc?

sterlingcrispin/claude_slash_commands/audithandoffdoc

$npx -y skills add sterlingcrispin/claude_slash_commands --skill audithandoffdoc

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	Please perform a deep audit of our current task to produce a handoff document that gets another agent fully up to speed.
2
3	Deliverable:
4	Create a file named `AUDIT_HANDOFF.md` at the project root.
5
6	Document your current understanding of:
7	- what we are building
8	- why we are building it
9	- the project's telos (ultimate purpose/end-state)
10	- how we are approaching implementation
11	- what has been completed so far
12	- how we define and measure success
13	- current hypotheses
14	- what is true (with evidence) vs what is assumed
15	- what might be wrong
16	- highest-risk areas
17	- what we just tried and the outcome
18	- next hypothesis
19	- open questions
20
21	Required Structure (use these exact section headers)
22
23	1. `# Executive Summary`
24	- 5-10 bullets: current project state, trajectory, and key concerns.
25
26	2. `# Product Vision and Telos`
27	- What we are building.
28	- Why it matters.
29	- Desired end-state if the project fully succeeds.
30
31	3. `# Implementation Approach`
32	- Architecture and strategy.
33	- Key technical decisions and tradeoffs.
34	- Why this approach was chosen over alternatives.
35
36	4. `# Progress So Far`
37	- Completed work.
38	- In-progress work.
39	- Deferred/not started work.
40	- Include concrete references (files, PRs, commits, tests, docs) where possible.
41
42	5. `# Success Metrics`
43	- Define primary and secondary metrics.
44	- For each metric include: baseline, current value (if known), target, and measurement method.
45
46	6. `# Hypotheses`
47	- Current main hypothesis.
48	- Supporting sub-hypotheses.
49	- What would confirm or falsify each one.
50
51	7. `# Evidence vs Assumptions`
52	Include a table with columns:
53	`Claim \| Type (Evidence/Assumption) \| Source \| Confidence (Low/Med/High) \| Notes`
54
55	8. `# Failure Modes and Risk Register`
56	- What could be wrong.
57	- Highest-risk areas (ranked by impact x likelihood).
58	- Detection signals and mitigation options for each risk.
59
60	9. `# Most Recent Experiment/Attempt`
61	- What was just tried.
62	- Expected result.
63	- Actual result.
64	- Interpretation.
65	- Artifacts (logs, test outputs, benchmark data, screenshots, etc.).
66
67	10. `# Next Hypothesis and Immediate Plan`
68	- Next best hypothesis to test.
69	- Why this is the highest-leverage next step.
70	- Step-by-step plan for the next iteration.
71
72	11. `# Open Questions`
73	- Unresolved technical, product, and operational questions.
74	- For each: why it matters, blocking status, and who/what can resolve it.
75
76	## Quality Bar
77
78	- Clearly separate facts, inferences, and assumptions.
79	- Prefer concrete evidence over narrative.
80	- Cite sources directly (file paths, line refs, commands, outputs, tickets, PR links).
81	- Be explicit about uncertainty and confidence.
82	- Keep it concise but complete; optimize for fast onboarding and auditability.

People who liked this also viewed

6 picks

Type