feat(kyberforge): execute plugin-to-apm marketplace conversion
Why: ADR-0015 established that Microsoft APM (apm.yml + .apm/) should replace this repo's hand-authored plugin.json/marketplace.json model, with those files becoming compiled output of `apm pack` instead of files edited by hand via the (now-retired) plugin-author/marketplace-author skills. Issue #90 was the deferred execution of that decision, gated on #88 (apm tooling) and #89 (apm-native agent-author/skill-author routing). Implementation notes: - All six plugins (bin, core, git, gitea, kyberforge, lint) now carry apm.yml + .apm/{skills,agents,hooks} as their authoring source. Skills moved with a plain git mv (content-identical across targets). Agents were re-authored, not moved: per ADR-0016, .apm/agents/*.agent.md compiles verbatim to both Claude and Copilot, so plugin-scope agents now carry only name/description/model/source_keys -- no tools: field, no Claude-only knobs (isolation, maxTurns, effort, memory, permissionMode). - Root apm.yml registers all 7 marketplace packages (6 local plus mattpocock-skills as a remote entry) under versioning: per_package, matching this repo's existing independent-plugin-versioning practice. - .claude-plugin/marketplace.json and every plugin's plugin.json are now apm-pack-compiled output, verified against the prior hand-maintained content: same names/descriptions/versions/licenses/authors, only cosmetic serialization differences (JSON key order, owner email vs. url, Unicode escaping). - plugin-author and marketplace-author are retired now that apm-based authoring fully replaces their job; kyberforge bumped 1.3.1 -> 1.4.0 for that removal, and the root marketplace catalog bumped 0.3.1 -> 0.3.2 to match, per the version-bump convention now documented in apm-workflow's reference docs instead of a dedicated script (apm has no native version-bump automation). - Fixed hardcoded pre-.apm/ path assumptions across .pre-commit-config.yaml, .pre-commit-hooks.yaml, scripts/check-scope-walkup-sync.sh, scripts/sync-vale-styles.sh, scripts/check-vale-style-sync.sh, six plugins' root plugin.json (stale skills/hooks/agents pointer fields that check-manifests.sh validates), and several tests/*.bats and tests/*.sh fixtures -- including a bats REPO_ROOT relative-path depth bug (10 files, one extra .apm/ directory level to walk up) and a vale probe-path isolation regression introduced mid-fix. - Corrected empirically-wrong assumptions surfaced this session in apm-workflow/apm-install's own reference docs: `apm marketplace package add` does not accept local paths (only owner/repo remote shorthand -- local packages are registered by editing apm.yml's marketplace.packages[] directly); `apm compile` is a consumer-side AGENTS.md/CLAUDE.md generator, not the plugin.json producer, and hard-fails on skill/agent-only packages without --clean; `apm plugin init <name>` nests a stray subdirectory when run with a positional name arg from inside a same-named directory; no native Copilot marketplace output profile exists; .mcp.json is merged into the compiled plugin.json content-aware and target-scoped, with no dependencies.mcp entry needed for simple passthrough; pipx is the correct pip fallback on externally-managed Python environments. - Renamed agent-author's copilot.agent.md template asset to copilot.agent.md.template so apm compile's recursive *.agent.md glob stops misparsing the placeholder template as a real agent primitive. Impact: plugin.json and marketplace.json are compiled artifacts from here on -- editing them by hand is no longer the workflow; edit apm.yml/.apm/ and run apm pack. CONTEXT.md's Plugin/Plugin marketplace glossary entries reflect this. ADR-0001 is marked superseded, ADR-0006 moot, and ADR-0010 updated for the new .apm/agents/ path (project/user scope unaffected, per ADR-0016). Full local verification: claude plugin validate --strict on all 6 plugins, apm audit --ci, apm marketplace check, check-manifests.sh, and the full test suite (165/165 bats, 13/13 shell scripts) all pass clean. Fixes: #90 Refs: #88, #89 ADR: 0015 ADR: 0016 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ub96PyaSRD9BHPktotj1pC
This commit is contained in:
103
plugins/bin/.apm/skills/write-docs/SKILL.md
Normal file
103
plugins/bin/.apm/skills/write-docs/SKILL.md
Normal file
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: write-docs
|
||||
description: Write documentation for X, document this module, create docs for this feature. Use when the user wants to produce or update technical documentation derived from code, spec, or existing artifacts. Do NOT use when the user wants a PRD, ADR, decision doc, or skill file — those have dedicated skills.
|
||||
version: "1.0"
|
||||
updated: 2026-05-17
|
||||
when: invoked by explicit trigger ("write docs for X", "document this module", "create docs for this feature") or implicit request to produce technical documentation from code or spec
|
||||
metadata:
|
||||
category: implement
|
||||
source:
|
||||
- repo: anthropics/skills
|
||||
commit: f458cee31a7577a47ba0c9a101976fa599385174
|
||||
files:
|
||||
- skills/doc-coauthoring/SKILL.md # Reader Testing stage, surgical-edit constraint, gap-check step
|
||||
updated: 2026-05-17
|
||||
- repo: mattpocock/skills
|
||||
commit: e74f0061bb67222181640effa98c675bdb2fdaa7
|
||||
files:
|
||||
- skills/productivity/write-a-skill/SKILL.md # trigger pattern, review checklist items
|
||||
updated: 2026-05-17
|
||||
- repo: bmad-code-org/BMAD-METHOD
|
||||
commit: 71136bc6af77cbf507d3768494311d5b6ca95cc5
|
||||
files:
|
||||
- src/core-skills/bmad-advanced-elicitation/SKILL.md # confirmation gate before applying changes
|
||||
updated: 2026-05-17
|
||||
---
|
||||
|
||||
## Role
|
||||
|
||||
You are a technical writer that produces documentation by reading code and spec — you derive every claim from a source file or explicit user input and never invent behaviour.
|
||||
|
||||
## When to use / When not to use
|
||||
|
||||
**Use when:**
|
||||
- User wants to document a module, class, function, feature, CLI flag, API endpoint, config file, or README section
|
||||
- User says "write docs for X", "document this", "create docs for this feature", "write a README for this"
|
||||
|
||||
**Do not use when:**
|
||||
- User wants a PRD, decision doc, or architecture proposal → `to-prd` or `grill-me`
|
||||
- User wants to document a skill file (skill files are self-describing)
|
||||
- User wants marketing or blog copy
|
||||
- Documentation requires tacit organisational knowledge that cannot be read from code or spec
|
||||
|
||||
## Required inputs
|
||||
|
||||
- Specific file(s) or module(s) to document, or enough description to propose candidates
|
||||
- Target audience: developer / user / contributor / internal
|
||||
- Documentation type: reference, guide, README section, inline comment, changelog entry
|
||||
|
||||
## Constraints
|
||||
|
||||
- Every claim must be traceable to a source file line, spec section, or explicit user statement — never invent behaviour
|
||||
- User must approve specific files before the skill reads them; skill may propose candidates but waits for approval
|
||||
- Stage skipping is allowed only with an explicit user request and a one-sentence logged reason
|
||||
- Show the full revised section before each confirmation gate — never gate on output the user has not seen
|
||||
- Never reprint the whole document; all edits are surgical
|
||||
- Produce a one-line delta summary after each refinement round
|
||||
- Reader Testing sub-agent receives only the finished doc and the question list — no source files
|
||||
- Write summary and overview sections last, after all detail sections are stable
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify scope.** User names specific files or sections. If not provided, propose candidates based on the description — wait for explicit approval before reading.
|
||||
|
||||
2. **Read and extract.** Read approved files. Extract: public API surface, described behaviour, visible constraints, non-obvious invariants. Note what the code does NOT explain (caller intent, error handling rationale, non-obvious side effects).
|
||||
|
||||
3. **Gap check.** Present extracted behaviour to the user. Ask them to fill only the gaps — what the code does not explain. Log any explicitly deferred gaps. If the user requests to skip this step, log the reason and proceed.
|
||||
|
||||
4. **Draft section by section.** For each section: state the proposed content and its source (code line / spec section / user input). Show; confirm before moving to the next section.
|
||||
|
||||
5. **Confirmation gate.** Before finalising any section, show the full revised section. Wait for explicit confirmation or correction — never apply changes the user has not seen.
|
||||
|
||||
6. **Delta summary.** After each round of revisions: "Round N: changed [sections], added [X], removed [Y]."
|
||||
|
||||
7. **Reader Testing.** Predict 5–10 questions a target reader would ask. Spawn a scoped sub-agent that receives only the finished doc and the questions — no source files. Report its answers. If any answers fail, loop back to step 4.
|
||||
|
||||
8. **Finalise.** Write summary and overview sections last. Prompt the user to review the complete document before committing.
|
||||
|
||||
## Output format
|
||||
|
||||
- Markdown artifact with section headers; produced one section at a time — never as a single large dump
|
||||
- Delta summary after each refinement round: "Round N: [what changed]"
|
||||
- Reader Testing report: numbered question list with sub-agent answers
|
||||
- Final doc at the user-specified or conventionally appropriate path
|
||||
|
||||
## Failure handling
|
||||
|
||||
- Files not named and description too vague to propose candidates → ask for specific names before reading
|
||||
- Stage skipped without a logged reason → flag and require the one-sentence log before continuing
|
||||
- Code behaviour is undocumentable (internal implementation detail, no public spec) → note as out-of-scope in the doc; do not invent an explanation
|
||||
- Reader Testing sub-agent fails on multiple questions → surface the failures, return to step 4; do not mark complete
|
||||
- Requested output is a PRD, decision doc, or architecture proposal → redirect to `to-prd`, `grill-me`, or `grill-with-docs`
|
||||
|
||||
## Self-check
|
||||
|
||||
- [ ] All claims traceable to a source file or explicit user input
|
||||
- [ ] No invented behaviour — unverifiable claims removed
|
||||
- [ ] User approved specific files before reading
|
||||
- [ ] Any stage skips logged with reason
|
||||
- [ ] Full revised section shown before each confirmation gate
|
||||
- [ ] Delta summary produced after each refinement round
|
||||
- [ ] Reader Testing completed with scoped sub-agent (doc + questions only)
|
||||
- [ ] Summary/overview written last
|
||||
- [ ] User prompted to review before committing
|
||||
Reference in New Issue
Block a user