agent-audit
Skill13 starsChanged 7 months agoMITView on GitHub
Audits agents, prompts, skills, knowledge, and documentation for gaps, inconsistencies, and improvement opportunities. Proposes changes for user approval. Triggers on "agent-audit", "audit agents", "review config", "what can we improve".
3 other projects use a version of this.
Adopted by
Most recently taken up by
- DentalEdge-Solutions/claude_codetheir own version, first seen Nov 1, 2026
- Linwei-Chen/agent-audittheir own version, first seen Oct 15, 2026
- day-ai/gtm-braintheir own version, first seen Aug 19, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- day-ai/gtm-brain★ 9same name
- DentalEdge-Solutions/claude_code★ 1same name
- Linwei-Chen/agent-audit★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
- codebase-auditSkill
- commitSkill
- design-and-specSkill
- dispatching-parallel-agentsSkill
- doc-driftSkill
- execution-planningSkill
- explain-codeSkill
- post-implementationSkill
- pushSkill
- python-auditSkill
- receiving-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- terraform-auditSkill
- test-driven-developmentSkill
- trace-codeSkill
- typescript-auditSkill
- verification-before-completionSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
22 rules. About 0 are common, 12 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Read all of these files:
- Very specific: line 17
All files in agents/prompts/
- Very specific: line 23
All files in skills/*/SKILL.md (frontmatter only — name, description)
- Very specific: line 32
If docs/improvements/pending.md exists, process it before any other analysis:
- Distinctive: line 34
Read every entry — each has a date, project path, what went wrong, and a suggested fix
- Very specific: line 49
Read the description frontmatter — this is what the orchestrator matches against
- Distinctive: line 52
Check: does the trigger description match real user phrasing, or is it written in system terminology?
- Distinctive: line 69
Do any rules reference tools, APIs, or patterns that no longer exist?
- Very specific: line 108
Check that file paths mentioned in skill-catalog match the actual paths in the skill's SKILL.md content
- Distinctive: line 109
Check that file paths in steering docs reference files that exist
- Distinctive: line 110
Check that hook scripts referenced in agent JSON hooks exist on disk
- Distinctive: line 122
Check that counts in welcome messages match actual counts for that agent's loaded resources
- Distinctive: line 126
Check for files on disk that exist in listed directories but are missing from the tree
- Very specific: line 141
When the current workspace has a .kiro/ directory (project-level config), also check:
- Very specific: line 143
Path validity: Do allowedPaths in agent JSON files reference directories that actually exist?
- Very specific: line 144
Knowledge base sources: Do knowledgeBase source paths point to directories that exist?
- Distinctive: line 145
Prompt file references: Do file paths mentioned in agent prompts reference files that exist?
- Distinctive: line 146
Stale structure references: Do prompts or skills reference folder patterns from a previous project structure?
- Very specific: line 147
docs/context/ alignment: If docs/context/ exists, check that steering docs point to it rather than duplicating its content.
- Very specific: line 194
After user approves resolved items, move them from docs/improvements/pending.md to docs/improvements/resolved.md.
- Distinctive: line 198
When running agent-audit, also check:
- Distinctive: line 202
If findings exist, append a "Proactive Suggestions" section to the report.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Audit
Analyze the current kiro-config and propose improvements.
Announce at start: "Running agent-audit against current kiro-config."
Process
Phase 1: Read current state
Read all of these files:
- All files in
agents/prompts/ - All files in
agents/*.json knowledge/rules.mdknowledge/gotchas.mdknowledge/episodes.md- All files in
steering/ - All files in
skills/*/SKILL.md(frontmatter only — name, description) docs/reference/skill-catalog.mddocs/reference/security-model.mddocs/reference/creating-agents.mdREADME.mddocs/improvements/pending.md← primary input (read first if it exists)
Phase 2: improvements/pending.md analysis
If docs/improvements/pending.md exists, process it before any other analysis:
- Read every entry — each has a date, project path, what went wrong, and a suggested fix
- Group entries by root cause type:
steering gap|routing issue|missing skill|missing context - Identify patterns: 3+ entries with the same root cause = high-priority fix
- Cross-reference each entry against the current config files to check if it's already been resolved
- Entries that are already resolved → move to
docs/improvements/resolved.md(after user approval) - Entries still unresolved → produce actionable proposals: "add X to Y.md", "update routing trigger Z"
Cross-project awareness: Improvement entries include the project path where friction occurred. Use this to identify patterns across projects without scanning those directories directly:
- Multiple entries from the same project mentioning a language → check if a steering doc exists for that language
- Routing corrections in entries → check if the routing table has the missing pattern
- Missing context entries → check if a context doc or gotcha covers that gap
Phase 3: Skill coverage analysis
For each skill in skills/*/SKILL.md:
- Read the
descriptionfrontmatter — this is what the orchestrator matches against - Compare trigger phrases against how users actually phrase requests (use improvement entries as signal)
- Flag triggers that are too narrow (miss common phrasings) or too broad (overlap with other skills)
- Check: does the trigger description match real user phrasing, or is it written in system terminology?
Phase 4: Check agent and skill consistency
- Agent prompts missing guidance that exists in steering docs
- Rules in steering that aren't reflected in agent deny lists
- Gotchas that should be promoted to rules
- Episodes that have been sitting active for too long
- Inconsistencies between agents (e.g., one has a deny rule another lacks)
- Skills referenced in agent configs that don't exist on disk
- Skills that exist on disk but aren't referenced by any agent
- deniedCommands lists that differ between subagents (should be identical)
Phase 5: Steering effectiveness check
For each file in steering/:
- Are the rules specific enough to act on, or are they vague guidance?
- Do any rules reference tools, APIs, or patterns that no longer exist?
- Are there rules that contradict each other across steering docs?
- Flag rules that are too vague: "be careful" → needs a concrete action
- Flag rules that are outdated: reference deprecated patterns or old file paths
Phase 6: Knowledge hygiene
Review knowledge/episodes.md and knowledge/rules.md:
- Promotion candidates: Episodes that have recurred 2+ times → propose promoting to a rule
- Stale rules: Rules that reference resolved issues, deprecated tools, or old file structures
- Duplication: Any section in
knowledge/gotchas.mdorknowledge/rules.mdlonger than 3 lines that substantially overlaps with content in steering docs or agent prompts — gotchas and rules should be short pointers, not full copies of checklists
Phase 7: Routing review
Examine the orchestrator's routing table:
- Dead routes: Triggers that haven't fired recently (use improvement entries as signal)
- Overlapping triggers: Two routes with similar trigger words — which one wins?
- Missing patterns: Improvement entries with "routing correction" root cause → what trigger was missing?
- Skill trigger drift: Compare skill
descriptionfrontmatter against the routing table entries that reference them
Phase 8: Check documentation consistency
Cross-reference documentation files against source-of-truth config files:
Skill counts:
- Count
skills/*/SKILL.mdfiles on disk - Compare against counts in
README.md, agent welcome messages,docs/reference/skill-catalog.md - Flag mismatches
Skill assignment matrix:
- For each agent JSON, extract the
skill://entries fromresources - Compare against the matrix in
docs/reference/skill-catalog.mdandREADME.md - Flag any agent that has a skill in its JSON but not in the matrix (or vice versa)
Skill descriptions:
- For each skill in
docs/reference/skill-catalog.md, compare the "Activates when you say..." column against the actual SKILL.mddescriptionfrontmatter - Flag descriptions that have drifted
File paths in docs:
- Check that file paths mentioned in skill-catalog match the actual paths in the skill's SKILL.md content
- Check that file paths in steering docs reference files that exist
- Check that hook scripts referenced in agent JSON hooks exist on disk
Steering and MCP counts:
- Count
steering/*.mdfiles on disk - Count MCP servers across all agent configs
- Compare against counts mentioned in README or docs
Agent tool alignment:
- For each agent JSON, verify every tool in
allowedToolsis also intools - Cross-check MCP servers: if an agent references an MCP tool, verify the MCP server is available
Welcome message accuracy:
- Check that counts in welcome messages match actual counts for that agent's loaded resources
Directory tree verification:
- For each directory tree in README.md, verify every listed file exists on disk
- Check for files on disk that exist in listed directories but are missing from the tree
- Flag any mismatch (file listed but missing, or file exists but unlisted)
Feature count verification:
- For each count in the Features section (e.g., "N steering docs", "N skills", "N hooks", "N agents"), verify the number against the actual filesystem. Current baseline as of v0.7.0: 12 steering docs, 20 skills, 11 hooks, 11 agents.
- Flag any count that doesn't match
Phase 9: Check for staleness
- Rules that may be outdated (platform changes, new features)
- Gotchas that have been resolved by config changes
- Agent prompts that reference deprecated patterns
Phase 9.5: Project-level .kiro/ audit
When the current workspace has a .kiro/ directory (project-level config), also check:
- Path validity: Do
allowedPathsin agent JSON files reference directories that actually exist? - Knowledge base sources: Do
knowledgeBasesourcepaths point to directories that exist? - Prompt file references: Do file paths mentioned in agent prompts reference files that exist?
- Stale structure references: Do prompts or skills reference folder patterns from a previous project structure?
- docs/context/ alignment: If
docs/context/exists, check that steering docs point to it rather than duplicating its content.
Skip this phase if the workspace has no .kiro/ directory.
Phase 10: Output structured report
## Agent Audit Report — YYYY-MM-DD
### Improvements Backlog (from pending.md)
- [ ] [entry date + project] — proposed fix
### Skill Coverage Gaps
- [ ] [skill] — trigger mismatch or missing phrasing
### Steering Effectiveness
- [ ] [file:rule] — too vague / outdated
### Knowledge Hygiene
- [ ] [episode/rule] — promotion candidate or stale
### Routing Issues
- [ ] [route] — dead / overlapping / missing
### Config Gaps
- [ ] [file] — description of gap
### Documentation Drift
- [ ] [doc file vs source file] — what's inconsistent
### Stale Items
- [ ] [file:line] — what's stale and why
### Proposed Changes
For each finding, include:
- File to modify
- What to change
- Why
### Resolved (pending.md items already fixed)
Items that can be moved to resolved.md.
### No Action Needed
Items reviewed and found current.Present to user for approval. Never auto-apply changes.
After user approves resolved items, move them from docs/improvements/pending.md to docs/improvements/resolved.md.
Proactive Suggestions
When running agent-audit, also check:
- Are there new Kiro CLI features (check /help, introspect) that could improve the config?
- Are there patterns in recent sessions that suggest a new rule or gotcha?
If findings exist, append a "Proactive Suggestions" section to the report.
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
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.

