hk-autonomy-audit

Name: hk-autonomy-audit
Author: deepklarity

84stars12forks

How to install hk-autonomy-audit?

deepklarity/harness-kit/hk-autonomy-audit

$npx -y skills add deepklarity/harness-kit --skill hk-autonomy-audit

Installs into the current project.

Summary

Audit whether an AI agent can autonomously close the loop on problems in a given area — from discovering a symptom to verifying a fix — without human intervention. Evaluates documentation, diagnostic tools, commands, logs, and flows for completeness and actionability. Generates a

Files · 1

View on GitHub

SKILL.md

1	# /hk-autonomy-audit — Autonomous Loop-Closing Readiness Audit
2
3	You're auditing whether the tooling, docs, commands, and flows in a given area are sufficient for an AI agent to autonomously solve problems — from first symptom to verified fix — without stopping to ask a human.
4
5	This is not a documentation quality check. It's an operational readiness assessment. The question isn't "do docs exist?" but "if an agent hit a wall here at 3am, could it get itself unstuck?"
6
7	## Target
8
9	<audit_target> $ARGUMENTS </audit_target>
10
11	If the target is empty or vague, ask the user:
12	1. What area or flow should be audited? (e.g., "odin task execution", "taskit API debugging", "reflection quality issues")
13	2. Is there a specific scenario that prompted this? (a recent failure where an agent got stuck is the best input)
14
15	If the user provides a doc path, start there but don't stop there — trace outward to the commands, tools, and flows the doc references.
16
17	## The Mental Model
18
19	An AI agent closing the loop on a problem goes through six stages. A gap at any stage breaks the chain:
20
21	```
22	DISCOVER → DIAGNOSE → HYPOTHESIZE → FIX → VERIFY → DOCUMENT
23	↓ ↓ ↓ ↓ ↓ ↓
24	"Something "The root "Changing "Apply "Confirm "Record what
25	is wrong" cause is X should the it works happened and
26	Y because fix it change end-to- why"
27	Z" because W" itself end"
28	```
29
30	Each stage needs specific resources. The audit checks whether those resources exist, are discoverable, and are actually usable by an agent (not just by a human who knows where to look).
31
32	## Process
33
34	### Step 1: Scope the audit
35
36	Read the target area's CLAUDE.md, AGENTS.md, and any referenced docs. Build a mental map of:
37	- What problems can occur here? (error types, failure modes, misconfigurations)
38	- What tools exist for this area? (diagnostic scripts, CLI commands, log files)
39	- What docs cover this area? (guides, patterns, solutions)
40
41	Don't read everything — scan headings and structure first. Depth comes in Step 2 when you know where to look.
42
43	### Step 2: Walk the agent journey
44
45	For each stage, evaluate from the perspective of an AI agent that has access to the repo's CLAUDE.md files and tools but no prior tribal knowledge. Use parallel subagents to check multiple stages simultaneously.
46
47	DISCOVER — Can the agent detect that something is wrong?
48	- Are error messages actionable? (Do they say what failed, or just "error"?)
49	- Are logs accessible and parseable? (Where are they? What format? Can an agent tail them?)
50	- Are there health checks or status commands? (Quick "is this working?" checks)
51	- Is there monitoring that surfaces problems before a human reports them?
52
53	DIAGNOSE — Can the agent find the root cause?
54	- Are diagnostic scripts/commands available? (Not just "look at the code")
55	- Do diagnostic tools explain what they find? (Auto-detected problems, not just raw data)
56	- Is the data flow traceable? (Can the agent follow data from input to symptom?)
57	- Are common failure patterns documented with their signatures?
58
59	HYPOTHESIZE — Can the agent form a theory?
60	- Do docs explain the WHY behind design decisions? (Not just what the code does)
61	- Are edge cases and gotchas documented? (The non-obvious things)
62	- Are there solution docs from past incidents? (Searchable by symptom)
63	- Is there enough architectural context to reason about side effects?
64
65	FIX — Can the agent make the change?
66	- Are modification commands documented? (Not just read-only inspection)
67	- Are there guard rails? (Tests that catch regressions, linters, type checks)
68	- Is the change surface well-bounded? (Can the agent know which files to touch?)
69	- Are there examples of similar past fixes? (Patterns to follow)
70
71	VERIFY — Can the agent confirm the fix works?
72	- Are test commands documented and runnable? (Not just "run the tests")
73	- Is there a live verification path? (Beyond unit tests — can the agent check end-to-end?)
74	- Are success criteria defined? (How does "working" look, specifically?)
75	- Can the agent verify

People who liked this also viewed

6 picks

Type

hk-autonomy-audit

84stars12forks

View on GitHub

How to install hk-autonomy-audit?

deepklarity/harness-kit/hk-autonomy-audit

$npx -y skills add deepklarity/harness-kit --skill hk-autonomy-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /hk-autonomy-audit — Autonomous Loop-Closing Readiness Audit
2
3	You're auditing whether the tooling, docs, commands, and flows in a given area are sufficient for an AI agent to autonomously solve problems — from first symptom to verified fix — without stopping to ask a human.
4
5	This is not a documentation quality check. It's an operational readiness assessment. The question isn't "do docs exist?" but "if an agent hit a wall here at 3am, could it get itself unstuck?"
6
7	## Target
8
9	<audit_target> $ARGUMENTS </audit_target>
10
11	If the target is empty or vague, ask the user:
12	1. What area or flow should be audited? (e.g., "odin task execution", "taskit API debugging", "reflection quality issues")
13	2. Is there a specific scenario that prompted this? (a recent failure where an agent got stuck is the best input)
14
15	If the user provides a doc path, start there but don't stop there — trace outward to the commands, tools, and flows the doc references.
16
17	## The Mental Model
18
19	An AI agent closing the loop on a problem goes through six stages. A gap at any stage breaks the chain:
20
21	```
22	DISCOVER → DIAGNOSE → HYPOTHESIZE → FIX → VERIFY → DOCUMENT
23	↓ ↓ ↓ ↓ ↓ ↓
24	"Something "The root "Changing "Apply "Confirm "Record what
25	is wrong" cause is X should the it works happened and
26	Y because fix it change end-to- why"
27	Z" because W" itself end"
28	```
29
30	Each stage needs specific resources. The audit checks whether those resources exist, are discoverable, and are actually usable by an agent (not just by a human who knows where to look).
31
32	## Process
33
34	### Step 1: Scope the audit
35
36	Read the target area's CLAUDE.md, AGENTS.md, and any referenced docs. Build a mental map of:
37	- What problems can occur here? (error types, failure modes, misconfigurations)
38	- What tools exist for this area? (diagnostic scripts, CLI commands, log files)
39	- What docs cover this area? (guides, patterns, solutions)
40
41	Don't read everything — scan headings and structure first. Depth comes in Step 2 when you know where to look.
42
43	### Step 2: Walk the agent journey
44
45	For each stage, evaluate from the perspective of an AI agent that has access to the repo's CLAUDE.md files and tools but no prior tribal knowledge. Use parallel subagents to check multiple stages simultaneously.
46
47	DISCOVER — Can the agent detect that something is wrong?
48	- Are error messages actionable? (Do they say what failed, or just "error"?)
49	- Are logs accessible and parseable? (Where are they? What format? Can an agent tail them?)
50	- Are there health checks or status commands? (Quick "is this working?" checks)
51	- Is there monitoring that surfaces problems before a human reports them?
52
53	DIAGNOSE — Can the agent find the root cause?
54	- Are diagnostic scripts/commands available? (Not just "look at the code")
55	- Do diagnostic tools explain what they find? (Auto-detected problems, not just raw data)
56	- Is the data flow traceable? (Can the agent follow data from input to symptom?)
57	- Are common failure patterns documented with their signatures?
58
59	HYPOTHESIZE — Can the agent form a theory?
60	- Do docs explain the WHY behind design decisions? (Not just what the code does)
61	- Are edge cases and gotchas documented? (The non-obvious things)
62	- Are there solution docs from past incidents? (Searchable by symptom)
63	- Is there enough architectural context to reason about side effects?
64
65	FIX — Can the agent make the change?
66	- Are modification commands documented? (Not just read-only inspection)
67	- Are there guard rails? (Tests that catch regressions, linters, type checks)
68	- Is the change surface well-bounded? (Can the agent know which files to touch?)
69	- Are there examples of similar past fixes? (Patterns to follow)
70
71	VERIFY — Can the agent confirm the fix works?
72	- Are test commands documented and runnable? (Not just "run the tests")
73	- Is there a live verification path? (Beyond unit tests — can the agent check end-to-end?)
74	- Are success criteria defined? (How does "working" look, specifically?)
75	- Can the agent verify

People who liked this also viewed

6 picks

Type