agent-skillboard 0.1.1 → 0.2.1
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/CHANGELOG.md +20 -0
- package/README.md +154 -630
- package/docs/adapters.md +96 -96
- package/docs/ai-skill-routing-goal.md +112 -0
- package/docs/capabilities.md +6 -0
- package/docs/install.md +155 -105
- package/docs/plans/skillboard-variant-lifecycle-handoff.md +56 -0
- package/docs/policy-model.md +266 -214
- package/docs/positioning.md +94 -94
- package/docs/reference.md +349 -0
- package/docs/routing.md +85 -0
- package/docs/user-flow.md +75 -16
- package/docs/value-proof.md +190 -0
- package/docs/variant-lifecycle.md +86 -0
- package/docs/versioning.md +157 -138
- package/examples/multi-source-skills/anthropic/docx/SKILL.md +8 -8
- package/examples/multi-source-skills/anthropic/skill-creator/SKILL.md +8 -8
- package/examples/multi-source-skills/matt/grill-me/SKILL.md +8 -8
- package/examples/multi-source-skills/matt/tdd/SKILL.md +8 -8
- package/examples/multi-source-skills/omo/review-work/SKILL.md +8 -8
- package/examples/multi-source-skills/omo/ulw-plan/SKILL.md +8 -8
- package/examples/multi-source-skills/private/tdd-work-continuity/SKILL.md +8 -8
- package/examples/multi-source-skills/private/workflow-router/SKILL.md +8 -8
- package/examples/multi-source-skills/wshobson/python-testing/SKILL.md +8 -8
- package/examples/multi-source-skills/wshobson/security-review/SKILL.md +8 -8
- package/examples/skills/grill-me/SKILL.md +9 -9
- package/examples/skills/grill-with-docs/SKILL.md +9 -9
- package/examples/skills/requirement-intake/SKILL.md +9 -9
- package/examples/skills/tdd/SKILL.md +8 -8
- package/package.json +25 -20
- package/src/advisor/guidance.mjs +232 -0
- package/src/advisor/schema.mjs +2 -0
- package/src/advisor/skills.mjs +2 -0
- package/src/advisor.mjs +36 -7
- package/src/brief-cli.mjs +6 -5
- package/src/brief-renderer.mjs +225 -8
- package/src/cli.mjs +589 -34
- package/src/config-helpers.mjs +34 -18
- package/src/conflicts.mjs +70 -0
- package/src/control/can-use-guard.mjs +8 -3
- package/src/control/skill-crud.mjs +142 -0
- package/src/control/skill-variants.mjs +221 -0
- package/src/control/source-trust.mjs +1 -0
- package/src/control/variant-files.mjs +265 -0
- package/src/control/variant-lifecycle-config.mjs +156 -0
- package/src/control/variant-reset.mjs +171 -0
- package/src/control/variant-status.mjs +75 -0
- package/src/control.mjs +13 -1
- package/src/domain/rules/skills.mjs +60 -0
- package/src/domain/rules/workflows.mjs +13 -0
- package/src/impact.mjs +21 -12
- package/src/index.mjs +13 -1
- package/src/lifecycle-cli.mjs +18 -7
- package/src/lifecycle-content.mjs +29 -22
- package/src/route.mjs +537 -0
- package/src/source-verification.mjs +7 -3
- package/src/workspace.mjs +141 -43
- package/tsconfig.lsp.json +1 -1
package/docs/versioning.md
CHANGED
|
@@ -1,117 +1,118 @@
|
|
|
1
|
-
# Versioning
|
|
2
|
-
|
|
3
|
-
SkillBoard has several versioned surfaces. They should not all move at the same
|
|
4
|
-
pace, and not every skill file belongs in central version control.
|
|
5
|
-
|
|
1
|
+
# Versioning
|
|
2
|
+
|
|
3
|
+
SkillBoard has several versioned surfaces. They should not all move at the same
|
|
4
|
+
pace, and not every skill file belongs in central version control.
|
|
5
|
+
|
|
6
6
|
This document defines the public alpha policy for releases, config compatibility,
|
|
7
7
|
source profiles, and the generated lockfile.
|
|
8
|
-
|
|
9
|
-
## Status
|
|
10
|
-
|
|
11
|
-
Current package version: `0.
|
|
12
|
-
|
|
13
|
-
Current config schema version:
|
|
14
|
-
|
|
15
|
-
```yaml
|
|
16
|
-
version: 1
|
|
17
|
-
```
|
|
18
|
-
|
|
19
|
-
The project is a public alpha. Breaking changes are allowed before `1.0.0`, but
|
|
20
|
-
they must be documented in release notes and should include a migration note when
|
|
21
|
-
they affect user config.
|
|
22
|
-
|
|
23
|
-
## Versioned Surfaces
|
|
24
|
-
|
|
25
|
-
SkillBoard versions these surfaces deliberately:
|
|
26
|
-
|
|
27
|
-
- CLI package version: the npm package and command behavior.
|
|
28
|
-
- Config schema version: the top-level `version` field in
|
|
29
|
-
`skillboard.config.yaml`.
|
|
30
|
-
- Source profile format: YAML files under `profiles/` and project-specific
|
|
31
|
-
`.skillboard/profiles/`.
|
|
32
|
-
- Workflow contracts: workflow names, required capabilities, active skill pools,
|
|
33
|
-
required outputs, and harness choices.
|
|
34
|
-
- Capability contracts: canonical skill, alternatives, and default policy for a
|
|
35
|
-
capability.
|
|
36
|
-
- Exported skill entries: shared or vendor skills governed by SkillBoard.
|
|
37
|
-
- Install-unit entries: plugin, marketplace, package, harness, MCP, hook, agent,
|
|
38
|
-
and LSP sources.
|
|
8
|
+
|
|
9
|
+
## Status
|
|
10
|
+
|
|
11
|
+
Current package version: `0.2.1`
|
|
12
|
+
|
|
13
|
+
Current config schema version:
|
|
14
|
+
|
|
15
|
+
```yaml
|
|
16
|
+
version: 1
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
The project is a public alpha. Breaking changes are allowed before `1.0.0`, but
|
|
20
|
+
they must be documented in release notes and should include a migration note when
|
|
21
|
+
they affect user config.
|
|
22
|
+
|
|
23
|
+
## Versioned Surfaces
|
|
24
|
+
|
|
25
|
+
SkillBoard versions these surfaces deliberately:
|
|
26
|
+
|
|
27
|
+
- CLI package version: the npm package and command behavior.
|
|
28
|
+
- Config schema version: the top-level `version` field in
|
|
29
|
+
`skillboard.config.yaml`.
|
|
30
|
+
- Source profile format: YAML files under `profiles/` and project-specific
|
|
31
|
+
`.skillboard/profiles/`.
|
|
32
|
+
- Workflow contracts: workflow names, required capabilities, active skill pools,
|
|
33
|
+
required outputs, and harness choices.
|
|
34
|
+
- Capability contracts: canonical skill, alternatives, and default policy for a
|
|
35
|
+
capability.
|
|
36
|
+
- Exported skill entries: shared or vendor skills governed by SkillBoard.
|
|
37
|
+
- Install-unit entries: plugin, marketplace, package, harness, MCP, hook, agent,
|
|
38
|
+
and LSP sources.
|
|
39
39
|
- Lockfile data: pinned source/cache digest, skill content digests, policy, and
|
|
40
40
|
compatible harnesses.
|
|
41
|
-
|
|
42
|
-
SkillBoard does not try to centrally version every prompt or helper skill. A
|
|
43
|
-
workflow-internal private skill can remain inside that workflow package until it
|
|
44
|
-
becomes shared, auto-invokable, vendor-provided, or cross-workflow.
|
|
45
|
-
|
|
46
|
-
## Release Versioning
|
|
47
|
-
|
|
48
|
-
The package follows SemVer with a stricter alpha convention:
|
|
49
|
-
|
|
50
|
-
- Patch: bug fixes, docs, new tests, safer validation, and non-breaking profile
|
|
51
|
-
additions.
|
|
52
|
-
- Minor: new commands, new config fields with safe defaults, new report sections,
|
|
53
|
-
new built-in source profiles, and new policy checks that are warnings first.
|
|
54
|
-
- Major: post-`1.0.0` breaking CLI, config, or policy behavior.
|
|
55
|
-
|
|
56
|
-
Before `1.0.0`, breaking changes may happen in minor releases, but the changelog
|
|
57
|
-
must call them out clearly.
|
|
58
|
-
|
|
41
|
+
|
|
42
|
+
SkillBoard does not try to centrally version every prompt or helper skill. A
|
|
43
|
+
workflow-internal private skill can remain inside that workflow package until it
|
|
44
|
+
becomes shared, auto-invokable, vendor-provided, or cross-workflow.
|
|
45
|
+
|
|
46
|
+
## Release Versioning
|
|
47
|
+
|
|
48
|
+
The package follows SemVer with a stricter alpha convention:
|
|
49
|
+
|
|
50
|
+
- Patch: bug fixes, docs, new tests, safer validation, and non-breaking profile
|
|
51
|
+
additions.
|
|
52
|
+
- Minor: new commands, new config fields with safe defaults, new report sections,
|
|
53
|
+
new built-in source profiles, and new policy checks that are warnings first.
|
|
54
|
+
- Major: post-`1.0.0` breaking CLI, config, or policy behavior.
|
|
55
|
+
|
|
56
|
+
Before `1.0.0`, breaking changes may happen in minor releases, but the changelog
|
|
57
|
+
must call them out clearly.
|
|
58
|
+
|
|
59
59
|
Suggested tags:
|
|
60
60
|
|
|
61
61
|
- `v0.1.0-alpha`: first public GitHub alpha.
|
|
62
|
-
- `v0.2.
|
|
62
|
+
- `v0.2.1`: ask-after skill routing, README benefit-first positioning,
|
|
63
|
+
source inventory refresh, doctor/status, source pin refresh,
|
|
63
64
|
installer/config detection, resilient detector warnings, and richer dry-run
|
|
64
65
|
plans.
|
|
65
66
|
- `v0.3.0-alpha`: signed remote source verification hardening and migration
|
|
66
67
|
workflow.
|
|
67
68
|
- `v1.0.0`: config schema and core CLI behavior are stable enough for external
|
|
68
69
|
workflows to rely on.
|
|
69
|
-
|
|
70
|
-
## Config Schema Version
|
|
71
|
-
|
|
72
|
-
The top-level `version` field is the schema version, not the package version.
|
|
73
|
-
|
|
74
|
-
Rules:
|
|
75
|
-
|
|
76
|
-
- `version: 1` is the only supported schema today.
|
|
77
|
-
- Missing `version` is treated as `1` for early compatibility.
|
|
78
|
-
- Unsupported future versions must fail fast rather than silently parsing with
|
|
79
|
-
older semantics.
|
|
80
|
-
- New fields should default to the safest behavior.
|
|
81
|
-
- New automatic invocation behavior must be opt-in.
|
|
82
|
-
- New policy checks should start as warnings unless they protect an important
|
|
83
|
-
safety boundary.
|
|
84
|
-
|
|
85
|
-
Breaking schema changes need a migration note. A future `skillboard migrate`
|
|
86
|
-
command can automate those changes, but it is not implemented yet.
|
|
87
|
-
|
|
88
|
-
## Source Profile Versioning
|
|
89
|
-
|
|
90
|
-
Source profiles are data, not hardcoded adapter branches. Built-in profiles live
|
|
91
|
-
under `profiles/`; project profiles can live under `.skillboard/profiles/`.
|
|
92
|
-
|
|
93
|
-
Profile compatibility rules:
|
|
94
|
-
|
|
95
|
-
- Adding a new built-in profile is a patch or minor change.
|
|
96
|
-
- Changing a built-in profile's namespace, target path prefix, default status,
|
|
97
|
-
default invocation, or default exposure is a breaking profile behavior change.
|
|
98
|
-
- External profiles should not grant `global-auto` unless they also mark the
|
|
99
|
-
imported skills as `global-meta`.
|
|
100
|
-
- External repository skills should normally import as `vendor`, `candidate`, or
|
|
101
|
-
`quarantined`, with `manual-only` or `router-only` invocation.
|
|
102
|
-
- Harness/plugin bundle profiles should use `unit-managed` for child skills when
|
|
103
|
-
the parent bundle owns commands, hooks, MCP servers, or config mutation.
|
|
104
|
-
|
|
105
|
-
Profile imports can be reviewed as fragments or merged directly:
|
|
106
|
-
|
|
107
|
-
```bash
|
|
108
|
-
skillboard import \
|
|
109
|
-
--profile github.mattpocock.skills \
|
|
110
|
-
--source-root /path/to/source \
|
|
111
|
-
--out .skillboard/reports/import-fragment.yaml
|
|
112
|
-
```
|
|
113
|
-
|
|
114
|
-
```bash
|
|
70
|
+
|
|
71
|
+
## Config Schema Version
|
|
72
|
+
|
|
73
|
+
The top-level `version` field is the schema version, not the package version.
|
|
74
|
+
|
|
75
|
+
Rules:
|
|
76
|
+
|
|
77
|
+
- `version: 1` is the only supported schema today.
|
|
78
|
+
- Missing `version` is treated as `1` for early compatibility.
|
|
79
|
+
- Unsupported future versions must fail fast rather than silently parsing with
|
|
80
|
+
older semantics.
|
|
81
|
+
- New fields should default to the safest behavior.
|
|
82
|
+
- New automatic invocation behavior must be opt-in.
|
|
83
|
+
- New policy checks should start as warnings unless they protect an important
|
|
84
|
+
safety boundary.
|
|
85
|
+
|
|
86
|
+
Breaking schema changes need a migration note. A future `skillboard migrate`
|
|
87
|
+
command can automate those changes, but it is not implemented yet.
|
|
88
|
+
|
|
89
|
+
## Source Profile Versioning
|
|
90
|
+
|
|
91
|
+
Source profiles are data, not hardcoded adapter branches. Built-in profiles live
|
|
92
|
+
under `profiles/`; project profiles can live under `.skillboard/profiles/`.
|
|
93
|
+
|
|
94
|
+
Profile compatibility rules:
|
|
95
|
+
|
|
96
|
+
- Adding a new built-in profile is a patch or minor change.
|
|
97
|
+
- Changing a built-in profile's namespace, target path prefix, default status,
|
|
98
|
+
default invocation, or default exposure is a breaking profile behavior change.
|
|
99
|
+
- External profiles should not grant `global-auto` unless they also mark the
|
|
100
|
+
imported skills as `global-meta`.
|
|
101
|
+
- External repository skills should normally import as `vendor`, `candidate`, or
|
|
102
|
+
`quarantined`, with `manual-only` or `router-only` invocation.
|
|
103
|
+
- Harness/plugin bundle profiles should use `unit-managed` for child skills when
|
|
104
|
+
the parent bundle owns commands, hooks, MCP servers, or config mutation.
|
|
105
|
+
|
|
106
|
+
Profile imports can be reviewed as fragments or merged directly:
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
skillboard import \
|
|
110
|
+
--profile github.mattpocock.skills \
|
|
111
|
+
--source-root /path/to/source \
|
|
112
|
+
--out .skillboard/reports/import-fragment.yaml
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
```bash
|
|
115
116
|
skillboard import \
|
|
116
117
|
--profile github.mattpocock.skills \
|
|
117
118
|
--source-root /path/to/source \
|
|
@@ -123,33 +124,33 @@ skillboard import \
|
|
|
123
124
|
`--merge` is append-only by default. `--replace` is required to overwrite
|
|
124
125
|
existing skill or install-unit ids. Drop `--dry-run` only after reviewing the
|
|
125
126
|
reported text and YAML semantic change plan.
|
|
126
|
-
|
|
127
|
-
## Workflow And Capability Versioning
|
|
128
|
-
|
|
129
|
-
The primary unit of compatibility is the workflow, not an individual skill.
|
|
130
|
-
|
|
131
|
-
Version these centrally:
|
|
132
|
-
|
|
133
|
-
- workflow name and intent;
|
|
134
|
-
- harness and fallback harness assumptions;
|
|
135
|
-
- required capabilities;
|
|
136
|
-
- active, blocked, and manual-only skill pools;
|
|
137
|
-
- required outputs;
|
|
138
|
-
- exported skill contracts used by more than one workflow;
|
|
139
|
-
- policy decisions that allow automatic invocation.
|
|
140
|
-
|
|
141
|
-
Avoid central versioning for:
|
|
142
|
-
|
|
143
|
-
- one-off prompts;
|
|
144
|
-
- workflow-internal helper skills;
|
|
145
|
-
- private skills used by only one workflow;
|
|
146
|
-
- temporary templates that are not auto-invokable;
|
|
147
|
-
- implementation details inside a harness bundle.
|
|
148
|
-
|
|
149
|
-
When a workflow changes its required outputs, required capabilities, or
|
|
150
|
-
workflow-auto skill set, treat it as a compatibility change even if no file paths
|
|
151
|
-
changed.
|
|
152
|
-
|
|
127
|
+
|
|
128
|
+
## Workflow And Capability Versioning
|
|
129
|
+
|
|
130
|
+
The primary unit of compatibility is the workflow, not an individual skill.
|
|
131
|
+
|
|
132
|
+
Version these centrally:
|
|
133
|
+
|
|
134
|
+
- workflow name and intent;
|
|
135
|
+
- harness and fallback harness assumptions;
|
|
136
|
+
- required capabilities;
|
|
137
|
+
- active, blocked, and manual-only skill pools;
|
|
138
|
+
- required outputs;
|
|
139
|
+
- exported skill contracts used by more than one workflow;
|
|
140
|
+
- policy decisions that allow automatic invocation.
|
|
141
|
+
|
|
142
|
+
Avoid central versioning for:
|
|
143
|
+
|
|
144
|
+
- one-off prompts;
|
|
145
|
+
- workflow-internal helper skills;
|
|
146
|
+
- private skills used by only one workflow;
|
|
147
|
+
- temporary templates that are not auto-invokable;
|
|
148
|
+
- implementation details inside a harness bundle.
|
|
149
|
+
|
|
150
|
+
When a workflow changes its required outputs, required capabilities, or
|
|
151
|
+
workflow-auto skill set, treat it as a compatibility change even if no file paths
|
|
152
|
+
changed.
|
|
153
|
+
|
|
153
154
|
## Lockfile Policy
|
|
154
155
|
|
|
155
156
|
`skillboard lock write` generates `skillboard.lock.yaml` from the current
|
|
@@ -176,7 +177,7 @@ the current working directory, so bundled examples can use project-root-relative
|
|
|
176
177
|
paths while project configs can still keep config-local paths.
|
|
177
178
|
`skillboard lock write` refuses to write when verification has errors unless
|
|
178
179
|
`--allow-unverified` is passed explicitly for investigation artifacts.
|
|
179
|
-
|
|
180
|
+
|
|
180
181
|
## Release Checklist
|
|
181
182
|
|
|
182
183
|
Before tagging a public release:
|
|
@@ -187,15 +188,13 @@ Before tagging a public release:
|
|
|
187
188
|
- Run at least one CLI smoke test through the public surface.
|
|
188
189
|
- Confirm docs mention any breaking config, profile, or CLI changes.
|
|
189
190
|
- Update package version and release notes.
|
|
190
|
-
- Confirm
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
- Push a version tag that exactly matches `package.json`, for example `v0.1.1`
|
|
198
|
-
for package version `0.1.1`.
|
|
191
|
+
- Confirm the repository `NPM_TOKEN` secret can publish `agent-skillboard`.
|
|
192
|
+
The publish job uses that token for npm authentication and requests
|
|
193
|
+
provenance with GitHub Actions OIDC, so keep `permissions.id-token: write`,
|
|
194
|
+
the npm registry URL in `setup-node`, and
|
|
195
|
+
`NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}` on the publish step.
|
|
196
|
+
- Push a version tag that exactly matches `package.json`, for example `v0.2.1`
|
|
197
|
+
for package version `0.2.1`.
|
|
199
198
|
- Let `.github/workflows/publish.yml` publish from the tag. The workflow runs
|
|
200
199
|
the full check suite, validates that the tag matches the package version, and
|
|
201
200
|
skips `npm publish` only when that exact version already exists on npm.
|
|
@@ -220,3 +219,23 @@ completion notes:
|
|
|
220
219
|
without generating user-visible `-2` suffixes;
|
|
221
220
|
- README and install docs include a Hermes system prompt bridge for profiles
|
|
222
221
|
that do not automatically read `AGENTS.md` or `CLAUDE.md`.
|
|
222
|
+
|
|
223
|
+
## 0.1.2 Completion Notes
|
|
224
|
+
|
|
225
|
+
- add `--version` and `-v` flags to the CLI for fast version verification in
|
|
226
|
+
npm, global, source-tree, and tarball installs;
|
|
227
|
+
- add a dedicated test for the version flags;
|
|
228
|
+
- update README quick-start to verify the installed version before running
|
|
229
|
+
policy commands.
|
|
230
|
+
|
|
231
|
+
## 0.2.1 Completion Notes
|
|
232
|
+
|
|
233
|
+
- add ask-after route policy suggestions for safe ambiguous workflow skill
|
|
234
|
+
matches while preserving the public route JSON contract;
|
|
235
|
+
- carry route candidate guard and capability roles into AI-facing brief
|
|
236
|
+
guidance;
|
|
237
|
+
- keep no-match and guard-denied routes free of use disclosures or post-use
|
|
238
|
+
policy suggestions;
|
|
239
|
+
- update README positioning around user benefit, no-global-install usage,
|
|
240
|
+
read-only normal checks, explicit approval for policy changes, and
|
|
241
|
+
conservative previewable cleanup.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: anthropic.docx
|
|
3
|
-
description: Create and edit Word documents.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Anthropic DOCX
|
|
7
|
-
|
|
8
|
-
Document workflow skill.
|
|
1
|
+
---
|
|
2
|
+
name: anthropic.docx
|
|
3
|
+
description: Create and edit Word documents.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Anthropic DOCX
|
|
7
|
+
|
|
8
|
+
Document workflow skill.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: anthropic.skill-creator
|
|
3
|
-
description: Create Agent Skills with the standard skill structure.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Anthropic Skill Creator
|
|
7
|
-
|
|
8
|
-
Reference skill authoring workflow.
|
|
1
|
+
---
|
|
2
|
+
name: anthropic.skill-creator
|
|
3
|
+
description: Create Agent Skills with the standard skill structure.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Anthropic Skill Creator
|
|
7
|
+
|
|
8
|
+
Reference skill authoring workflow.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matt.grill-me
|
|
3
|
-
description: Clarify vague requirements before implementation.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matt Grill Me
|
|
7
|
-
|
|
8
|
-
Vendor requirement clarification skill.
|
|
1
|
+
---
|
|
2
|
+
name: matt.grill-me
|
|
3
|
+
description: Clarify vague requirements before implementation.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matt Grill Me
|
|
7
|
+
|
|
8
|
+
Vendor requirement clarification skill.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matt.tdd
|
|
3
|
-
description: Run test-driven implementation loops.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matt TDD
|
|
7
|
-
|
|
8
|
-
Vendor TDD workflow skill.
|
|
1
|
+
---
|
|
2
|
+
name: matt.tdd
|
|
3
|
+
description: Run test-driven implementation loops.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matt TDD
|
|
7
|
+
|
|
8
|
+
Vendor TDD workflow skill.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: omo.review-work
|
|
3
|
-
description: Review completed implementation work with strict verification.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# OMO Review Work
|
|
7
|
-
|
|
8
|
-
Harness-owned post-implementation review skill.
|
|
1
|
+
---
|
|
2
|
+
name: omo.review-work
|
|
3
|
+
description: Review completed implementation work with strict verification.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# OMO Review Work
|
|
7
|
+
|
|
8
|
+
Harness-owned post-implementation review skill.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: omo.ulw-plan
|
|
3
|
-
description: Plan complex work in a LazyCodex harness.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# OMO ULW Plan
|
|
7
|
-
|
|
8
|
-
Harness-owned planning skill.
|
|
1
|
+
---
|
|
2
|
+
name: omo.ulw-plan
|
|
3
|
+
description: Plan complex work in a LazyCodex harness.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# OMO ULW Plan
|
|
7
|
+
|
|
8
|
+
Harness-owned planning skill.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: private.tdd-work-continuity
|
|
3
|
-
description: Keep local TDD work resumable with plan and verification notes.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Private TDD Work Continuity
|
|
7
|
-
|
|
8
|
-
Maintain continuity for project-specific engineering workflows.
|
|
1
|
+
---
|
|
2
|
+
name: private.tdd-work-continuity
|
|
3
|
+
description: Keep local TDD work resumable with plan and verification notes.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Private TDD Work Continuity
|
|
7
|
+
|
|
8
|
+
Maintain continuity for project-specific engineering workflows.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: private.workflow-router
|
|
3
|
-
description: Route incoming work to the correct workflow before exposing specialized skills.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Private Workflow Router
|
|
7
|
-
|
|
8
|
-
Keep global routing small and explicit.
|
|
1
|
+
---
|
|
2
|
+
name: private.workflow-router
|
|
3
|
+
description: Route incoming work to the correct workflow before exposing specialized skills.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Private Workflow Router
|
|
7
|
+
|
|
8
|
+
Keep global routing small and explicit.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: wshobson.python-testing
|
|
3
|
-
description: Python testing workflow skill.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Wshobson Python Testing
|
|
7
|
-
|
|
8
|
-
Marketplace skill for Python test workflows.
|
|
1
|
+
---
|
|
2
|
+
name: wshobson.python-testing
|
|
3
|
+
description: Python testing workflow skill.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Wshobson Python Testing
|
|
7
|
+
|
|
8
|
+
Marketplace skill for Python test workflows.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: wshobson.security-review
|
|
3
|
-
description: Security review workflow skill.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Wshobson Security Review
|
|
7
|
-
|
|
8
|
-
Marketplace skill for security review workflows.
|
|
1
|
+
---
|
|
2
|
+
name: wshobson.security-review
|
|
3
|
+
description: Security review workflow skill.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Wshobson Security Review
|
|
7
|
+
|
|
8
|
+
Marketplace skill for security review workflows.
|
|
@@ -1,9 +1,9 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: grill-me
|
|
3
|
-
description: Ask strict clarifying questions before work begins.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Grill Me
|
|
7
|
-
|
|
8
|
-
Vendor skill kept for manual comparison. It is blocked in the sample night
|
|
9
|
-
workflow because `requirement-intake` is canonical.
|
|
1
|
+
---
|
|
2
|
+
name: grill-me
|
|
3
|
+
description: Ask strict clarifying questions before work begins.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Grill Me
|
|
7
|
+
|
|
8
|
+
Vendor skill kept for manual comparison. It is blocked in the sample night
|
|
9
|
+
workflow because `requirement-intake` is canonical.
|
|
@@ -1,9 +1,9 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matt.grill-with-docs
|
|
3
|
-
description: Requirement clarification that also updates durable project docs.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Grill With Docs
|
|
7
|
-
|
|
8
|
-
Use only when a workflow explicitly allows requirements clarification that
|
|
9
|
-
changes durable project documentation.
|
|
1
|
+
---
|
|
2
|
+
name: matt.grill-with-docs
|
|
3
|
+
description: Requirement clarification that also updates durable project docs.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Grill With Docs
|
|
7
|
+
|
|
8
|
+
Use only when a workflow explicitly allows requirements clarification that
|
|
9
|
+
changes durable project documentation.
|
|
@@ -1,9 +1,9 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: requirement-intake
|
|
3
|
-
description: Route vague feature requests into clear requirements, open questions, and implementation-ready scope.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Requirement Intake
|
|
7
|
-
|
|
8
|
-
Use when a task needs clarification before implementation. Produce a short
|
|
9
|
-
decision brief, unresolved owner decisions, and a suggested workflow.
|
|
1
|
+
---
|
|
2
|
+
name: requirement-intake
|
|
3
|
+
description: Route vague feature requests into clear requirements, open questions, and implementation-ready scope.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Requirement Intake
|
|
7
|
+
|
|
8
|
+
Use when a task needs clarification before implementation. Produce a short
|
|
9
|
+
decision brief, unresolved owner decisions, and a suggested workflow.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: tdd
|
|
3
|
-
description: Drive coding tasks through failing-first tests, implementation, and verification.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# TDD
|
|
7
|
-
|
|
8
|
-
Use when implementation work needs a red-green verification loop.
|
|
1
|
+
---
|
|
2
|
+
name: tdd
|
|
3
|
+
description: Drive coding tasks through failing-first tests, implementation, and verification.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# TDD
|
|
7
|
+
|
|
8
|
+
Use when implementation work needs a red-green verification loop.
|
package/package.json
CHANGED
|
@@ -1,10 +1,13 @@
|
|
|
1
|
-
{
|
|
1
|
+
{
|
|
2
2
|
"name": "agent-skillboard",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "0.2.1",
|
|
4
|
+
"description": "Let AI agents pick and use allowed skills in each workflow.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai-agent",
|
|
7
|
+
"agent-skills",
|
|
7
8
|
"skills",
|
|
9
|
+
"skill-routing",
|
|
10
|
+
"workflow",
|
|
8
11
|
"codex",
|
|
9
12
|
"claude-code",
|
|
10
13
|
"policy"
|
|
@@ -21,11 +24,13 @@
|
|
|
21
24
|
"files": [
|
|
22
25
|
"bin",
|
|
23
26
|
"src",
|
|
24
|
-
"docs",
|
|
27
|
+
"docs/*.md",
|
|
28
|
+
"docs/plans",
|
|
25
29
|
"examples",
|
|
26
30
|
"profiles",
|
|
27
31
|
"README.md",
|
|
28
32
|
"CONTRIBUTING.md",
|
|
33
|
+
"CHANGELOG.md",
|
|
29
34
|
"LICENSE",
|
|
30
35
|
"tsconfig.lsp.json"
|
|
31
36
|
],
|
|
@@ -33,9 +38,9 @@
|
|
|
33
38
|
"skillboard": "bin/skillboard.mjs",
|
|
34
39
|
"agent-skillboard": "bin/skillboard.mjs"
|
|
35
40
|
},
|
|
36
|
-
"publishConfig": {
|
|
37
|
-
"access": "public"
|
|
38
|
-
},
|
|
41
|
+
"publishConfig": {
|
|
42
|
+
"access": "public"
|
|
43
|
+
},
|
|
39
44
|
"scripts": {
|
|
40
45
|
"test": "node --test",
|
|
41
46
|
"test:unit": "node --test test/advisor-brief-actions.test.mjs test/advisor-brief.test.mjs test/ecosystem-docs.test.mjs test/install-units.test.mjs test/package.test.mjs test/policy.test.mjs test/skillboard.test.mjs",
|
|
@@ -43,16 +48,16 @@
|
|
|
43
48
|
"diagnostics": "tsc -p tsconfig.lsp.json",
|
|
44
49
|
"check": "node --check bin/skillboard.mjs && npm run diagnostics && node --test"
|
|
45
50
|
},
|
|
46
|
-
"dependencies": {
|
|
47
|
-
"yaml": "^2.8.1"
|
|
48
|
-
},
|
|
49
|
-
"engines": {
|
|
50
|
-
"node": ">=20"
|
|
51
|
-
},
|
|
52
|
-
"license": "MIT",
|
|
53
|
-
"devDependencies": {
|
|
54
|
-
"@types/node": "^26.0.0",
|
|
55
|
-
"typescript": "^6.0.3",
|
|
56
|
-
"typescript-language-server": "^5.3.0"
|
|
57
|
-
}
|
|
58
|
-
}
|
|
51
|
+
"dependencies": {
|
|
52
|
+
"yaml": "^2.8.1"
|
|
53
|
+
},
|
|
54
|
+
"engines": {
|
|
55
|
+
"node": ">=20"
|
|
56
|
+
},
|
|
57
|
+
"license": "MIT",
|
|
58
|
+
"devDependencies": {
|
|
59
|
+
"@types/node": "^26.0.0",
|
|
60
|
+
"typescript": "^6.0.3",
|
|
61
|
+
"typescript-language-server": "^5.3.0"
|
|
62
|
+
}
|
|
63
|
+
}
|