refactor(skills): retrofit the corpus to the ADR-0020 context contract (#129)
Retrofits all 39 skills to ADR-0020's description/body context contract, then fixes what six rounds of independent review found in that retrofit — including four ways the hot gate itself failed open. Closes #99, #107, #108, #110, #111, #114, #115, #120. ## The retrofit (waves 1-5) | | Start | Now | |---|---|---| | Description FAILs (>400 chars) | 26 | **0** | | Body FAILs (>900 words, body-only) | 9 | **0** | | Dangling routing targets | 2 | **0** | | `Kyberforge.CompositionNote` | 10 | **0** | | Preload tax | 21,005 chars | **~10,500** | Under the 12,000-char success criterion. Per-wave detail is on #99. ## The review fixes **The gate failed open four ways, three of them found after the retrofit shipped.** An unrecognised follower token made a dangling target vanish. A skill directory with no `SKILL.md` resolved as a valid target, so a commit could be green locally and red in a fresh clone — three existing fixtures were relying on that, one of which made the install-leak A/B pass vacuously. Then the free-standing `/name` sweep turned out to be gated on the sentence carrying a boundary marker, so route notation in any other sentence was invisible — not an ERROR, not a SUGGESTION, not an INFO — which left the documented "`/name` always blocks" promise false from a second direction. All four fixed and pinned. **Two checks were silently not running.** `validate-provenance.sh` checks 7-8 were dead across nine skills. Waking them exposed a deeper problem: they assume `Research doc:` names a source index, but 30 of 121 entries point at topic content documents, so every new check-7 INFO was a false positive and check 8 was saved from a false-FAIL flood only by an *unannounced* skip. Checks 7/8 are now scoped to source indexes and every skip announces itself (#121). **The retrofit's own anti-goal, four times.** ADR-0020 warns that a blunt gate gets satisfied by deleting content rather than relocating it. `diagnose` and `skill-audit` relocated prose and then read it unconditionally; `prototype` and `vale-config` deleted rules outright that survived nowhere. All four addressed. ## Verification - `bash tests/run-tests.sh --strict` — 24 suites, 0 skipped, 0 failed - `bash tests/run-bats.sh` — 325 tests, 0 failures - `pre-commit run --all-files` — 17/17 - `pre-commit run --hook-stage pre-push --all-files` — 16/16, with `apm marketplace check` and `apm pack --check-clean` run against the remote, not skipped - `scripts/skill-size-check.sh` over all 39 skills — rc 0, 0 ERROR/FAIL, SUGGESTION-only - Preload tax measured at **10,498 chars**, max description 390 — both inside budget - Every new test proven non-vacuous by a deliberate mutation of the behaviour it covers **Per-commit sync, stated accurately:** the ten commits from the latest review round each pass `check-plugin-content-sync` in isolation, verified by checking each out in a detached worktree with a clean between. The earlier gitea window (`dfacf05..bedbd1d`, nine commits) does **not** — its mirror was regenerated in one batch at `bbc7300`. An earlier revision of this description claimed the property held for every commit; it does not, and a bisect through that window lands on a red commit. **Squash-merge** to collapse it, or accept that this range is not bisectable. ## Version bump Six plugins and the catalog take a **patch**, not a minor. The branch is **89 commits — 40 `fix` / 30 `refactor` / 12 `docs` / 5 `chore` / 2 `test` — zero `feat`, zero `!`, zero `BREAKING CHANGE`** — and adds no skill, agent, command or hook. (Two earlier revisions of this section cited a stale histogram, most recently 78 commits; the figures above are measured at HEAD.) Both rules this repo ships (`forge/references/version-bump.md`, landing in this PR, and `git-commits/references/conventional-commits-spec.md`) make that a patch, and the catalog set is unchanged at 7 entries. Not settled by that: four published files were removed from the installed tree, three moved, and `caveman` gained `disable-model-invocation`, retiring its old triggers. Under a strict reading those are major-class and currently ship under `refactor:` with no marker. Whether the deployed skill surface is a public contract is written down nowhere — worth deciding, but it outlives this PR. ## Deliberately not in scope #112 (cherry-pick ownership, now resolved in favour of `git-commits`), #113 (`rtk git` normalisation), #116 (research fan-out), #101 (audit-skill merge), #122 (non-spec skill-root files), #123 (no PRD producer) stay open. #117 is the one worth reading: the contract's remedy is to move prose into `references/`, which is exactly where neither the size gate nor Vale looks — and the blind spot is wider than #117 currently records, since there is no root `.vale.ini` at all, so every ADR, `CONTEXT.md` and `README.md` is unlinted too. That blind spot let this branch carry two `level: error` `Kyberforge.SentenceOpenerThereIs` violations into `references/` files it created — `provider-adapter-author/references/provider-matrix.md:31` and `agent-audit/references/finding-criteria.md:95`. Both are reworded in `afadaae`, confirmed by routing each file through the audit's own `vale-wrap.sh` (1 error each before, 0 after). Five further occurrences sit in `references/` files already on `main`; those are the pre-existing corpus and stay with #117, which is the real fix. Also unfixed and not this PR's: `apm install` appends a duplicate `SessionStart` entry to `.claude/settings.json`, so a fresh clone cannot get pre-push green without an edit AGENTS.md warns against. Reproduces identically on `main`. Co-authored-by: Defame1297 <gitea@rkdr.net> Reviewed-on: https://git.dev.rkdr.net/Defame1297/holocron/pulls/129 Co-authored-by: Claude Code AI - Gitea MCP <claude@noreply.git.dev.rkdr.net> Co-committed-by: Claude Code AI - Gitea MCP <claude@noreply.git.dev.rkdr.net>
This commit was merged in pull request #129.
This commit is contained in:
@@ -1,15 +0,0 @@
|
||||
```yaml
|
||||
version: "1.1"
|
||||
updated: 2026-06-21
|
||||
|
||||
when: >-
|
||||
Invoked when the user wants to gather structured reference documentation for a
|
||||
tool, library, or API from MCP documentation indexes or web sources. Typically
|
||||
run before writing a new skill that wraps an external tool, or any time
|
||||
reference files are needed for a topic. Triggered explicitly
|
||||
("/research <topic> <path>") or implicitly when the user asks to look up,
|
||||
gather, or pull docs for a topic before implementing something.
|
||||
|
||||
references:
|
||||
- .agents/skills/context7-mcp/SKILL.md # context7-mcp — MCP source channel integrated at step 2
|
||||
```
|
||||
31
plugins/bin/.apm/skills/research/README.md
Normal file
31
plugins/bin/.apm/skills/research/README.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# research
|
||||
|
||||
Research a tool, library or API from canonical documentation into a directory of structured per-topic reference files.
|
||||
|
||||
## What it does
|
||||
|
||||
Runs a six-step pipeline: scope against the working directory (what version is actually in use, what is already documented), resolve the topic through Context7, websearch for canonical docs covering whatever Context7 missed, read those sources, deepen one level into the links worth following, then write one markdown file per topic area plus a `sources.md` provenance record.
|
||||
|
||||
Four gotchas at the top of `SKILL.md` shape the whole run, and each exists because of a specific failure: the output path is never inferred (a guessed destination scatters a directory's worth of files through someone's source tree); nothing is written outside that path; no empty topic file is ever written (a stub `troubleshooting.md` reads downstream as researched and closed); and a Context7 "no results", redirect or header-only response does not count as coverage. If no topic area has content, the run writes nothing at all — `sources.md` included — and reports what it searched.
|
||||
|
||||
The frontmatter pins `model: sonnet` and a closed `allowed-tools` list. Notably it grants no subagent tool, so every `WebFetch` is serial and each fetched page lands in the run's own context — which is why steps 4 and 5 insist on reducing each page to notes before fetching the next, and cap deepening at roughly ten extra pages.
|
||||
|
||||
## Composition
|
||||
|
||||
Both reference files are read on condition, never on every run — `SKILL.md` inlines the minimum each step needs (the seven default topic areas at step 1, the four `sources.md` field names and the topic-file frontmatter keys at step 6) and sends the run to the reference only for what it does not carry. Those four field names are matched literally by the downstream provenance validator, so prose written in their place parses as nothing and the check passes having verified nothing — which is why they are inlined rather than deferred.
|
||||
|
||||
## Usage
|
||||
|
||||
```text
|
||||
/research
|
||||
```
|
||||
|
||||
Name the topic and the output path — the skill will stop and ask if the path is missing. Supplying starting URLs is treated as a deliberate source choice and skips Context7 resolution and discovery. For documentation derived from existing code or specs, use `write-docs`; for a bug or incident, use `diagnose`.
|
||||
|
||||
## Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `SKILL.md` | The four gotchas and the six research steps |
|
||||
| `references/topics.md` | Read at Step 1 only when what belongs in a default topic is unclear or a custom topic is needed: the per-topic coverage table and the custom-topic naming rule |
|
||||
| `references/file-format.md` | Read at Step 6 only when the inlined field names do not settle the case: slug derivation, the Context7 slug and URL convention, and what belongs in a topic body |
|
||||
@@ -1,97 +1,78 @@
|
||||
---
|
||||
name: research
|
||||
description: >-
|
||||
Use when the user wants to research a topic and generate structured reference
|
||||
markdown files. Handles: finding canonical docs for a tool/library/API via
|
||||
Context7 MCP or web sources, reading and deepening into linked pages,
|
||||
organizing extracted content into topic files (overview, installation,
|
||||
configuration, cli-reference, api-reference, examples, troubleshooting). Do
|
||||
NOT use when the user wants to write documentation from existing code or specs
|
||||
(use write-docs), install or manage the neuledge-context MCP server (use
|
||||
neuledge-context), or research a bug/incident (use diagnose).
|
||||
Use when the user wants a tool, library, or API researched from canonical
|
||||
documentation into structured per-topic reference markdown files. Not
|
||||
documentation written from existing code or specs -> `write-docs`. Not a bug
|
||||
or incident -> `diagnose`.
|
||||
metadata:
|
||||
category: research
|
||||
allowed-tools:
|
||||
- WebSearch
|
||||
- WebFetch
|
||||
- Grep
|
||||
- Glob
|
||||
- Read
|
||||
- Write
|
||||
- WebSearch
|
||||
- WebFetch
|
||||
- mcp__context7__resolve-library-id
|
||||
- mcp__context7__query-docs
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
<requirements>
|
||||
## Gotchas
|
||||
|
||||
## Required inputs
|
||||
- Never infer the output path. A run writes a directory's worth of files, and a guessed destination scatters them through someone's source tree. If the user named no path, stop and ask.
|
||||
- Write nothing outside the given output path. A file placed beside the agreed directory is one the user never asked for and will not think to look for.
|
||||
- Never write an empty topic file. A stub `troubleshooting.md` reads downstream as researched and closed.
|
||||
- A Context7 response that is a "no results" message, a redirect notice, or header-only boilerplate is not coverage. A topic area counts as covered only when the response carries at least one substantive paragraph.
|
||||
|
||||
- **Topic** — the subject to research (tool, library, API, concept); inferred from user description if clear, ask if ambiguous
|
||||
- **Output path** — directory where reference files will be written; must be provided explicitly — do not infer or default
|
||||
- **Starting URLs** — optional; if provided, skip discovery websearch and read these first
|
||||
## Step 1 — Scope against the working directory
|
||||
|
||||
## Constraints
|
||||
Search for existing use of the topic — imports, config files, version pins, reference files already written — and narrow the research to what is missing: the version actually in use, the topics not yet documented.
|
||||
|
||||
- Never write files outside the explicitly provided output path
|
||||
- Skip any default topic file if no relevant content is found for it — do not create empty files
|
||||
- Create additional topic files beyond the default list when content warrants it (e.g. `webhooks.md`, `rate-limits.md`)
|
||||
- Subagents handle parallel source reading and link deepening — the orchestrator writes all files; subagents return summaries only, never write directly
|
||||
- Context7 MCP calls (`resolve-library-id`, `query-docs`) are made only by the orchestrator at step 2 — subagents must not call them
|
||||
- `sources.md` is always written, even if only one source was read
|
||||
- Each topic file must have frontmatter with `topic` and `source_keys`; body is prose only — no inline URLs
|
||||
- Source keys in `sources.md` must be kebab-case slugs: derived from the source domain or page title for web sources; for Context7 sources use `context7-<library-slug>` (e.g. `context7-vercel-next-js`)
|
||||
- Default topic list and file format spec live in `references/` sub-files — read them at step 1
|
||||
The default topic areas are `overview`, `installation`, `configuration`, `cli-reference`,
|
||||
`api-reference`, `examples` and `troubleshooting` — one file each, and only where content exists.
|
||||
If what belongs in one of them is unclear, or the topic needs a file outside that set, read
|
||||
`references/topics.md` for the per-topic coverage table and the custom-topic naming rule.
|
||||
|
||||
</requirements>
|
||||
## Step 2 — Resolve against Context7
|
||||
|
||||
<steps>
|
||||
If the topic is a library, framework, or API and the user gave no starting URLs, call `resolve-library-id` with the topic name and the user's full question — match quality depends on the question, not the bare name — then `query-docs` once per default topic area. Record each response as a source with slug `context7-<library-slug>`, and mark which topic areas it covered — those skip the web reads at step 4.
|
||||
|
||||
## Process
|
||||
If the library does not resolve, or the user gave starting URLs, go to step 3. Explicit URLs are a source choice; do not second-guess them with a resolution attempt.
|
||||
|
||||
1. **Scan codebase.** Search the working directory for existing usage of the topic — imports, config files, version pins, existing reference files. Use findings to narrow research scope (e.g. target the version already in use, skip topics already documented). Read `references/topics.md` for the default topic list and `references/file-format.md` for the output file format spec.
|
||||
## Step 3 — Discover sources
|
||||
|
||||
2. **Try Context7.** If the topic is a library, framework, or API and no starting URLs were provided, call `resolve-library-id` with the topic name and the user's question. If a match resolves, call `query-docs` once per default topic area (see `references/topics.md`). Treat each response as a source summary with slug `context7-<library-slug>` (e.g. `context7-vercel-next-js`). A topic area has sufficient content when the Context7 response contains at least one substantive paragraph — not a "no results" message, redirect notice, or header-only boilerplate. Mark covered topic areas — skip their subagent web reads in step 4. If the library does not resolve, or starting URLs were provided (explicit source choice by the user), skip this step entirely.
|
||||
If the user gave starting URLs, skip discovery: those URLs are the source list and go straight to step 4.
|
||||
|
||||
3. **Discover sources.** For topics not covered by Context7 (or when no starting URLs were provided and Context7 did not resolve), websearch for canonical documentation (prefer `llms.txt`, developer docs, official API references over tutorials or blog posts). Collect 3–5 candidate URLs before reading any.
|
||||
Otherwise, for every topic area Context7 did not cover, websearch for canonical documentation — `llms.txt`, official developer docs, and API references ahead of tutorials or blog posts. Collect three to five candidate URLs before reading any of them.
|
||||
|
||||
4. **Read sources in parallel.** Spawn one subagent per source URL. Each subagent fetches the page, extracts relevant content, identifies links worth deepening, and returns a structured summary (content by topic area + links to follow). Subagents do not write files.
|
||||
If nothing usable comes back, stop and report what was searched, then ask for starting URLs rather than settling for tutorials.
|
||||
|
||||
5. **Deepen.** For each subagent that returned links worth following, spawn child subagents per branch. Continue until content becomes repetitive or out of scope. Cap at ~10 additional pages total across all branches.
|
||||
## Step 4 — Read the sources
|
||||
|
||||
6. **Consolidate.** Merge all subagent summaries (Context7 and web) by topic area. Identify which default topics have sufficient content and which custom topics emerged.
|
||||
`WebFetch` each URL in turn. No subagent tool is granted here, so the reads are serial and every fetched page lands in this context: reduce each page to notes by topic area, plus the links worth deepening, before fetching the next one.
|
||||
|
||||
7. **Write topic files.** For each topic with content, write `<output-path>/<topic>.md` using the format in `references/file-format.md`. Orchestrator writes all files — never delegate file writing to a subagent.
|
||||
## Step 5 — Deepen
|
||||
|
||||
8. **Write `sources.md`.** Write `<output-path>/sources.md` mapping each source slug to its URL (use `context7:<library-id>` as the URL for Context7 sources), description, and list of topic files it contributed to. Include sources that yielded no content, marked `no content extracted`.
|
||||
`WebFetch` the links worth following, still one at a time and still reducing each page to notes. Stop a branch once its content turns repetitive or leaves the topic, and cap the whole step at roughly ten additional pages — serial reads make that cap a real budget, not a formality.
|
||||
|
||||
## Output format
|
||||
## Step 6 — Write
|
||||
|
||||
- `<output-path>/<topic>.md` per topic with content — formatted per `references/file-format.md`
|
||||
- `<output-path>/sources.md` — always produced; maps slug → URL, description, contributing files
|
||||
Merge every set of notes, Context7 and web alike, by topic area, then write, in the output path:
|
||||
|
||||
</steps>
|
||||
- `<topic>.md` for each topic area that has content, default or custom. Frontmatter carries `topic:` (the filename without `.md`) and `source_keys:` (kebab-case slugs matching `sources.md`); the body is prose in `##` sections, with no inline URLs.
|
||||
- `sources.md`, always, one `##` section per source — including sources that yielded nothing — with exactly these four fields:
|
||||
|
||||
<checks>
|
||||
```markdown
|
||||
- **URL:** <full URL>
|
||||
- **Description:** <one-line summary>
|
||||
- **Contributing files:** <topic files this source contributed to>
|
||||
- **Status:** `extracted` | `no content extracted`
|
||||
```
|
||||
|
||||
## Failure handling
|
||||
Spell those four field names exactly as given. The downstream provenance validator matches them literally; prose in their place parses as nothing, and the check passes having verified nothing.
|
||||
|
||||
- Output path not provided — stop and ask; do not infer or default
|
||||
- No sources found after websearch — report what was searched, ask user to provide starting URLs
|
||||
- Subagent returns no usable content — skip that source, log in `sources.md` as `no content extracted`
|
||||
- All topic files would be empty — stop, report what was searched, do not write any files
|
||||
Read `references/file-format.md` when the four fields above do not settle the case: what a slug should be, the `context7-<library-slug>` slug and `context7:<library-id>` URL convention for a Context7 source, or what belongs in a topic body versus a verbatim copy of the source.
|
||||
|
||||
## Self-check
|
||||
|
||||
- [ ] Codebase scanned before any websearch was performed
|
||||
- [ ] Output path was explicitly provided — not inferred
|
||||
- [ ] `references/topics.md` and `references/file-format.md` read at step 1
|
||||
- [ ] Context7 resolution attempted before websearch when topic is a library/framework/API
|
||||
- [ ] Context7 calls made only at orchestrator step 2 — no subagent called `resolve-library-id` or `query-docs`
|
||||
- [ ] Context7 sources recorded in `sources.md` with `context7:<library-id>` as URL
|
||||
- [ ] No topic file written without content
|
||||
- [ ] `sources.md` written with all sources read (including those with no content extracted)
|
||||
- [ ] All file writes performed by the orchestrator, not subagents
|
||||
- [ ] Each topic file has `topic` and `source_keys` frontmatter fields
|
||||
- [ ] All source keys in topic files have a matching entry in `sources.md`
|
||||
- [ ] No files written outside the provided output path
|
||||
|
||||
</checks>
|
||||
If no topic area has content, write nothing at all, `sources.md` included, and report what was searched.
|
||||
|
||||
Reference in New Issue
Block a user