aiblueprint-cli 1.4.108 → 1.4.110
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +10 -0
- package/agents-config/claude-config/mods/agent4everything/.claude-plugin/plugin.json +5 -0
- package/agents-config/claude-config/mods/agent4everything/hooks/hooks.json +1 -0
- package/agents-config/claude-config/mods/agent4everything/hooks/register.ts +96 -0
- package/agents-config/claude-config/mods/aiblueprint/.claude-plugin/plugin.json +71 -0
- package/agents-config/claude-config/mods/aiblueprint/hooks/hooks.json +1 -0
- package/agents-config/claude-config/mods/aiblueprint/hooks/register.tsx +309 -0
- package/agents-config/claude-config/mods/aiblueprint/tests/band.test.tsx +74 -0
- package/agents-config/claude-config/mods/aiblueprint/types/index.d.ts +14 -0
- package/agents-config/claude-config/scripts/.claude/skills/fix-on-my-computer/SKILL.md +8 -74
- package/agents-config/claude-config/scripts/statusline/src/index.ts +1 -0
- package/agents-config/scripts/.claude/skills/fix-on-my-computer/SKILL.md +8 -74
- package/agents-config/scripts/statusline/src/index.ts +1 -0
- package/agents-config/skills/agents-manager/SKILL.md +15 -453
- package/agents-config/skills/apex/SKILL.md +14 -110
- package/agents-config/skills/app-icon/SKILL.md +22 -117
- package/agents-config/skills/appstore-connect/SKILL.md +22 -85
- package/agents-config/skills/arena/LICENSE +21 -0
- package/agents-config/skills/arena/SKILL.md +371 -0
- package/agents-config/skills/arena/agents/openai.yaml +9 -0
- package/agents-config/skills/arena/assets/codex-icon.svg +22 -0
- package/agents-config/skills/arena/bracket.py +1235 -0
- package/agents-config/skills/arena/rubric.md +79 -0
- package/agents-config/skills/arena/strategies.json +205 -0
- package/agents-config/skills/audit-memories/SKILL.md +13 -139
- package/agents-config/skills/audit-skills/SKILL.md +6 -65
- package/agents-config/skills/environments-manager/SKILL.md +14 -238
- package/agents-config/skills/grill-me/SKILL.md +8 -22
- package/agents-config/skills/hooks-manager/SKILL.md +8 -54
- package/agents-config/skills/rules-manager/SKILL.md +11 -192
- package/agents-config/skills/skill-manager/SKILL.md +19 -158
- package/agents-config/skills/skill-manager/references/description-recommandation.md +15 -85
- package/agents-config/skills/test-audit/CAMPAIGN.md +117 -0
- package/agents-config/skills/test-audit/LICENSE +23 -0
- package/agents-config/skills/test-audit/SKILL.md +169 -0
- package/agents-config/skills/test-audit/agents/openai.yaml +10 -0
- package/agents-config/skills/test-audit/assets/codex-icon.svg +1 -0
- package/agents-config/skills/use-style/SKILL.md +8 -48
- package/dist/cli.js +125 -78
- package/package.json +1 -1
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
# The arena rubric
|
|
2
|
+
|
|
3
|
+
Every match in the arena is scored against this page. The judge scores both solutions, `bracket.py`
|
|
4
|
+
does the arithmetic, and the higher weighted total goes through. The loser is out.
|
|
5
|
+
|
|
6
|
+
## The five criteria
|
|
7
|
+
|
|
8
|
+
Each criterion is scored 0 to 10. The weight is how much of the 100-point total it is worth.
|
|
9
|
+
|
|
10
|
+
| criterion | weight | the question |
|
|
11
|
+
| --- | --- | --- |
|
|
12
|
+
| Correctness | 30 | Is it right? No false claims, no logic errors, no bugs, nothing that would mislead the user. |
|
|
13
|
+
| Completeness | 25 | Does it meet every requirement the task actually states? Judged against the task text, not against what the judge would have liked. |
|
|
14
|
+
| Specificity | 15 | Could the user act on it right now without guessing? Exact steps, values, names, code. |
|
|
15
|
+
| Robustness | 20 | Does it hold up against the attacks raised in this match? Fixed, correctly rebutted, or still standing. |
|
|
16
|
+
| Clarity | 10 | Is it easy to read and use, at a length that fits the task? |
|
|
17
|
+
|
|
18
|
+
Weighted total = (correctness x 30 + completeness x 25 + specificity x 15 + robustness x 20 + clarity x 10) / 10.
|
|
19
|
+
That gives a number from 0 to 100.
|
|
20
|
+
|
|
21
|
+
## Anchors
|
|
22
|
+
|
|
23
|
+
Use the whole scale. A 7 is not a polite default.
|
|
24
|
+
|
|
25
|
+
**Correctness**
|
|
26
|
+
- 10: nothing wrong that you can find after checking it yourself.
|
|
27
|
+
- 7: minor slips that do not change the outcome for the user.
|
|
28
|
+
- 4: at least one real error the user would trip on.
|
|
29
|
+
- 0 to 2: wrong at the core, or it would cause harm if used.
|
|
30
|
+
|
|
31
|
+
**Completeness**
|
|
32
|
+
- 10: every stated requirement is met, fully.
|
|
33
|
+
- 7: every requirement is touched, one is thin.
|
|
34
|
+
- 4: a stated requirement is missing.
|
|
35
|
+
- 0 to 2: it answers a different question from the one asked.
|
|
36
|
+
|
|
37
|
+
**Specificity**
|
|
38
|
+
- 10: the user can act on every part of it immediately.
|
|
39
|
+
- 7: mostly concrete, with one or two places that need a guess.
|
|
40
|
+
- 4: a lot of "consider", "ensure" and "it depends" without the actual answer.
|
|
41
|
+
- 0 to 2: generic advice that would fit any task.
|
|
42
|
+
|
|
43
|
+
**Robustness**
|
|
44
|
+
- 10: every attack in this match is fixed in the revised solution or correctly rebutted, and nothing new is broken.
|
|
45
|
+
- 7: one MINOR attack still standing.
|
|
46
|
+
- 4: a MAJOR attack still standing, or a fix that broke something else.
|
|
47
|
+
- 0 to 2: a FATAL attack still standing.
|
|
48
|
+
|
|
49
|
+
A missing attack file means the opponent raised nothing. Score robustness on the flaws you found yourself.
|
|
50
|
+
|
|
51
|
+
**Clarity**
|
|
52
|
+
- 10: the shape makes it obvious how to use it. No padding.
|
|
53
|
+
- 7: fine, with some padding or one confusing section.
|
|
54
|
+
- 4: the user has to dig for the answer.
|
|
55
|
+
- 0 to 2: hard to follow at all.
|
|
56
|
+
|
|
57
|
+
## The fatal rule
|
|
58
|
+
|
|
59
|
+
Mark a solution `fatal` only when you have verified a flaw that makes it wrong or unusable for the
|
|
60
|
+
task: code that cannot work, a false central claim, a hard constraint broken, the wrong question
|
|
61
|
+
answered. A fatal solution cannot beat a solution that is not fatal, whatever the totals say. If both
|
|
62
|
+
are fatal, the totals decide.
|
|
63
|
+
|
|
64
|
+
## Ties
|
|
65
|
+
|
|
66
|
+
There are no draws. On an exact tie, the solution with fewer attacks still standing wins. If that is
|
|
67
|
+
also level, the higher correctness score wins. If that is also level, pick the one you would hand to
|
|
68
|
+
the user, and say why in the reason.
|
|
69
|
+
|
|
70
|
+
## What the judge does not reward
|
|
71
|
+
|
|
72
|
+
- **Length.** Longer is not better. A tight answer that meets every requirement beats a long one
|
|
73
|
+
that meets the same requirements.
|
|
74
|
+
- **Confidence.** A defense that says "fixed" is not proof. Check the revised solution.
|
|
75
|
+
- **The approach.** The judge never sees the strategy cards and does not guess at them. It scores
|
|
76
|
+
the work, not the method that produced it.
|
|
77
|
+
- **Talking about quality.** "This robust, comprehensive solution" earns nothing. The solution has to
|
|
78
|
+
be robust and comprehensive.
|
|
79
|
+
- **Agreement with the judge's own taste** where the task does not ask for it.
|
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": 1,
|
|
3
|
+
"about": "The strategy cards for /arena. Every competitor gets the same task and exactly one card: one reasoning mode, one workflow, one strategy. 15 x 12 x 12 = 2,160 distinct cards. bracket.py deals them with no repeats and spreads them evenly, so a 100-agent arena uses every reasoning mode, every workflow and every strategy. Edit freely: add an entry and the dealer picks it up. Ids must stay unique within a list.",
|
|
4
|
+
"reasoning": [
|
|
5
|
+
{
|
|
6
|
+
"id": "first-principles",
|
|
7
|
+
"name": "First principles",
|
|
8
|
+
"how": "Strip the task down to the facts and requirements nobody can argue with. Rebuild the answer from those alone, and keep a convention only if it earns its place again."
|
|
9
|
+
},
|
|
10
|
+
{
|
|
11
|
+
"id": "inversion",
|
|
12
|
+
"name": "Inversion",
|
|
13
|
+
"how": "Ask what would make this answer fail. List every way it could, then build the answer that makes each of those failures impossible."
|
|
14
|
+
},
|
|
15
|
+
{
|
|
16
|
+
"id": "analogy",
|
|
17
|
+
"name": "Analogy",
|
|
18
|
+
"how": "Find a problem in a different field that has already been solved and has the same shape. Port its solution over, then fix every place where the analogy breaks."
|
|
19
|
+
},
|
|
20
|
+
{
|
|
21
|
+
"id": "adversarial",
|
|
22
|
+
"name": "Adversarial",
|
|
23
|
+
"how": "Picture the harshest expert reviewer trying to tear the answer apart. Write their attacks down first and build the answer backwards from them."
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"id": "constraint-first",
|
|
27
|
+
"name": "Constraint first",
|
|
28
|
+
"how": "List every hard constraint, stated and implied: time, budget, tools, format, audience, platform. Solve strictly inside that box and let the tightest constraint drive the design."
|
|
29
|
+
},
|
|
30
|
+
{
|
|
31
|
+
"id": "worked-example",
|
|
32
|
+
"name": "Worked example",
|
|
33
|
+
"how": "Solve one concrete, realistic instance end to end first, with real values. Generalise only from what that example actually taught you."
|
|
34
|
+
},
|
|
35
|
+
{
|
|
36
|
+
"id": "socratic",
|
|
37
|
+
"name": "Socratic",
|
|
38
|
+
"how": "Interrogate the task with the questions a sharp expert would ask before starting. Answer each one explicitly and let the answers decide the shape of the solution."
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "contrarian",
|
|
42
|
+
"name": "Contrarian",
|
|
43
|
+
"how": "Write down the obvious default answer, then argue seriously against it. Keep only what survives the argument, even if that takes you the unpopular way."
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"id": "systems-thinking",
|
|
47
|
+
"name": "Systems thinking",
|
|
48
|
+
"how": "Map the moving parts, how they affect each other, and what happens second and third order. Optimise the whole system, not just the one part the task points at."
|
|
49
|
+
},
|
|
50
|
+
{
|
|
51
|
+
"id": "decomposition",
|
|
52
|
+
"name": "Decomposition",
|
|
53
|
+
"how": "Break the task into independent sub-problems. Solve each one completely, then integrate them and test the seams where they meet."
|
|
54
|
+
},
|
|
55
|
+
{
|
|
56
|
+
"id": "working-backwards",
|
|
57
|
+
"name": "Working backwards",
|
|
58
|
+
"how": "Describe the finished result precisely, as if it already exists. Then work backwards, step by step, to where the user is right now."
|
|
59
|
+
},
|
|
60
|
+
{
|
|
61
|
+
"id": "probabilistic",
|
|
62
|
+
"name": "Probabilistic",
|
|
63
|
+
"how": "Treat every claim and choice as uncertain. Weigh what is likely, prefer what holds up across most scenarios, and state your confidence where it changes the decision."
|
|
64
|
+
},
|
|
65
|
+
{
|
|
66
|
+
"id": "dialectical",
|
|
67
|
+
"name": "Dialectical",
|
|
68
|
+
"how": "State the strongest version of one answer, then the strongest opposing answer, then write the synthesis that keeps what is true in both."
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "evidence-first",
|
|
72
|
+
"name": "Evidence first",
|
|
73
|
+
"how": "Ground every claim in something checkable: the task text, the files it points to, the numbers given, documentation. Anything you cannot check gets labelled as an assumption."
|
|
74
|
+
},
|
|
75
|
+
{
|
|
76
|
+
"id": "expert-panel",
|
|
77
|
+
"name": "Expert panel",
|
|
78
|
+
"how": "Answer the task as three different experts would, picking roles that fit it. Take the strongest idea from each and settle every point where they disagree."
|
|
79
|
+
}
|
|
80
|
+
],
|
|
81
|
+
"workflows": [
|
|
82
|
+
{
|
|
83
|
+
"id": "draft-critique-rewrite",
|
|
84
|
+
"name": "Draft, critique, rewrite",
|
|
85
|
+
"how": "Write a complete first draft. Critique it line by line against the task as if someone else wrote it. Then rewrite it from scratch using the critique."
|
|
86
|
+
},
|
|
87
|
+
{
|
|
88
|
+
"id": "outline-first",
|
|
89
|
+
"name": "Outline first",
|
|
90
|
+
"how": "Write a skeleton outline, check the outline against every requirement in the task, fix it, and only then fill it in."
|
|
91
|
+
},
|
|
92
|
+
{
|
|
93
|
+
"id": "test-first",
|
|
94
|
+
"name": "Test first",
|
|
95
|
+
"how": "Before writing the answer, write the checks it must pass: acceptance tests for code, pass or fail criteria for anything else. Then write the answer and run every check against it."
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"id": "research-then-synthesise",
|
|
99
|
+
"name": "Research, then synthesise",
|
|
100
|
+
"how": "Gather every relevant fact first: the task, any files or context it points to, what is known about the domain. Write nothing until the research is done, then synthesise."
|
|
101
|
+
},
|
|
102
|
+
{
|
|
103
|
+
"id": "three-drafts",
|
|
104
|
+
"name": "Three drafts, pick one",
|
|
105
|
+
"how": "Write three short, genuinely different approaches. Pick the strongest on the task's own terms and develop only that one fully."
|
|
106
|
+
},
|
|
107
|
+
{
|
|
108
|
+
"id": "requirements-checklist",
|
|
109
|
+
"name": "Requirements checklist",
|
|
110
|
+
"how": "Pull every requirement out of the task into a numbered list. Solve, then tick each item off and say exactly where it is met."
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "iterative-deepening",
|
|
114
|
+
"name": "Iterative deepening",
|
|
115
|
+
"how": "Write a one-paragraph answer first. Then expand the parts that matter most in two more passes, each one deeper than the last."
|
|
116
|
+
},
|
|
117
|
+
{
|
|
118
|
+
"id": "build-then-break",
|
|
119
|
+
"name": "Build, then break",
|
|
120
|
+
"how": "Build the answer. Then throw five hostile inputs or scenarios at it, write down what breaks, and patch every break."
|
|
121
|
+
},
|
|
122
|
+
{
|
|
123
|
+
"id": "smallest-version-first",
|
|
124
|
+
"name": "Smallest version first",
|
|
125
|
+
"how": "Produce the smallest complete version that actually works. Then extend it one step at a time, keeping it working after every step."
|
|
126
|
+
},
|
|
127
|
+
{
|
|
128
|
+
"id": "options-matrix",
|
|
129
|
+
"name": "Options matrix",
|
|
130
|
+
"how": "List the realistic options, score them in a small matrix against the criteria that matter for this task, choose one, and write up the choice."
|
|
131
|
+
},
|
|
132
|
+
{
|
|
133
|
+
"id": "open-questions-first",
|
|
134
|
+
"name": "Open questions first",
|
|
135
|
+
"how": "List every open question the task leaves. Resolve each one with reasoning or a stated assumption, then answer."
|
|
136
|
+
},
|
|
137
|
+
{
|
|
138
|
+
"id": "write-then-restructure",
|
|
139
|
+
"name": "Write, then restructure",
|
|
140
|
+
"how": "Write freely and fast. Then outline what you actually wrote, fix the structure, and rewrite it to the new outline."
|
|
141
|
+
}
|
|
142
|
+
],
|
|
143
|
+
"strategies": [
|
|
144
|
+
{
|
|
145
|
+
"id": "simplest",
|
|
146
|
+
"name": "Simplest thing that works",
|
|
147
|
+
"how": "Pick the least complicated answer that fully does the job. Every extra part has to justify itself."
|
|
148
|
+
},
|
|
149
|
+
{
|
|
150
|
+
"id": "maximal-rigour",
|
|
151
|
+
"name": "Maximal rigour",
|
|
152
|
+
"how": "Be exhaustive and exact. Check every step, verify every claim, and leave no hand-waving anywhere."
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "user-empathy",
|
|
156
|
+
"name": "User empathy first",
|
|
157
|
+
"how": "Start from the person who will use this: their situation, their skill level, and what they will actually do next. Shape everything around that."
|
|
158
|
+
},
|
|
159
|
+
{
|
|
160
|
+
"id": "edge-cases-first",
|
|
161
|
+
"name": "Edge cases first",
|
|
162
|
+
"how": "Hunt the edge cases, failure modes and weird inputs first, and design the answer around surviving them."
|
|
163
|
+
},
|
|
164
|
+
{
|
|
165
|
+
"id": "speed",
|
|
166
|
+
"name": "Speed",
|
|
167
|
+
"how": "Optimise for the fastest route to something usable today. Cut anything that does not move the result."
|
|
168
|
+
},
|
|
169
|
+
{
|
|
170
|
+
"id": "defensive",
|
|
171
|
+
"name": "Defensive",
|
|
172
|
+
"how": "Assume the inputs are bad and the conditions are hostile. Make the answer fail safely and loudly rather than quietly."
|
|
173
|
+
},
|
|
174
|
+
{
|
|
175
|
+
"id": "clarity",
|
|
176
|
+
"name": "Clarity above all",
|
|
177
|
+
"how": "Make it the easiest answer to read and act on: plain words, obvious structure, nothing the reader has to decode."
|
|
178
|
+
},
|
|
179
|
+
{
|
|
180
|
+
"id": "completeness",
|
|
181
|
+
"name": "Completeness",
|
|
182
|
+
"how": "Leave out nothing the task asks for or clearly implies. Cover every requirement explicitly."
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "fewest-moving-parts",
|
|
186
|
+
"name": "Fewest moving parts",
|
|
187
|
+
"how": "Remove things until it breaks, then put the last one back. Fewer steps, fewer dependencies, fewer words."
|
|
188
|
+
},
|
|
189
|
+
{
|
|
190
|
+
"id": "explicit-trade-offs",
|
|
191
|
+
"name": "Explicit trade-offs",
|
|
192
|
+
"how": "Name the real trade-offs, choose for the user's most likely constraints, and say plainly what that choice gives up."
|
|
193
|
+
},
|
|
194
|
+
{
|
|
195
|
+
"id": "built-to-last",
|
|
196
|
+
"name": "Built to last",
|
|
197
|
+
"how": "Optimise for how this holds up in six months: easy to maintain, easy to extend, no traps for the next person."
|
|
198
|
+
},
|
|
199
|
+
{
|
|
200
|
+
"id": "concrete-specifics",
|
|
201
|
+
"name": "Concrete specifics",
|
|
202
|
+
"how": "Exact numbers, names, commands, file paths and steps. Zero generic advice."
|
|
203
|
+
}
|
|
204
|
+
]
|
|
205
|
+
}
|
|
@@ -1,161 +1,35 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: audit-memories
|
|
3
|
-
description:
|
|
3
|
+
description: Audit and clean agent-facing Markdown in the current project. Use when the user invokes $audit-memories or /audit-memories to audit or clean AGENTS.md, rules, skills, plans, or task traces.
|
|
4
4
|
argument-hint: "[audit|clean]"
|
|
5
5
|
disable-model-invocation: true
|
|
6
6
|
user-invocable: true
|
|
7
7
|
---
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Proceed only on an explicit `$audit-memories` or `/audit-memories`. An OpenCode command that states the user invoked `/audit-memories` satisfies this guard. Default action is `audit`. `clean` audits first, then applies justified local cleanup.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
Resolve the project root from `$PWD`. Do not switch checkouts. Do not read or modify `~/.codex/memories`. Classify only agent-facing Markdown: `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.agents/**/*.md`, `.claude/**/*.md`, `.cursor/**/*.{md,mdc}`, `.github/copilot-instructions.md`, `.github/instructions/**/*.md`, `skills/**/SKILL.md`, `.agents/skills/**`. Product docs, READMEs, changelogs, and public specs are truth evidence only.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Read the nearest `AGENTS.md`, `CLAUDE.md`, and repository rules first. Record `git status --short` before and after. Never inspect secret values. Never use `rm -rf`; `trash` approved removals. Use `apply_patch` for text. Label provider/runtime claims `NOT VERIFIED` unless this run checks the live system. Do not delete instruction, security, migration, incident, or destructive-safeguard files because they are old.
|
|
14
14
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
Supported actions:
|
|
18
|
-
|
|
19
|
-
- `$audit-memories audit`: exhaustive read-only audit. This is the default action when only `$audit-memories` is supplied.
|
|
20
|
-
- `$audit-memories clean`: run or refresh the exhaustive audit, then apply justified local cleanup.
|
|
21
|
-
- `/audit-memories audit` and `/audit-memories clean`: equivalent manual commands in clients that use slash-command syntax.
|
|
22
|
-
|
|
23
|
-
Do not read or modify `~/.codex/memories`. Do not classify product documentation, public docs, README files, changelogs, or general project plans. They may be read only as truth evidence when an agent document references them.
|
|
24
|
-
|
|
25
|
-
## Hard boundaries
|
|
26
|
-
|
|
27
|
-
- Resolve the project root from the current working directory. Never silently switch to another checkout.
|
|
28
|
-
- Read the nearest applicable `AGENTS.md`, `CLAUDE.md`, and repository rules before auditing.
|
|
29
|
-
- Preserve unrelated dirty-tree changes. Record `git status --short` before and after.
|
|
30
|
-
- Never inspect secret values. Compare environment-variable names through examples, schemas, and code only.
|
|
31
|
-
- Never use `rm -rf`. Use `trash` for approved file removal.
|
|
32
|
-
- Use `apply_patch` for textual edits. Use formatters only for mechanical normalization.
|
|
33
|
-
- Do not infer deployed truth from local code. Label provider/runtime claims `NOT VERIFIED` unless the audit explicitly checks the live system.
|
|
34
|
-
- Do not delete instruction files, security guidance, migration procedures, incident runbooks, or destructive-operation safeguards merely because they are old or rarely linked.
|
|
35
|
-
|
|
36
|
-
## Action: audit
|
|
37
|
-
|
|
38
|
-
### 1. Inventory every agent-facing Markdown file
|
|
15
|
+
## Audit
|
|
39
16
|
|
|
40
17
|
Run:
|
|
41
18
|
|
|
42
19
|
```bash
|
|
43
|
-
python3 ~/.agents/skills/audit-memories/scripts/inventory_project_markdown.py
|
|
44
|
-
--root "$PWD" \
|
|
45
|
-
--format json
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
Include only:
|
|
49
|
-
|
|
50
|
-
- `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, and equivalent agent entrypoints;
|
|
51
|
-
- `.agents/**/*.md`, `.claude/**/*.md`, and `.cursor/**/*.{md,mdc}`;
|
|
52
|
-
- `.github/copilot-instructions.md` and `.github/instructions/**/*.md`;
|
|
53
|
-
- project skill files under `skills/**/SKILL.md` or `.agents/skills/**`.
|
|
54
|
-
|
|
55
|
-
This intentionally includes agent-generated plans, task traces, and output folders because they are prime cleanup candidates. Exclude public/local documentation such as `content/docs`, normal README files, product specs, and application changelogs from classification.
|
|
56
|
-
|
|
57
|
-
The byte-level ledger must show `visited == eligible`. It is not a semantic audit by itself.
|
|
58
|
-
|
|
59
|
-
### 2. Build the project truth map
|
|
60
|
-
|
|
61
|
-
Inspect current primary evidence before classifying documents:
|
|
62
|
-
|
|
63
|
-
1. repository instructions and package/workspace manifests;
|
|
64
|
-
2. source tree, routes, exported APIs, schemas, migrations, and configuration;
|
|
65
|
-
3. tests and CI workflows;
|
|
66
|
-
4. current Git history only when a document makes a historical claim;
|
|
67
|
-
5. live provider/runtime state only when explicitly requested and safely accessible.
|
|
68
|
-
|
|
69
|
-
Start with `rg --files`, `package.json` or equivalent manifests, key configs, and the files referenced by Markdown. Follow repository instructions about required reading. Use targeted searches rather than loading the entire source tree blindly.
|
|
70
|
-
|
|
71
|
-
Truth priority:
|
|
72
|
-
|
|
73
|
-
```text
|
|
74
|
-
explicit current user instruction
|
|
75
|
-
> current code/config/schema
|
|
76
|
-
> current tests and CI contracts
|
|
77
|
-
> verified provider/runtime read-back
|
|
78
|
-
> Markdown claims
|
|
79
|
-
> historical memory
|
|
20
|
+
python3 ~/.agents/skills/audit-memories/scripts/inventory_project_markdown.py --root "$PWD" --format json
|
|
80
21
|
```
|
|
81
22
|
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
Read every eligible agent-facing Markdown file. Sampling is not completion.
|
|
85
|
-
|
|
86
|
-
For more than 30 files, split the exact manifest into disjoint batches of 10–20. Use parallel subagents when available. Give each worker the shared truth map plus exact Markdown paths and read-only boundaries. Require one result row per path; verify that batch union equals the manifest with no duplicates.
|
|
87
|
-
|
|
88
|
-
For each file, record:
|
|
89
|
-
|
|
90
|
-
- purpose and intended audience;
|
|
91
|
-
- whether referenced paths, commands, APIs, routes, names, versions, statuses, and architecture match current evidence;
|
|
92
|
-
- overlap with other Markdown files;
|
|
93
|
-
- broken local links and missing referenced files;
|
|
94
|
-
- historical value and operational risk;
|
|
95
|
-
- evidence paths and line numbers;
|
|
96
|
-
- verdict: `KEEP`, `UPDATE`, `MERGE`, `ARCHIVE`, `DELETE`, or `VERIFY`.
|
|
97
|
-
|
|
98
|
-
For important claims, use:
|
|
99
|
-
|
|
100
|
-
- `VERIFIED`: directly supported by current local evidence;
|
|
101
|
-
- `CONTRADICTED`: current evidence disproves it;
|
|
102
|
-
- `NOT VERIFIED`: needs external/runtime evidence;
|
|
103
|
-
- `HISTORICAL`: intentionally describes an old state;
|
|
104
|
-
- `OPINION`: product/design intent, not a factual implementation claim.
|
|
105
|
-
|
|
106
|
-
Load [cleanup-rubric.md](references/cleanup-rubric.md) before classification.
|
|
107
|
-
|
|
108
|
-
### 4. Produce the audit report
|
|
109
|
-
|
|
110
|
-
Return:
|
|
111
|
-
|
|
112
|
-
- project root and Git status boundary;
|
|
113
|
-
- files eligible, byte-visited, semantically reviewed, skipped, and failed;
|
|
114
|
-
- current lines/bytes and projected post-clean totals;
|
|
115
|
-
- verdict counts and defensible removal percentage;
|
|
116
|
-
- one concise row per agent-facing Markdown file;
|
|
117
|
-
- contradiction table with exact document and truth-source lines;
|
|
118
|
-
- duplicate/merge clusters and canonical destination;
|
|
119
|
-
- broken local links;
|
|
120
|
-
- protected documents and why they must survive;
|
|
121
|
-
- claims marked `NOT VERIFIED`.
|
|
122
|
-
|
|
123
|
-
Do not create another report Markdown inside the project unless the user explicitly asks for a durable report.
|
|
124
|
-
|
|
125
|
-
## Action: clean
|
|
126
|
-
|
|
127
|
-
Run the complete audit first unless a still-current exhaustive audit exists for the same Git tree. Recheck hashes and `git status`; refresh changed files.
|
|
128
|
-
|
|
129
|
-
Apply verdicts as follows:
|
|
130
|
-
|
|
131
|
-
- `KEEP`: no change.
|
|
132
|
-
- `UPDATE`: make the smallest accurate edit and preserve useful history.
|
|
133
|
-
- `MERGE`: move unique knowledge into the declared canonical file, update inbound links, then `trash` the redundant file.
|
|
134
|
-
- `ARCHIVE`: use only when historical value is real and the repository already has an archive convention.
|
|
135
|
-
- `DELETE`: `trash` only after proving the file is redundant, contradicted without historical value, generated noise, or obsolete execution residue.
|
|
136
|
-
- `VERIFY`: leave unchanged unless the required evidence is obtained.
|
|
137
|
-
|
|
138
|
-
Before modifying any file, obey repository-specific read requirements. If the worktree is dirty, never overwrite overlapping user changes; downgrade that action to `BLOCKED` and continue with disjoint files.
|
|
139
|
-
|
|
140
|
-
After edits:
|
|
23
|
+
The byte ledger must show `visited == eligible`. Then read every eligible file. Over 30 files: disjoint batches of 10–20, one row per path, union equals the manifest.
|
|
141
24
|
|
|
142
|
-
|
|
143
|
-
2. search for references to removed or renamed files;
|
|
144
|
-
3. run proportionate repository validation through its required supervisor;
|
|
145
|
-
4. inspect the final diff and confirm no non-Markdown behavior changed unintentionally;
|
|
146
|
-
5. report exact files updated, merged, archived, trashed, blocked, and untouched.
|
|
25
|
+
Load [cleanup-rubric.md](references/cleanup-rubric.md) before classifying. Verdict each file `KEEP`, `UPDATE`, `MERGE`, `ARCHIVE`, `DELETE`, or `VERIFY`. Mark important claims `VERIFIED`, `CONTRADICTED`, `NOT VERIFIED`, `HISTORICAL`, or `OPINION`.
|
|
147
26
|
|
|
148
|
-
Do not
|
|
27
|
+
Return the root, git boundary, counts, projected totals, one row per file, contradictions with line evidence, merge clusters, broken links, protected files, and `NOT VERIFIED` claims. Do not write a report file unless asked.
|
|
149
28
|
|
|
150
|
-
##
|
|
29
|
+
## Clean
|
|
151
30
|
|
|
152
|
-
|
|
31
|
+
Reuse a still-current exhaustive audit for this Git tree; otherwise re-audit. Recheck hashes and `git status`. Apply verdicts: `KEEP` unchanged; `UPDATE` smallest accurate edit; `MERGE` unique knowledge into the canonical file, fix inbound links, then `trash`; `ARCHIVE` only with an existing archive convention; `DELETE` via `trash` only after a proven replacement or no-value rationale; `VERIFY` unchanged until evidence exists.
|
|
153
32
|
|
|
154
|
-
|
|
33
|
+
If the worktree is dirty, skip overlapping user changes (`BLOCKED`) and continue on disjoint files. After edits: rerun inventory and link checks, search for removed or renamed paths, run proportionate repo validation, confirm the diff is Markdown-only. Do not commit or push unless asked.
|
|
155
34
|
|
|
156
|
-
|
|
157
|
-
- every applied deletion has a proven canonical replacement or explicit no-value rationale;
|
|
158
|
-
- links and references are repaired;
|
|
159
|
-
- protected operational knowledge remains accessible;
|
|
160
|
-
- validation results and blockers are reported separately;
|
|
161
|
-
- the final dirty tree contains no accidental out-of-scope edits.
|
|
35
|
+
Stop `audit` when every eligible file has one evidenced verdict. Stop `clean` when the ledger matches the tree, every deletion has a proven rationale, links are repaired, protected knowledge remains, validation and blockers are reported separately, and the dirty tree has no out-of-scope edits.
|
|
@@ -5,75 +5,16 @@ argument-hint: "[audit|fix] [project-root]"
|
|
|
5
5
|
disable-model-invocation: true
|
|
6
6
|
---
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
Audit skill discovery cost and placement from current files plus observable Codex and Claude session evidence. Treat missing telemetry as uncertainty, not proof that a skill has never been useful.
|
|
11
|
-
|
|
12
|
-
## Invocation guard
|
|
13
|
-
|
|
14
|
-
Proceed only when the current user message explicitly invokes `$audit-skills`.
|
|
15
|
-
|
|
16
|
-
- `$audit-skills audit [project-root]`: produce a read-only audit. This is the default.
|
|
17
|
-
- `$audit-skills fix [project-root]`: audit first, then apply only high-confidence corrections.
|
|
18
|
-
|
|
19
|
-
Resolve `project-root` from the argument or current repository. Preserve unrelated dirty changes and record Git status for every modified repository.
|
|
20
|
-
|
|
21
|
-
## Audit
|
|
22
|
-
|
|
23
|
-
Run the deterministic inventory as a bounded job:
|
|
8
|
+
Proceed only on an explicit `$audit-skills` invocation. Default `audit`; `fix` applies only high-confidence corrections after the ledger exists. Resolve `project-root` from the argument or current repo. Preserve unrelated dirty changes.
|
|
24
9
|
|
|
25
10
|
```bash
|
|
26
|
-
bun ~/.agents/skills/audit-skills/scripts/audit-skills.mjs
|
|
27
|
-
--project "$PWD" \
|
|
28
|
-
--format markdown
|
|
11
|
+
bun ~/.agents/skills/audit-skills/scripts/audit-skills.mjs --project "$PWD" --format markdown
|
|
29
12
|
```
|
|
30
13
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
- explicit user references such as `$skill-name` or `/skill-name`;
|
|
34
|
-
- Claude `Skill` tool calls;
|
|
35
|
-
- agent reads of a matching `SKILL.md`;
|
|
36
|
-
- working directories associated with observed use;
|
|
37
|
-
- Claude `disable-model-invocation` and Codex `policy.allow_implicit_invocation` controls;
|
|
38
|
-
- name collisions and hardcoded project-root references.
|
|
39
|
-
|
|
40
|
-
Report these evidence classes separately:
|
|
41
|
-
|
|
42
|
-
- `OBSERVED_USER`: explicitly named by a user in scanned history;
|
|
43
|
-
- `OBSERVED_MODEL`: loaded or invoked by an agent in scanned history;
|
|
44
|
-
- `UNOBSERVED`: no matching evidence in scanned sources;
|
|
45
|
-
- `EXPLICIT_ONLY`: protected for both Claude and Codex;
|
|
46
|
-
- `INVOCATION_MISMATCH`: protected on only one platform;
|
|
47
|
-
- `LOCALITY_CANDIDATE`: global skill with a project-specific runtime dependency or at least two observed uses confined to one project;
|
|
48
|
-
- `NAME_COLLISION`: same skill name discovered globally and locally.
|
|
49
|
-
|
|
50
|
-
Include scan coverage and limitations. Cursor ACP stores are opaque blobs and are not counted unless a reliable parser becomes available. Never label `UNOBSERVED` as “never used” without naming the scanned time range and sources.
|
|
51
|
-
|
|
52
|
-
## Fix
|
|
53
|
-
|
|
54
|
-
Apply changes only after the audit ledger exists.
|
|
55
|
-
|
|
56
|
-
Safe automatic corrections:
|
|
57
|
-
|
|
58
|
-
1. Mirror an existing explicit-only decision across platforms: add `disable-model-invocation: true` when Codex already blocks implicit invocation, or add `policy.allow_implicit_invocation: false` when Claude already blocks it.
|
|
59
|
-
2. Mark a skill explicit-only when its own instructions already require direct user invocation but one or both platform controls are missing.
|
|
60
|
-
3. Repair metadata made stale by a move or rename.
|
|
61
|
-
|
|
62
|
-
Require explicit user direction or a project-specific runtime dependency before moving a skill between scopes. Multiple uses confined to one project justify review, not automatic relocation; a single observed use is insufficient evidence.
|
|
63
|
-
|
|
64
|
-
When moving a skill:
|
|
65
|
-
|
|
66
|
-
1. copy the complete directory, including scripts, references, assets, and `agents/openai.yaml`;
|
|
67
|
-
2. rewrite absolute self-paths and dependencies to their new canonical locations;
|
|
68
|
-
3. validate the destination before removing the source;
|
|
69
|
-
4. use `trash` for source removal;
|
|
70
|
-
5. search all skill roots and plugin/profile metadata for stale references;
|
|
71
|
-
6. confirm the name is discovered exactly once in the intended scope.
|
|
72
|
-
|
|
73
|
-
For unobserved skills, recommend rather than mutate unless their own text clearly establishes user-only intent. Rarely used incident, security, recovery, and migration skills remain protected from usage-only pruning.
|
|
14
|
+
Report every inventoried skill with scan coverage and one evidence class: `OBSERVED_USER`, `OBSERVED_MODEL`, `UNOBSERVED`, `EXPLICIT_ONLY`, `INVOCATION_MISMATCH`, `LOCALITY_CANDIDATE`, `NAME_COLLISION`. Cursor ACP stores are opaque. Do not label `UNOBSERVED` as never used without naming the scanned range.
|
|
74
15
|
|
|
75
|
-
|
|
16
|
+
Safe automatic fixes: mirror an existing explicit-only decision across Claude/Codex; add missing explicit-only controls when the skill text already requires direct invocation; repair stale move/rename metadata. Move a skill between scopes only with explicit user direction or a project-specific runtime dependency. Copy the full directory, rewrite self-paths, validate, `trash` the source, then confirm the name is discovered once.
|
|
76
17
|
|
|
77
|
-
|
|
18
|
+
Recommend rather than mutate unobserved skills. Protect incident, security, recovery, and migration skills from usage-only pruning.
|
|
78
19
|
|
|
79
|
-
|
|
20
|
+
Done when every skill has a row, every recommendation cites evidence, and — on `fix` — touched skills validate and Git status distinguishes this run.
|