@yogiadhik/skillcheck 0.1.2 → 0.1.3
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 +36 -0
- package/dist/cli.js +1 -1
- package/dist/lint/rules.js +3 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -66,6 +66,42 @@ That runs lint with GitHub annotations on every pull request. For
|
|
|
66
66
|
behavioral runs in CI, call `npx @yogiadhik/skillcheck run` yourself in a job that
|
|
67
67
|
has your agent authenticated; keep a budget flag on it.
|
|
68
68
|
|
|
69
|
+
## what it finds in the wild
|
|
70
|
+
|
|
71
|
+
I periodically run lint across public skill collections — official
|
|
72
|
+
vendor skills, a security firm's suite, several large community
|
|
73
|
+
bundles, close to eight thousand skill files so far. No names,
|
|
74
|
+
because the point is the pattern, and the pattern repeats:
|
|
75
|
+
|
|
76
|
+
- **Skills that silently don't work.** If a skill's frontmatter isn't
|
|
77
|
+
valid YAML, the skill never loads — and nothing tells you. The usual
|
|
78
|
+
cause is an unquoted description containing a colon. Every large
|
|
79
|
+
bundle I've audited shipped a few of these; anyone installing them
|
|
80
|
+
gets a skill that simply never fires.
|
|
81
|
+
- **Instructions pointing at files that don't exist.** Skills tell the
|
|
82
|
+
agent "read references/details.md for the full procedure" and that
|
|
83
|
+
file was never committed. The agent hits a dead end in the middle of
|
|
84
|
+
someone's task. This is the most common hard error.
|
|
85
|
+
- **Sheer size.** The most common warning by a wide margin. Skills
|
|
86
|
+
running twenty to forty thousand tokens re-bill that entire document
|
|
87
|
+
on every single invocation.
|
|
88
|
+
- **Descriptions without trigger language.** The description is the
|
|
89
|
+
only thing the model reads when deciding whether to use a skill; a
|
|
90
|
+
description that doesn't say when to use it is a skill that fires
|
|
91
|
+
rarely and randomly.
|
|
92
|
+
- **Well-maintained collections come back clean.** Several do,
|
|
93
|
+
official and community both. Quality is achievable; it's just not
|
|
94
|
+
the default.
|
|
95
|
+
|
|
96
|
+
Two honest footnotes. First: twice, the loudest "errors" in an audit
|
|
97
|
+
turned out to be this linter's own false positives — links inside
|
|
98
|
+
example code blocks, and templated {baseDir} targets that resolve at
|
|
99
|
+
runtime. Both fixed (0.1.1, 0.1.3), both caught by checking findings
|
|
100
|
+
against the accused code before believing them. Do the same with
|
|
101
|
+
anything this tool tells you. Second: these audits are how skillcheck
|
|
102
|
+
gets tested — every rule here has drawn blood on real files or been
|
|
103
|
+
fixed for crying wolf.
|
|
104
|
+
|
|
69
105
|
## a note on safety
|
|
70
106
|
|
|
71
107
|
`run` executes the agent with permission prompts disabled, inside a
|
package/dist/cli.js
CHANGED
package/dist/lint/rules.js
CHANGED
|
@@ -50,6 +50,9 @@ export const relativeLinks = (s) => {
|
|
|
50
50
|
const target = m[1];
|
|
51
51
|
if (/^(https?:|mailto:|#)/.test(target))
|
|
52
52
|
continue;
|
|
53
|
+
// templated targets like {baseDir}/x.md resolve at runtime; can't judge them
|
|
54
|
+
if (target.includes('{'))
|
|
55
|
+
continue;
|
|
53
56
|
if (!existsSync(resolve(s.dir, target.split('#')[0])))
|
|
54
57
|
out.push(finding(s, 'relative-links', 'error', `broken relative link: ${target}`));
|
|
55
58
|
}
|