cyber-agentkit 1.1.0 → 2.0.0
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/.claude-plugin/plugin.json +1 -1
- package/.codex-plugin/plugin.json +1 -1
- package/.cursor-plugin/plugin.json +1 -1
- package/CHANGELOG.md +181 -0
- package/dist/cli.js +8668 -4165
- package/dist/commands.d.ts +159 -87
- package/dist/commands.js +1099 -838
- package/dist/index.d.ts +426 -70
- package/dist/index.js +608 -22
- package/dist/reference-where-BsBpwLyg.d.ts +735 -0
- package/dist/{reference-where-C84J6MsR.js → reference-where-CVmGFOwR.js} +5468 -1864
- package/package.json +3 -2
- package/plugin.json +3 -2
- package/readme.md +59 -26
- package/skills/asset/scripts/asset.mjs +95 -61
- package/skills/prose-update/README.md +24 -0
- package/skills/prose-update/SKILL.md +58 -0
- package/skills/prose-update/scripts/prose-update.mjs +233 -0
- package/skills/reference/README.md +7 -7
- package/skills/reference/SKILL.md +64 -58
- package/skills/reference/references/create.md +29 -24
- package/skills/reference/references/customize.md +82 -0
- package/skills/reference/references/load.md +58 -37
- package/skills/reference/scripts/reference.mjs +95 -61
- package/dist/resolve-reference-D62VJZc0.d.ts +0 -246
|
@@ -1,16 +1,16 @@
|
|
|
1
1
|
# Reference
|
|
2
2
|
|
|
3
|
-
Loads,
|
|
3
|
+
Loads, finds, inspects, creates, customizes, and deletes [references](https://cyber-uni.github.io/cyber-agentkit/concepts/reference-documents/): Markdown documents (or JSON, YAML, TOML, or text files, which are never merged) an agent reads on demand by name. It routes each request to the `reference` command, run from a launcher bundled in `scripts/`, and writes or deletes a reference only after the user approves it. Type `/reference` to run it yourself. Installed as a Claude Code plugin, it is `/cyber-agentkit:reference` (pnpm install: `pnpm-cyber-agentkit-reference`). Installed with pnpm, it is `pnpm-cyber-agentkit-reference`.
|
|
4
4
|
|
|
5
5
|
| Mode | When |
|
|
6
6
|
| --- | --- |
|
|
7
|
-
| Load | a skill's instructions name references, or an interface whose implementations, to load with this skill |
|
|
8
|
-
| Create | writing a new reference for a project, a user, a plugin (`<plugin name>.<reference>.md`), or a skill's default (`<name>.default.md`); an implementation of an interface is `<id>.<key>.md` |
|
|
9
|
-
| Update | changing a reference: the user's own in place, a plugin's by a customization that patches it |
|
|
10
|
-
| Select | choosing which plugins, or the skill's default, a name builds on, which settles an ambiguous name |
|
|
11
|
-
| Delete | removing a project or user contribution, saying first what answers the name afterwards |
|
|
7
|
+
| Load | a skill's instructions name references, or an interface whose implementations, to load with this skill; it acts on each status and warning, and follows project sections for the folder the work is in |
|
|
12
8
|
| Find | `search` for a topic, `list` every reference, or `implementations` of an interface |
|
|
13
|
-
| Inspect | `
|
|
9
|
+
| Inspect | `load`; `load --trace` for how a name composed; `where` for the files a customization goes to; `check` against an interface |
|
|
10
|
+
| Create | writing a new reference from given text, for the repository, a folder, the user, a plugin (`<plugin name>.<reference>.md`), or a skill's default (`<name>.default.md`), or stubbing an interface; it shows where each section came from and offers the full document |
|
|
11
|
+
| Update | editing the user's own hand-written file in place |
|
|
12
|
+
| Customize | picking what a name builds on, changing its prose by request through a generator subagent, implementing an interface by request, or revising a stale generated document |
|
|
13
|
+
| Delete | removing a repo, user, or project-section contribution, saying first what answers the name afterwards |
|
|
14
14
|
| Wire a skill | giving a skill the line below |
|
|
15
15
|
|
|
16
16
|
It ships in the `cyber-agentkit` plugin:
|
|
@@ -1,28 +1,33 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: reference
|
|
3
|
-
description: Use this skill when loading, creating, updating, deleting, finding, or inspecting a reference
|
|
3
|
+
description: Use this skill when loading, creating, customizing, updating, deleting, finding, or inspecting a reference (a document agents read by name, Markdown or a JSON, YAML, TOML, or text file), or when wiring a skill to load one.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Reference
|
|
7
7
|
|
|
8
|
-
Route the request to one mode, then follow that mode.
|
|
8
|
+
Route the request to one mode, then follow that mode.
|
|
9
|
+
|
|
10
|
+
A **reference** is a document read by name. Each place that holds a **contribution** to a name is a **tier**:
|
|
11
|
+
|
|
12
|
+
- the plugins that ship the name, and the loading skill's **default** (`references/<name>.default.md` in its folder). They form the stack, bottom first, in the order `extends` gives.
|
|
13
|
+
- `user`: `~/.agents/references/`, for one person in every repository. It applies over the stack.
|
|
14
|
+
- `repo`: `.agents/references/` at the repository root, for everyone working in it. It applies over `user`.
|
|
15
|
+
- a **project section**: `.agents/references/<name>.md` in a folder below the root. It states only what differs for work in that folder, and follows the main document.
|
|
16
|
+
- `managed`: an admin's folder for the running harness. It applies over the main document and over each project section.
|
|
17
|
+
|
|
18
|
+
Each contribution applies with its `merge`: `patch` (the default) replaces the text a section matches, `combine` adds after it, `replace` drops everything below, and `remove` turns the name off. An **interface** is a contract, declared in a `<id>.interface` reference, that other references implement. What answers a name is the `reference` command's decision. Never decide it by reading tier folders yourself.
|
|
9
19
|
|
|
10
20
|
## Route
|
|
11
21
|
|
|
12
22
|
| The request | Mode |
|
|
13
23
|
| --- | --- |
|
|
14
|
-
| a skill's instructions name references to load with this skill | [Load](#load) |
|
|
15
|
-
| a
|
|
16
|
-
|
|
|
17
|
-
| write a reference
|
|
18
|
-
|
|
|
19
|
-
| choose
|
|
20
|
-
| remove a
|
|
21
|
-
| find a reference for a topic, or see which ones exist | [Find](#find) |
|
|
22
|
-
| find the implementations of an interface | [Find](#find) |
|
|
23
|
-
| check that references have the shape their interface requires | [Inspect](#inspect) |
|
|
24
|
-
| see a reference, or learn why a name composed as it did | [Inspect](#inspect) |
|
|
25
|
-
| learn where a customization of a reference goes | [Inspect](#inspect) |
|
|
24
|
+
| a skill's instructions name references, or an interface's implementations, to load with this skill | [Load](#load) |
|
|
25
|
+
| find a reference for a topic, list them, or list an interface's implementations | [Find](#find) |
|
|
26
|
+
| read a reference, learn why it composed as it did, where a customization goes, or check it against its interface | [Inspect](#inspect) |
|
|
27
|
+
| write a new reference from text the author gives: for the repository, the user, a plugin to ship, or a skill's default; or stub an interface | [Create](#create) |
|
|
28
|
+
| edit the user's own reference file in place | [Update](#update) |
|
|
29
|
+
| choose what a name builds on, settle an ambiguous name, change what a reference says, or revise a stale one | [Customize](#customize) |
|
|
30
|
+
| remove a repo, user, or project-section contribution | [Delete](#delete) |
|
|
26
31
|
| make a skill load a reference | [Wire a skill](#wire-a-skill) |
|
|
27
32
|
|
|
28
33
|
Ask only when the request fits two modes. Otherwise pick one; outside Load, say which. Invoked as `/reference` with no request, run `list` from [Find](#find) and ask what to do with one.
|
|
@@ -30,80 +35,81 @@ Ask only when the request fits two modes. Otherwise pick one; outside Load, say
|
|
|
30
35
|
## Run the command
|
|
31
36
|
|
|
32
37
|
```sh
|
|
33
|
-
node <this skill's folder>/scripts/reference.mjs <subcommand> ...
|
|
38
|
+
node <this skill's folder>/scripts/reference.mjs <subcommand> ...
|
|
34
39
|
```
|
|
35
40
|
|
|
36
|
-
`scripts/reference.mjs` is the package's `reference` command bundled into one file; it needs no `node_modules`.
|
|
41
|
+
`scripts/reference.mjs` is the package's `reference` command bundled into one file; it needs no `node_modules`. It finds the repository root from the working folder. Add `--root <repository root>` only when the working folder is not in the repository. A command that cannot complete exits 1 (or 2 for a usage error) and prints one error value on stdout, with `error` and `code` lines. A warning prints `warning: <code>: <message>` on stderr in text output, and does not change the exit code.
|
|
37
42
|
|
|
38
|
-
Outside Load, when
|
|
43
|
+
Outside Load, when the script is missing or cannot run, use `pnpm exec cyber-agentkit reference` when the package is a direct dependency, else `npx -y cyber-agentkit@2.0.0 reference`, with the same arguments. Load never falls back to a package runner.
|
|
39
44
|
|
|
40
45
|
## Load
|
|
41
46
|
|
|
42
47
|
Load `references/load.md` from this skill's folder and follow it, then return to the caller's work.
|
|
43
48
|
|
|
49
|
+
## Find
|
|
50
|
+
|
|
51
|
+
- For a topic, run `search <query>`. If nothing matches, say that nothing matched. Do not guess a name.
|
|
52
|
+
- For every reference, run `list`. Add `--trace` for every contribution of each name and its outcome.
|
|
53
|
+
- For every name matching a pattern, run `list '<pattern>'`. `*` stands for any run of characters and the rest is literal.
|
|
54
|
+
- For the implementations of an interface, run `implementations <id>`. It lists each one a consumer can load, with its pin. Add `--trace` for each one it left out, with why.
|
|
55
|
+
- When `list` or `search` carries a `defaults` field, say that skills' defaults were not searched, and why.
|
|
56
|
+
|
|
57
|
+
## Inspect
|
|
58
|
+
|
|
59
|
+
- To read a reference, run `load <name>`. Add `--metadata` for its composed frontmatter.
|
|
60
|
+
- To learn why a name composed as it did, run `load <name> --trace`. Report the stack and what built it, the contribution each section came from, each project section, and each layer that was `shadowed`, `stale`, `not used`, or `not read`, with its reason.
|
|
61
|
+
- To check a reference, run `check <name>...`: an interface document against its shape, an implementation against its interface, and every document for defects. With no name, it checks every name and reports every warning `load` would raise. It exits 0; report each entry under `failed` with its check, and each under `warned` with its warnings.
|
|
62
|
+
- To learn where a customization goes, run `where <name>`. Add `--default <skill folder>` when a skill loads the name, and `--in <folder>` for a folder's project section. Report each file, who it reaches, and what hides it. A plugin's or a skill's default contribution is read-only; never offer it as a place to write.
|
|
63
|
+
|
|
44
64
|
## Create
|
|
45
65
|
|
|
46
66
|
Load `references/create.md` from this skill's folder and follow it.
|
|
47
67
|
|
|
48
68
|
## Update
|
|
49
69
|
|
|
50
|
-
|
|
51
|
-
2. Choose the folder to write: `.agents/references/` for the project, or `~/.agents/references/` for the user alone.
|
|
52
|
-
3. If the trace shows a `used` file with a body in that folder, it is the user's own contribution. Edit that file in place, then go to step 6.
|
|
53
|
-
4. Otherwise, write a customization above what is there. Run `where <name>` (add `--default <skill folder>` when a skill loads the name) for the heading paths of the document below each place. Write only the sections the user changes, each under the heading path it has there; `patch` keeps every section you do not name. To add after a section's text instead of replacing it, use `--merge combine`, or mark that one section `<!-- merge: combine -->` under its heading. To drop one section, mark it `<!-- merge: remove -->`.
|
|
54
|
-
5. Start it with `create <name> --dry-run`, adding `--scope user` for the user's folder and `--template <path>` with the file holding those sections. Show the user the path and content, then run it without `--dry-run` on approval.
|
|
55
|
-
6. Run `show <name> --trace` again. The written file must be `used`, and each section the user changed must list it.
|
|
70
|
+
Use Update only for a file the user wrote by hand under `.agents/references/` or `~/.agents/references/`.
|
|
56
71
|
|
|
57
|
-
|
|
72
|
+
1. Run `load <name> --trace`. Find the `used` layer for that file.
|
|
73
|
+
2. If its trace row records a `request`, it is generated. Never edit it by hand; go to [Customize](#customize).
|
|
74
|
+
3. Show the user the change and the path. On approval, edit the file.
|
|
75
|
+
4. Run `load <name> --trace` again. The file must be `used`, and `load <name>` must give no `marker-unmatched` warning.
|
|
58
76
|
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
4. Run `show <name> --trace`. The stack must be what the user picked. To undo a selection, run `select <name> --clear`.
|
|
77
|
+
## Customize
|
|
78
|
+
|
|
79
|
+
Load `references/customize.md` from this skill's folder and follow it.
|
|
63
80
|
|
|
64
81
|
## Delete
|
|
65
82
|
|
|
66
|
-
1. Run `
|
|
67
|
-
2. Choose the
|
|
68
|
-
3. Run `delete <name> --dry-run
|
|
83
|
+
1. Run `load <name> --trace`. Use the bare name.
|
|
84
|
+
2. Choose the place: the repository (the default), the user with `--scope user`, or one folder's project section with `--in <folder>`. An author may also delete from a plugin's or a skill's source folder in this repository with `--plugin` or `--default`. An installed plugin's, a managed, or an installed skill's contribution is never deleted; offer a customization with `merge: remove` through [Customize](#customize) instead.
|
|
85
|
+
3. Run `delete <name> --dry-run` with that place's flag. Show the user the path and what will answer the name afterwards, and say so when a selection goes with the file.
|
|
69
86
|
4. On approval, run it without `--dry-run`.
|
|
70
|
-
5. Run `
|
|
71
|
-
|
|
72
|
-
## Find
|
|
73
|
-
|
|
74
|
-
- For a topic, run `search <query>`. If nothing matches, say that nothing matched. Do not guess a name.
|
|
75
|
-
- For every reference, run `list`. Add `--trace` for every contribution of each name and the outcome it gets.
|
|
76
|
-
- For every name matching a pattern, such as every provider of a shared prefix, run `list '<pattern>'`. `*` stands for any run of characters and the rest is literal, so it returns only exact matches, unlike `search`.
|
|
77
|
-
- For the implementations of an interface, run `implementations <id>`. It lists each one a consumer can load, with its pin; add `--trace` for each one it left out, with why.
|
|
78
|
-
- When `list` or `search` carries a `defaults` field, say that skills' defaults were not searched, and why.
|
|
87
|
+
5. Run `load <name> --trace` again. The deleted file must be gone from the trace.
|
|
79
88
|
|
|
80
|
-
##
|
|
89
|
+
## Wire a skill
|
|
81
90
|
|
|
82
|
-
|
|
83
|
-
- To learn why a name composed as it did, run `show <name> --trace`. Report the stack and what built it, the contributions each section came from, and each layer that was `shadowed`, `not used`, or `not read`, with its reason.
|
|
84
|
-
- To check a reference against its interface, run `check <name>...`; with no name, it checks every interface document and implementation. Report each failure with its check. Exit 1 means at least one failed.
|
|
85
|
-
- To learn where a customization goes, run `where <name>`; when a skill loads the name, add `--default <that skill's folder>`. Report each place, who it reaches, and the heading paths below it. A plugin's or a skill's default contribution is read-only; never offer it as a place to write. If the user then wants the customization written, go to [Update](#update).
|
|
91
|
+
A skill never runs the command itself. It carries one load line naming this skill and its package. Copy the line from the `README.md` in this skill's folder and replace the example names:
|
|
86
92
|
|
|
87
|
-
|
|
93
|
+
```text
|
|
94
|
+
Load `<name>` and `<name>` with the `reference` skill of `cyber-agentkit`.
|
|
95
|
+
Load the implementations of the `<id>` interface with the `reference` skill of `cyber-agentkit`.
|
|
96
|
+
```
|
|
88
97
|
|
|
89
|
-
A skill
|
|
98
|
+
A skill written for one harness may add that harness's typed form after the skill's name; the README lists each one. The skill may ship its own default of a name at `references/<name>.default.md` in its folder. Load adds it below every other contribution, and reads it on its own only when the command cannot run. A copy at `references/<name>.md` is not read as a default.
|
|
90
99
|
|
|
91
100
|
## Rules
|
|
92
101
|
|
|
93
|
-
- **Only Create, Update,
|
|
94
|
-
- **Never edit, move, rename, or delete a reference an installed plugin or skill ships, or a managed one.**
|
|
95
|
-
- **
|
|
102
|
+
- **Only Create, Update, Customize, and Delete write.** Load writes only a pick the user made for an ambiguous name. Find, Inspect, and Wire a skill change no reference file.
|
|
103
|
+
- **Never edit, move, rename, or delete a reference an installed plugin or skill ships, or a managed one.** Customize it instead. Its callers load it by name.
|
|
104
|
+
- **Never edit a generated document by hand.** Customize it again with its request.
|
|
105
|
+
- **Write only what the user approves.** Show the file and its path before you write or delete it. With no user present, write nothing.
|
|
96
106
|
|
|
97
107
|
## Validate
|
|
98
108
|
|
|
99
|
-
Before reporting a Create, Update,
|
|
109
|
+
Before reporting a Create, Update, Customize, or Delete done:
|
|
100
110
|
|
|
101
|
-
- The written or deleted file is under `.agents/references/` or `~/.agents/references/`, or, for Create and Delete, in a plugin's or a skill's source folder in this repository.
|
|
111
|
+
- The written or deleted file is under `.agents/references/` at the root or in a folder below it, under `~/.agents/references/`, or, for Create and Delete, in a plugin's or a skill's source folder in this repository.
|
|
102
112
|
- No file in an installed plugin or skill, or in a managed folder, changed.
|
|
103
113
|
- The file and its path were shown to the user before the write or the delete, and a delete also said what answers the name afterwards.
|
|
104
|
-
- After
|
|
105
|
-
-
|
|
106
|
-
- After Delete, `show <name> --trace` no longer finds the deleted file.
|
|
107
|
-
- A created reference's top level is not a single heading holding all the others.
|
|
108
|
-
- A created reference that declares `implements` passes `check <name>`.
|
|
109
|
-
- `show <name>` gives no `marker-unmatched` warning for a file written or changed.
|
|
114
|
+
- After a write, `load <name> --trace` reports the written file as `used`, or names what hides it.
|
|
115
|
+
- A written reference that declares `implements` passes `check <name>`.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
# Create a reference
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Create writes a new file from text the author gives, or an interface's stub. To change what an existing reference says in the customizer's own words, use Customize mode instead.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## 1. Check that it should be a reference
|
|
6
6
|
|
|
7
7
|
- If the agent must decide from the task that it needs this, it is a **skill**, not a reference. Say so and stop.
|
|
8
8
|
- If an `AGENTS.md` line, a skill, or a person will name it, it is a reference. Continue.
|
|
@@ -11,21 +11,21 @@ Decide who starts the read:
|
|
|
11
11
|
|
|
12
12
|
| Who it is for | Where | Flag |
|
|
13
13
|
| --- | --- | --- |
|
|
14
|
-
| this repository | `.agents/references/<name>.md` at the root
|
|
14
|
+
| everyone working in this repository | `.agents/references/<name>.md` at the root | (none) |
|
|
15
|
+
| work in one folder of the repository | `<folder>/.agents/references/<name>.md` | `--in <folder>` |
|
|
15
16
|
| the user, in every repository | `~/.agents/references/<name>.md` | `--scope user` |
|
|
16
|
-
| every user of a plugin | `references/<name>.md` in the plugin's source folder
|
|
17
|
+
| every user of a plugin | `references/<name>.md` in the plugin's source folder | `--plugin <plugin folder>` |
|
|
17
18
|
| a skill, as its default | `references/<name>.default.md` in the skill's source folder | `--default <skill folder>` |
|
|
18
19
|
|
|
19
|
-
`--plugin` and `--default` write only into a source folder in this repository, never into an installed copy.
|
|
20
|
+
`--plugin` and `--default` write only into a source folder in this repository, never into an installed copy. A folder's project section states only what differs there, and takes no `--merge`.
|
|
20
21
|
|
|
21
22
|
## 3. Name it
|
|
22
23
|
|
|
23
24
|
- Use lowercase words joined by `-`. A name is a file name, never a path, and never ends `.default`.
|
|
24
|
-
- **A plugin prefixes every name it ships** with its own name and a dot: `cyber-asana.work-hierarchy`, not `work-hierarchy`.
|
|
25
|
-
-
|
|
26
|
-
-
|
|
27
|
-
-
|
|
28
|
-
- Do not rename a reference that a plugin has already shipped. Its callers load it by the old name. Rename one only in a release that also updates every caller.
|
|
25
|
+
- **A plugin prefixes every name it ships** with its own name and a dot: `cyber-asana.work-hierarchy`, not `work-hierarchy`. A repository's or user's own reference needs no prefix. A skill's default takes the name its skill loads.
|
|
26
|
+
- **An implementation of an interface takes the interface's id as its namespace**: `<id>` when the interface's cardinality is `one`, `<id>.<key>` when it is `many`. Read the interface with `load <id>.interface`.
|
|
27
|
+
- Run `load <name>`. If the name already resolves and the author wants a new document, pick another name. To change the existing one, go to Customize mode.
|
|
28
|
+
- When a plugin or a skill renames a name it ships, list the old name in the new file's `aliases` frontmatter, so load lines and customizations written for the old name still reach it.
|
|
29
29
|
|
|
30
30
|
## 4. Write it
|
|
31
31
|
|
|
@@ -43,29 +43,34 @@ Instructions only.
|
|
|
43
43
|
```
|
|
44
44
|
|
|
45
45
|
- `description` and `tags` are what `search` matches. Always write a `description`.
|
|
46
|
-
-
|
|
47
|
-
- If the user's text starts with a `#` title, drop the title and make the sections under it top-level `##` sections. `create` refuses a template whose top level is one heading holding the others.
|
|
46
|
+
- If the author's text starts with a `#` title, drop the title and make the sections under it top-level `##` sections.
|
|
48
47
|
- Write instructions an agent follows. Leave the rationale out.
|
|
49
48
|
|
|
50
49
|
Run `create`; never write the file by hand:
|
|
51
50
|
|
|
52
|
-
1. Run `create <name> --dry-run`, with the flag from step 2. Add `--template <path>`
|
|
53
|
-
2. Show the
|
|
54
|
-
3. On approval, run the same command without `--dry-run`.
|
|
51
|
+
1. Run `create <name> --dry-run`, with the flag from step 2. Add `--template <path>` with the file holding the author's text; without it, the command writes its own template. Add `--merge <operation>` when it should not patch: `combine` to add after what is below, `replace` to stand alone, `remove` to turn the name off.
|
|
52
|
+
2. Show the author the path, the content it printed, and any `hint:` or `warning:` line. A warning that a contribution above hides the file still writes it.
|
|
53
|
+
3. On approval, run the same command without `--dry-run`.
|
|
55
54
|
|
|
56
|
-
If `create` refuses, report its reason and write nothing. An existing file with a body means
|
|
55
|
+
If `create` refuses, report its reason and write nothing. An existing file with a body means Customize mode, or Update mode for a file the user wrote by hand.
|
|
57
56
|
|
|
58
|
-
|
|
57
|
+
A plugin's file or a skill's default that changes how another plugin's reference reads, such as a house style, lists `extends: [<other plugin>]` in its frontmatter and holds only the sections it changes. `create` records in `sources` the version of each plugin it extends, so `check` warns the author when that plugin moves on. Never give such a file `merge: replace`; `create` refuses it.
|
|
59
58
|
|
|
60
|
-
|
|
59
|
+
## 5. Stub an interface
|
|
61
60
|
|
|
62
|
-
|
|
61
|
+
Run `create <name> --implements <id> --dry-run` instead of passing a template. It writes each section of the interface as a `##` heading, stubbed `**Unsupported.**` with what the section holds, and sets `implements: <id>@<version>` and `merge: replace`. With `--in <folder>`, it writes a project section with neither. Show it, write it on approval, then replace each stub with the section, or keep `**Unsupported.**` followed by one sentence on why. A required section cannot stay unsupported. Run `check <name>`; it must pass.
|
|
63
62
|
|
|
64
|
-
|
|
63
|
+
## 6. Show the result
|
|
65
64
|
|
|
66
|
-
|
|
67
|
-
|
|
65
|
+
1. Run `load <name> --trace`, adding `--default <skill folder>` for a skill's default. The new file must be `used`, or the trace names what hides it.
|
|
66
|
+
2. Show the author where each section came from: for each row of the trace's `sections`, the heading and the contributions that built it.
|
|
67
|
+
3. Offer the full document. When the author accepts, run `load <name>` and show what it prints.
|
|
68
68
|
|
|
69
|
-
|
|
69
|
+
For a plugin reference, run the command where the plugin is installed; otherwise, say that the plugin tier was not checked.
|
|
70
70
|
|
|
71
|
-
|
|
71
|
+
## 7. Connect it to a caller
|
|
72
|
+
|
|
73
|
+
Nothing loads a reference by itself. Tell the author where to name it:
|
|
74
|
+
|
|
75
|
+
- For a repository, add a line to `AGENTS.md`, or to the skill that needs it, such as: "Read the `testing` reference before writing tests."
|
|
76
|
+
- For a plugin or a skill's default, add the load line to each skill that needs it, as Wire a skill says.
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# Customize a reference
|
|
2
|
+
|
|
3
|
+
Customize changes what a skill reads for a name, for the repository, for the user alone, or for one folder. The customizer picks what the name builds on, says in their own words what to change in the prose, or both. The `customize` command writes the file and its record and runs no model; you run the generator.
|
|
4
|
+
|
|
5
|
+
With no user present, write nothing. When the command cannot run, write nothing and say so.
|
|
6
|
+
|
|
7
|
+
## 1. Read what the name is now
|
|
8
|
+
|
|
9
|
+
1. Run `load <name> --trace`. Add `--default <skill folder>` when a skill loads the name, and use it in every command below.
|
|
10
|
+
2. Note the status, the stack, and each `repo`, `user`, or project-section layer. A layer that records a `request` is generated. A layer whose outcome is `stale` goes to [Revise a stale document](#5-revise-a-stale-document).
|
|
11
|
+
|
|
12
|
+
## 2. Choose the target
|
|
13
|
+
|
|
14
|
+
Ask who the change is for, and use that target's flags in every command below:
|
|
15
|
+
|
|
16
|
+
| Who it is for | Flags |
|
|
17
|
+
| --- | --- |
|
|
18
|
+
| everyone working in this repository | (none) |
|
|
19
|
+
| only the user, in every repository | `--scope user` |
|
|
20
|
+
| work in one folder of the repository | `--in <folder>` |
|
|
21
|
+
|
|
22
|
+
Run `where <name>` with those flags. Tell the customizer the file it writes, who it reaches, and what hides it. A hidden target is still written, with a warning.
|
|
23
|
+
|
|
24
|
+
## 3. Pick what it builds on
|
|
25
|
+
|
|
26
|
+
Skip this step for `--in <folder>`: a project section takes no picks.
|
|
27
|
+
|
|
28
|
+
1. The options are the plugins that hold the name, each `<plugin>/<name>`, and `default` when a skill has one. An ambiguous name lists them in its `options`.
|
|
29
|
+
2. Ask the customizer which to build on, bottom first, even when only one is left.
|
|
30
|
+
3. Run `customize <name> --extends <step>... --dry-run` with the target's flags. A step is a plugin's name, `<plugin>:<merge>` (such as `house-style:combine`), or `default`. For steps that contribute only some sections, write the whole `extends` list to a YAML file and pass `--extends-file <file>`. To remove the picks, pass `--extends none`.
|
|
31
|
+
4. Show the path and the content. On approval, run it without `--dry-run`.
|
|
32
|
+
|
|
33
|
+
The picks record, as `declined`, every plugin holding the name that they leave out, so load stops asking about it. When load warns `plugin-not-selected` about a plugin installed later, ask the customizer whether to add it to the picks or leave it out; to leave it out, write the same picks again.
|
|
34
|
+
|
|
35
|
+
Picks alone write a selection, or change only `extends` on a file that has a body. When that body records a request, the output suggests customizing again with it: offer step 4.
|
|
36
|
+
|
|
37
|
+
## 4. Change the prose by request
|
|
38
|
+
|
|
39
|
+
1. If the name is ambiguous, do step 3 first. Write the customizer's request, in their own words, to a temporary file.
|
|
40
|
+
2. Run `customize <name> --base` with the target's flags and any new `--extends` picks. It prints what the generator reads, and writes nothing. It leaves out the target file, managed text, the tier above the target, and personal text.
|
|
41
|
+
3. Spawn a generator subagent. Give it the prompt in [The generator](#the-generator), the printed base, and the request. Say whether to write a delta (the default) or a whole document (the customizer asked to replace everything). If you cannot spawn a subagent, follow that prompt yourself, reading only the base and the request.
|
|
42
|
+
4. Write the draft to a temporary file. Run `customize <name> --request <request file> --body <draft file> --dry-run` with the target's flags, adding `--merge replace` for a whole document.
|
|
43
|
+
5. Show the customizer the path and the draft. If they decline, write nothing. If they change the request, start this step again with the new request.
|
|
44
|
+
6. Only after they approve, run the same command without `--dry-run`.
|
|
45
|
+
7. Run `load <name> --trace`. The written file must be `used`, or the trace names what hides it.
|
|
46
|
+
|
|
47
|
+
If `customize` refuses with `body-not-generated`, the target holds a body written by hand. Offer Update mode, or deleting it first.
|
|
48
|
+
|
|
49
|
+
### Implement an interface by request
|
|
50
|
+
|
|
51
|
+
To implement an interface for the name, add `--implements <id>` to the `--base` and to the write. The base then starts with the interface's stub. The draft is a whole document that holds every section of the interface, in its order. With `--in <folder>`, it is a project section for that folder alone, so one package can implement the interface its own way. After the write, run `check <name>`; it must pass.
|
|
52
|
+
|
|
53
|
+
A name that is `missing` under a found interface's namespace needs `--implements <id>`; `customize` refuses it otherwise and says how to name the interface.
|
|
54
|
+
|
|
55
|
+
## 5. Revise a stale document
|
|
56
|
+
|
|
57
|
+
Load reports a generated document `stale` when a plugin it was built from changed or is gone. Revise it from its recorded request; the customizer does not restate it.
|
|
58
|
+
|
|
59
|
+
1. From `load <name> --trace`, read the stale layer's `request`, its picks (`extends` in its `frontmatter`), and its `sources`.
|
|
60
|
+
2. If a source's status is `missing`, its plugin is gone. Tell the customizer before you generate anything. They pick again (step 3), or go on without it.
|
|
61
|
+
3. Revise the main document first: the `repo` or `user` document. Then revise each stale project section, one at a time, with `--in <folder>`. Each project section records the main document it was written against.
|
|
62
|
+
4. For each one, write its recorded request to a file and follow step 4 with the same target. The recorded picks apply unless the customizer picked again. The base never holds the stale document, so the request is not applied over its own earlier result.
|
|
63
|
+
5. A JSON, YAML, TOML, or text document is regenerated whole.
|
|
64
|
+
|
|
65
|
+
If the customizer declines, write nothing; the document stays stale.
|
|
66
|
+
|
|
67
|
+
## The generator
|
|
68
|
+
|
|
69
|
+
Give the generator subagent this prompt, followed by the base and the request:
|
|
70
|
+
|
|
71
|
+
> You write one reference document for the `reference` skill of `cyber-agentkit`. You get a base document and a customizer's request.
|
|
72
|
+
>
|
|
73
|
+
> - Apply the request to the base. Change only what the request asks for.
|
|
74
|
+
> - Write one concise document of instructions an agent follows. Leave out rationale and history.
|
|
75
|
+
> - Keep every heading path you use exactly as the base has it, so later loads match it. Add a new section only when the request needs one.
|
|
76
|
+
> - For a delta (the default), write only the sections you change, each under its heading path from the base. To drop a section, write its heading followed by `<!-- merge: remove -->`.
|
|
77
|
+
> - For a whole document, write every section, in the base's order.
|
|
78
|
+
> - For a project section, write only what differs for work in that folder.
|
|
79
|
+
> - For an interface, keep every section of the stub, in its order. Replace each stub with its content, or keep `**Unsupported.**` with one sentence on why. A required section cannot stay unsupported.
|
|
80
|
+
> - Use top-level `##` sections and no `#` title. Write no frontmatter; the command records it.
|
|
81
|
+
> - Use only the base and the request. Never add text from anywhere else, such as managed or admin instructions, or other files you can see.
|
|
82
|
+
> - Reply with the document alone.
|
|
@@ -2,79 +2,100 @@
|
|
|
2
2
|
|
|
3
3
|
Load the references a calling skill names, and hand them back as part of its instructions. The **caller** is the skill whose instructions sent you here; its **folder** is the directory its `SKILL.md` is in.
|
|
4
4
|
|
|
5
|
-
When the caller names an interface ("Load the implementations of the `<id>` interface"), follow [Implementations of an interface](#implementations-of-an-interface) for it. Load any names it also lists with steps 1 to
|
|
5
|
+
When the caller names an interface ("Load the implementations of the `<id>` interface"), follow [Implementations of an interface](#implementations-of-an-interface) for it. Load any names it also lists with steps 1 to 6.
|
|
6
6
|
|
|
7
7
|
## 1. Run the command once
|
|
8
8
|
|
|
9
|
-
Find the caller's folder from what the harness told you when the caller loaded: a `Base directory for this skill: <folder>` line, or the path of its `SKILL.md
|
|
9
|
+
Find the caller's folder from what the harness told you when the caller loaded: a `Base directory for this skill: <folder>` line, or the path of its `SKILL.md`. Collect every name the caller listed, in its order, and run one command for all of them:
|
|
10
10
|
|
|
11
11
|
```sh
|
|
12
|
-
node <this skill's folder>/scripts/reference.mjs
|
|
12
|
+
node <this skill's folder>/scripts/reference.mjs load <name>... --default <caller folder>
|
|
13
13
|
```
|
|
14
14
|
|
|
15
15
|
- `<this skill's folder>` is the directory the `reference` skill's `SKILL.md` is in.
|
|
16
|
-
- `--default <caller folder>` adds the caller's own defaults
|
|
17
|
-
-
|
|
18
|
-
-
|
|
19
|
-
- Never use `npx`, `pnpm dlx`, `upx`, or any other package runner, and never download anything, not even when this command cannot run. Go to step
|
|
16
|
+
- `--default <caller folder>` adds the caller's own defaults below every other contribution.
|
|
17
|
+
- Add `--root <repository root>` only when the working folder is not in the repository you work in.
|
|
18
|
+
- When you cannot tell the caller's folder, leave out `--default`. The names then load without the caller's defaults. Tell the user so in step 5.
|
|
19
|
+
- Never use `npx`, `pnpm dlx`, `upx`, or any other package runner, and never download anything, not even when this command cannot run. Go to step 4 instead.
|
|
20
20
|
|
|
21
21
|
Do not read `.agents/references/`, `~/.agents/`, any plugin's `references/`, or the caller's `references/` yourself. What answers a name is the command's decision.
|
|
22
22
|
|
|
23
|
-
## 2. Read
|
|
23
|
+
## 2. Read the result
|
|
24
24
|
|
|
25
|
-
One name prints its document. Several print each as `<reference name="…">` … `</reference>`, in the order asked. A name that
|
|
25
|
+
The result is on stdout. One found name prints its document. Several print each as `<reference name="…">` … `</reference>`, in the order asked. A name that was not found prints `<reference name="…" status="…" code="…">message</reference>` in its place, also when it is the only name. Read the status and the code from that tag. The command exits 0 even when a name was not found.
|
|
26
26
|
|
|
27
|
-
|
|
27
|
+
A found document may end with project sections, each wrapped as `<project folder="…">` … `</project>`. Each one states what differs for work in that folder. A section marked `plugin="…"` comes from a plugin that folder's `package.json` lists.
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
A warning prints on stderr as `warning: <code>: <message>`. It does not change the answer.
|
|
30
|
+
|
|
31
|
+
**The command ran** when every name you asked for appears on stdout as a document or a status tag. Exit 1 or 2 with one error value on stdout (`error:` and `code:` lines) means it ran but could not answer: go to step 4 and report the error. Anything else (`Cannot find module`, `node: not found`, a stack trace, no mention of the names) means it did not run: go to step 4.
|
|
32
|
+
|
|
33
|
+
## 3. Act on each name
|
|
30
34
|
|
|
31
35
|
- **found**: use the document.
|
|
32
|
-
- **missing**
|
|
33
|
-
- **
|
|
34
|
-
|
|
35
|
-
- With
|
|
36
|
-
-
|
|
36
|
+
- **missing** with `reference-missing`: carry on without it, and tell the user it was not loaded. Do not read the caller's default or search for a substitute: the command already included the default.
|
|
37
|
+
- **missing** with `reference-removed`: a `remove` turned the name off on purpose. Carry on without it, and say nothing about it. It is not a fault.
|
|
38
|
+
- **ambiguous** with `reference-ambiguous`: more than one plugin holds the name and nothing says which to build on. The tag ends with `; options: …`: each `<plugin>/<name>`, and `default` when the caller has one.
|
|
39
|
+
- With a user present, list every option, including `default`, even when only one is left. Ask which the name should build on, and whether the pick is for the repository (the default) or only for them. Write the pick with `reference customize <name> --extends <step>`, where the step is the option's plugin part or `default`, adding `--default <caller folder>`, and `--scope user` when it is for them only. Then run step 1 again for that name alone and use what it prints.
|
|
40
|
+
- With no user present, carry on without it, and tell the user to settle it with Customize mode.
|
|
41
|
+
- **invalid** with `reference-invalid`: the caller's load line names something that is not a reference name. Never read the path or file it names. Carry on without it, and tell the user it is a fault in the caller's instructions, to report to the caller's author.
|
|
42
|
+
|
|
43
|
+
Pass every warning on to the user, one line each, and use the reference as loaded. A `reference-stale` warning means a generated document was built against plugins that have since changed: name the changed plugins from its message, and say that Customize mode revises the document from its recorded request. A `plugin-not-selected` warning means a plugin installed after the customizer picked what the name builds on also holds it, and is not used: name the plugin, and say that Customize mode adds it, or leaves it out so the warning stops.
|
|
44
|
+
|
|
45
|
+
## 4. When the command did not run
|
|
46
|
+
|
|
47
|
+
Read the caller's default of every name, and only then. Never read a default for a name the command reported, whatever its status. A name's default is the first of these in the caller's folder:
|
|
48
|
+
|
|
49
|
+
1. `references/<name>.default.md`
|
|
50
|
+
2. `references/<name>.default.json`, `.default.yaml`, `.default.yml`, `.default.toml`, then `.default.txt`
|
|
51
|
+
|
|
52
|
+
A name with no such file is not loaded. Never read `references/<name>.md`; it is not a default.
|
|
53
|
+
|
|
54
|
+
## 5. Report
|
|
55
|
+
|
|
56
|
+
Tell the user, briefly:
|
|
37
57
|
|
|
38
|
-
|
|
58
|
+
- each name not loaded, and why: missing, ambiguous (with the options), or invalid (a fault for the caller's author). Leave out a name a `remove` turned off.
|
|
59
|
+
- each warning, one line each.
|
|
60
|
+
- when the command did not run: that it did not, the error it gave, and that each name came from the caller's default, so no managed text, project section, or repository or user customization applied. When a name has no default, add that `scripts/reference.mjs` ships with the npm package, so a `cyber-agentkit` plugin installed from git has none, and installing it from npm fixes it.
|
|
61
|
+
- when you could not tell the caller's folder: that the names loaded without its defaults.
|
|
39
62
|
|
|
40
|
-
|
|
63
|
+
Say nothing about the load when every name was found with no warning.
|
|
41
64
|
|
|
42
|
-
|
|
65
|
+
## 6. Follow the references
|
|
43
66
|
|
|
44
|
-
|
|
67
|
+
Return to the caller. Follow each loaded document as part of its instructions. Carry on without a name that was not loaded.
|
|
45
68
|
|
|
46
|
-
|
|
69
|
+
Where instructions conflict, follow them in this order, highest first:
|
|
47
70
|
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
- when you could not tell the caller's folder: that the names were loaded without its defaults.
|
|
71
|
+
1. company and team instructions the harness gives you;
|
|
72
|
+
2. a single feature's own document the caller points you at;
|
|
73
|
+
3. the resolved reference, or the default read when the command did not run.
|
|
52
74
|
|
|
53
|
-
|
|
75
|
+
Within a resolved reference, the project section for the folder the work is in ranks over the main document. When sections of nested folders both apply, follow both, and the inner folder's section wins where they conflict. When one folder has a section marked `plugin="…"` and one without, follow both, and the one without wins where they conflict. Managed text needs no ranking: the command already applied it.
|
|
54
76
|
|
|
55
|
-
|
|
77
|
+
Follow a project section whenever your work is in its folder. When the work moves into a folder partway through the task, follow that folder's project section from then on, without loading again. Stop following it when the work leaves the folder.
|
|
56
78
|
|
|
57
79
|
## Implementations of an interface
|
|
58
80
|
|
|
59
|
-
1. Run
|
|
81
|
+
1. Run:
|
|
60
82
|
|
|
61
83
|
```sh
|
|
62
|
-
node <this skill's folder>/scripts/reference.mjs implementations <id> --trace --format json
|
|
84
|
+
node <this skill's folder>/scripts/reference.mjs implementations <id> --trace --format json
|
|
63
85
|
```
|
|
64
86
|
|
|
65
|
-
Add `--accept <versions>`, such as `--accept 1,2`, when the caller names the interface versions it knows. The
|
|
66
|
-
2. Exit 0 prints one JSON object. `implementations` lists each one the caller can load, with its `pin`, `description`, and the `unsupported` sections it does not honor
|
|
67
|
-
3. Hand the list to the caller. The caller picks the implementations it needs; load each by its `pin` with steps 1 to
|
|
68
|
-
4. Tell the user, briefly, about each excluded implementation and its reasons, and about an interface not loaded and its error.
|
|
87
|
+
Add `--accept <versions>`, such as `--accept 1,2`, when the caller names the interface versions it knows. The rules of step 1 apply: add `--root` only outside the repository, no package runner, no download, and no reading tier folders yourself.
|
|
88
|
+
2. Exit 0 prints one JSON object. `implementations` lists each one the caller can load, with its `pin`, `description`, and the `unsupported` sections it does not honor. It is empty when there are none. `excluded` lists each one left out, with its `reasons`. An unknown interface exits 1 with one error value on stdout, code `interface-unknown`; then the interface is not loaded.
|
|
89
|
+
3. Hand the list to the caller. The caller picks the implementations it needs; load each by its `pin` with steps 1 to 6.
|
|
90
|
+
4. Tell the user, briefly, about each excluded implementation and its reasons, and about an interface not loaded and its error.
|
|
69
91
|
|
|
70
92
|
## Validate
|
|
71
93
|
|
|
72
94
|
Before returning to the caller:
|
|
73
95
|
|
|
74
|
-
- Every name the caller listed is
|
|
96
|
+
- Every name the caller listed is loaded from the command, read from the caller's default because the command did not run, or named in the report as not loaded.
|
|
75
97
|
- The caller's default was read only when the command did not run, never for a name the command reported.
|
|
76
|
-
- An ambiguous name was
|
|
77
|
-
- Every
|
|
98
|
+
- An ambiguous name was written with `reference customize --extends` only after the user picked an option and a scope.
|
|
99
|
+
- Every warning was passed on, one line each.
|
|
78
100
|
- No `npx`, `pnpm dlx`, `upx`, or download was run.
|
|
79
101
|
- No file under a tier folder, and no path an invalid name gives, was read by you.
|
|
80
|
-
- The report is empty when every name came from the command.
|