Add forge skill to kyberforge — orchestrates grill + artifact-type routing #61

New Issue

Claude · 2026-07-04T15:54:40Z

Claude commented

2026-07-04 15:54:40 +00:00

Problem

kyberforge ships 6 factory skills (skill-author, skill-audit, agent-author, agent-audit, plugin-author, marketplace-author) but nothing enforces grilling intent before jumping to implementation, and nothing helps a user classify which of the 4 artifact types (skill, agent/subagent, plugin, marketplace entry) their idea actually needs.

Design

Add plugins/kyberforge/skills/forge/SKILL.md, category factory.

Flow:

Call grill-with-docs against this repo's CONTEXT.md + relevant docs/adr/ to refine the user's intent before any authoring starts.
Classify the target artifact type against a decision table (new to this skill — no existing doc covers it beyond skill-vs-subagent in decision-criteria.md):
- new reusable capability/workflow → skill
- task needing an isolated execution context → agent (subagent definition, per ADR-0010)
- bundle of skills/agents/hooks/MCP servers for distribution → plugin
- listing/updating an existing plugin's marketplace visibility → marketplace entry
Announce the classification and which skill(s) will run (governance requirement: state before writing).
Invoke the matching *-author skill(s) — chained in sequence if the intent spans more than one artifact type (e.g. a new skill inside a new plugin, then registering that plugin in the marketplace).
Stop. Audit is NOT forge's responsibility — skill-author and agent-author already call their own audit skill (skill-audit / agent-audit) internally at closeout. plugin-author and marketplace-author have no audit counterpart at all, so forge does not invent one.

Explicitly out of scope

forge does not replace direct invocation of the 6 existing skills — they remain independently usable.
forge is in-plugin skill composition (kyberforge orchestrating its own skills), not the "cross-project automation" orchestration deferred to Chunk 5 by ADR-0008 — those are different concerns, no ADR conflict.
forge does not implement its own audit loop.

Reference

CONTEXT.md's "Skill composition" glossary entry has already been updated with this composition (see repo root CONTEXT.md).

Next step

A follow-up task will invoke /skill-author to implement plugins/kyberforge/skills/forge/ per this design.

## Problem kyberforge ships 6 factory skills (skill-author, skill-audit, agent-author, agent-audit, plugin-author, marketplace-author) but nothing enforces grilling intent before jumping to implementation, and nothing helps a user classify which of the 4 artifact types (skill, agent/subagent, plugin, marketplace entry) their idea actually needs. ## Design Add `plugins/kyberforge/skills/forge/SKILL.md`, category `factory`. Flow: 1. Call `grill-with-docs` against this repo's `CONTEXT.md` + relevant `docs/adr/` to refine the user's intent before any authoring starts. 2. Classify the target artifact type against a decision table (new to this skill — no existing doc covers it beyond skill-vs-subagent in decision-criteria.md): - new reusable capability/workflow → skill - task needing an isolated execution context → agent (subagent definition, per ADR-0010) - bundle of skills/agents/hooks/MCP servers for distribution → plugin - listing/updating an existing plugin's marketplace visibility → marketplace entry 3. Announce the classification and which skill(s) will run (governance requirement: state before writing). 4. Invoke the matching `*-author` skill(s) — chained in sequence if the intent spans more than one artifact type (e.g. a new skill inside a new plugin, then registering that plugin in the marketplace). 5. Stop. Audit is NOT forge's responsibility — `skill-author` and `agent-author` already call their own audit skill (skill-audit / agent-audit) internally at closeout. `plugin-author` and `marketplace-author` have no audit counterpart at all, so forge does not invent one. ## Explicitly out of scope - forge does not replace direct invocation of the 6 existing skills — they remain independently usable. - forge is in-plugin skill composition (kyberforge orchestrating its own skills), not the "cross-project automation" orchestration deferred to Chunk 5 by ADR-0008 — those are different concerns, no ADR conflict. - forge does not implement its own audit loop. ## Reference CONTEXT.md's "Skill composition" glossary entry has already been updated with this composition (see repo root CONTEXT.md). ## Next step A follow-up task will invoke `/skill-author` to implement `plugins/kyberforge/skills/forge/` per this design.

Claude added the Kind/Feature

Priority

Medium

3

labels 2026-07-04 15:54:40 +00:00

Defame1297 added the

Reviewed

Confirmed

1

label 2026-07-04 15:55:57 +00:00

Defame1297 added this to the Kyberforge basics milestone 2026-07-04 15:56:03 +00:00

Defame1297 referenced this issue from a commit