refactor(kyberforge): retrofit forge to the ADR-0020 contract
Description 648 -> 387 chars, body 1093 -> 541 words. This was the last body FAIL in the 39-skill corpus. The body was not trimmed to fit. forge routes four artifact types that a single invocation classifies between, so the contract requires a dispatch table plus the gates common to every route, with each route self-contained in references/. Adds references/author-routes.md (skill and agent), references/apm-routes.md (plugin and marketplace entry) and references/version-bump.md. Skill and agent share one file: they differ on one axis only, which audit skill verifies the result. Fixes three defects the first pass introduced or relocated: - references/apm-routes.md claimed `apm audit` "already runs inside apm-workflow's own flow" and told the agent to confirm it ran clean. apm-workflow dispatches audit as its own row; the configure and marketplace rows never reach it. That was the only completion check these routes had, and it could never be satisfied. Replaced with a manual read-back the agent performs itself. - "Read only the reference file" forbade the multi-artifact case the same body documents two lines later, and ADR-0011 records eight artifacts authored in one pass. - The announce gate became a closing gate, reachable only after the invocation it was meant to precede. Moved to the end of Step 2. Also restores the artifact enumeration to the plugin row, normalises to bare unnamespaced skill names per AGENTS.md, adds a dispatch fallback for artifacts matching no row, and corrects three provenance entries -- one asserted a contribution that did not happen. Refs #99 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MWb5RQgCL1ye7cGp2RPb2u
This commit is contained in:
@@ -0,0 +1,42 @@
|
||||
---
|
||||
source_keys:
|
||||
- claude-code-subagents-docs
|
||||
---
|
||||
|
||||
# Routing a plugin or marketplace entry to apm-workflow
|
||||
|
||||
Reached from `SKILL.md` Step 2 when the classified artifact is a plugin or a marketplace entry.
|
||||
Both route to `apm-workflow` — a plugin to its configure flow (`apm plugin init`), a marketplace
|
||||
entry to its marketplace flow (`apm marketplace package add`).
|
||||
|
||||
No other skill is a candidate for these two rows: `plugin-author` and `marketplace-author` were
|
||||
removed per ADR-0015 once issue #90 landed, and `apm-workflow` is their sole successor.
|
||||
|
||||
## Always inline, never forked
|
||||
|
||||
Run these routes inline, in the current conversation. Their flows are short, prompt-heavy or
|
||||
gated — `apm-workflow`'s publish and release steps take a HITL gate, and removing a marketplace
|
||||
entry takes a conversational confirmation — and a backgrounded fork cannot surface those
|
||||
checkpoints to the user in real time.
|
||||
|
||||
## No clean-context recheck, and no automatic audit
|
||||
|
||||
Skill and agent routes close with a clean-context audit rerun; these two do not, and the omission
|
||||
is deliberate rather than an oversight. Neither artifact type has an audit skill counterpart to
|
||||
re-run, so detaching the route to earn a recheck it would never get buys nothing.
|
||||
|
||||
These routes get no automated terminal check either. `apm audit` is a separate action on
|
||||
`apm-workflow`'s own dispatch table, not a closing step of the configure or marketplace flow a
|
||||
forge route lands in, so a completion message from either says nothing about it. Do not wait for
|
||||
one and do not report one you did not see.
|
||||
|
||||
Verify by hand instead. Read back what the route wrote against what the grill settled:
|
||||
|
||||
- **Plugin** — the package directory exists where the intent said it should, and its `apm.yml`
|
||||
carries the intended `name`, a top-level `type:` field, and a `version`.
|
||||
- **Marketplace entry** — the entry names that package, points at the source the intent settled
|
||||
on, and carries the version the package actually declares.
|
||||
|
||||
If the change warrants the full integrity and policy check rather than a read-back, invoke
|
||||
`apm-workflow` again for its audit action and run `apm audit` deliberately. Then return to
|
||||
`SKILL.md` Step 3 for the closing gates common to every route.
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
source_keys:
|
||||
- claude-code-subagents-docs
|
||||
---
|
||||
|
||||
# Routing a skill or agent to its author skill
|
||||
|
||||
Reached from `SKILL.md` Step 2 when the classified artifact is a skill or an agent/subagent
|
||||
definition. Route a skill to `skill-author` and an agent to `agent-author`. The two branches
|
||||
differ on one axis only — which audit skill verifies the result — and everything below applies to
|
||||
both.
|
||||
|
||||
## Choose fork or inline
|
||||
|
||||
Default to a **fork subagent**. It inherits the full grilled-intent conversation, so the author
|
||||
skill does not need re-briefing on what the user asked for or what the grill settled.
|
||||
|
||||
Fall back to an **inline invocation** — same conversation, no subagent — when either holds:
|
||||
|
||||
- **Fork is technically unavailable.** You are already running inside a fork (a fork cannot spawn
|
||||
another fork), a nesting-depth cap is reached, or the environment does not support forking.
|
||||
- **The routed flow needs live user interaction mid-run** that a backgrounded fork cannot surface
|
||||
in real time: clarifying questions, confirmation checkpoints, or a HITL gate. Judge this from
|
||||
context — if nothing about the flow signals a live checkpoint, prefer the fork.
|
||||
|
||||
## Two-tier verification
|
||||
|
||||
Both author skills already close out with their own inline audit, in the same context as the
|
||||
authoring work: `skill-author` runs `/skill-audit`, `agent-author` invokes
|
||||
`agent-audit`. That is tier one, and forge does not change it.
|
||||
|
||||
Tier two belongs to forge. Once the author skill's run has finished, spin up a separate
|
||||
**clean-context subagent** — fresh, not forked, no inherited context — to independently re-run the
|
||||
same audit skill against the finished artifact. This is a distinct verification layer, not a
|
||||
duplicate: the inline audit shares context with the work it is checking and can share its blind
|
||||
spots, while the clean rerun has no stake in the result.
|
||||
|
||||
If the clean audit surfaces any unresolved finding — not only a disagreement with the inline pass,
|
||||
any actionable finding on its own — loop: re-invoke the author skill (same fork-versus-inline
|
||||
judgment as the first invocation) to resolve it, then re-run the clean audit. Repeat until the
|
||||
clean audit comes back with nothing unresolved. Only then is the route done. This is the same
|
||||
resolve-before-close discipline the author skills already apply to their own inline audit.
|
||||
|
||||
Return to `SKILL.md` Step 3 for the closing gates common to every route once the loop closes.
|
||||
@@ -4,15 +4,15 @@
|
||||
|
||||
- **URL:** https://code.claude.com/docs/en/sub-agents
|
||||
- **Research doc:** plugins/kyberforge/docs/research/docs/claude-code-plugins/sources.md
|
||||
- **Description:** Official Claude Code subagent reference — definition format, all frontmatter fields, scope priority, built-in agents, CLI flags, environment variables, known limitations. Grounds Step 3's fork-vs-inline invocation logic: fork inherits full conversation history via `/fork` or `subagent_type: "fork"`, is not a declarable frontmatter field on any agent definition, cannot be nested (a fork cannot spawn another fork), and is a caller-side invocation choice rather than a property of the artifact being routed to.
|
||||
- **Contributing files:** SKILL.md
|
||||
- **Description:** Official Claude Code subagent reference — definition format, all frontmatter fields, scope priority, built-in agents, CLI flags, environment variables, known limitations. Grounds the fork-vs-inline invocation logic in `references/author-routes.md`, the always-inline decision for the apm routes in `references/apm-routes.md`, and the clean-context bump subagent in `references/version-bump.md`: fork inherits full conversation history via `/fork` or `subagent_type: "fork"`, is not a declarable frontmatter field on any agent definition, cannot be nested (a fork cannot spawn another fork), and is a caller-side invocation choice rather than a property of the artifact being routed to.
|
||||
- **Contributing files:** SKILL.md, references/author-routes.md, references/apm-routes.md, references/version-bump.md
|
||||
- **Status:** `extracted`
|
||||
|
||||
## context7-websites-code-claude
|
||||
|
||||
- **URL:** context7:/websites/code_claude
|
||||
- **Research doc:** plugins/kyberforge/docs/research/docs/claude-code-plugins/sources.md
|
||||
- **Description:** Official Claude Code documentation site indexed by Context7 — confirms the `context: fork` skill-level frontmatter field means isolated/fresh execution, the opposite of what the `/fork` subagent command does (inherits conversation). Informs the Gotchas entry warning against conflating the two.
|
||||
- **Description:** Official Claude Code documentation site indexed by Context7 — confirms the `context: fork` skill-level frontmatter field means isolated/fresh execution, the opposite of what the `/fork` subagent command does (inherits conversation). Informs the Gotchas entry in `SKILL.md` warning against conflating the two; nothing else in this skill draws on it, and no `references/` file mentions the `context: fork` field.
|
||||
- **Contributing files:** SKILL.md
|
||||
- **Status:** `extracted`
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
|
||||
- **URL:** https://agentskills.io/specification.md
|
||||
- **Research doc:** plugins/kyberforge/docs/research/docs/agentskillsio/sources.md
|
||||
- **Description:** Complete SKILL.md format specification — confirms `assets/`, `references/`, and `scripts/` are warranted only by the bulk/reusability of supporting content (large reference material, executable code, templates), not by a skill's category. forge has none of that bulk, so a lean SKILL.md-plus-provenance-file shape is spec-legitimate; the `references/sources.md` in this directory exists for this repo's own provenance-chain convention (see `CONTEXT.md`), not because the spec requires it.
|
||||
- **Description:** Complete SKILL.md format specification — confirms `assets/`, `references/`, and `scripts/` are warranted only by the bulk/reusability of supporting content (large reference material, executable code, templates), not by a skill's category, and forge's per-route procedures are that kind of supporting content — so the spec permits the `references/` split here but does not require it. The warrant is a house decision: ADR-0020's rule that dispatch is mandatory at two or more mutually exclusive flows, which forge's four-row table is. `references/sources.md` likewise exists for this repo's own provenance-chain convention (see `CONTEXT.md`), not because the spec requires it.
|
||||
- **Contributing files:** SKILL.md
|
||||
- **Status:** `extracted`
|
||||
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
source_keys:
|
||||
- claude-code-subagents-docs
|
||||
---
|
||||
|
||||
# Bumping the package version after a route
|
||||
|
||||
Reached from `SKILL.md` Step 3 when a route has finished and its completion message carries no
|
||||
evidence that the package version was bumped. The author skills bump it themselves in some flows,
|
||||
so check their output before doing anything here — a second bump for one artifact is wrong.
|
||||
|
||||
## Find the owning package
|
||||
|
||||
Walk up from the artifact's path to the nearest ancestor `apm.yml` that declares a top-level
|
||||
`type:` field (`instructions`, `skill`, `hybrid` or `prompts`).
|
||||
|
||||
An `apm.yml` with **no** `type:` field is a marketplace-only manifest: it lists packages rather
|
||||
than declaring one, so it does not count as a match. Skip it and keep walking up.
|
||||
|
||||
Skip this step entirely if no ancestor `apm.yml` carries a `type:` field: the artifact is then
|
||||
standalone or scoped to a user agent directory, and there is no package to version.
|
||||
|
||||
## Delegate the bump
|
||||
|
||||
Invoke `apm-workflow` as a **clean-context subagent** — fresh, not forked — with this
|
||||
brief:
|
||||
|
||||
> "The package at `<package-path>` gained a new `<artifact-type>` (`<artifact-name>`). Bump the
|
||||
> `version` field in that package's `apm.yml`. Determine whether to bump minor (0.1.0) or patch
|
||||
> (0.0.1) based on whether this is a new capability (minor) or a fix/refactor (patch). Do not
|
||||
> release or tag — just update `apm.yml` and commit."
|
||||
|
||||
Clean context rather than a fork is the point: the bump decision is made independently, without
|
||||
anchoring on the authoring conversation that just argued for the artifact's significance.
|
||||
|
||||
Then report to the user: "Updated `<package-name>` version from X.Y.Z to X.Y.Z to reflect the new
|
||||
`<artifact-name>`."
|
||||
Reference in New Issue
Block a user