diff --git a/plugins/kyberforge/.claude-plugin/plugin.json b/plugins/kyberforge/.claude-plugin/plugin.json index 5894989..8a5badf 100644 --- a/plugins/kyberforge/.claude-plugin/plugin.json +++ b/plugins/kyberforge/.claude-plugin/plugin.json @@ -8,5 +8,5 @@ "keywords": [], "license": "MIT", "name": "kyberforge", - "version": "1.2.2" + "version": "1.2.3" } diff --git a/plugins/kyberforge/plugin.json b/plugins/kyberforge/plugin.json index 1225684..f540bc0 100644 --- a/plugins/kyberforge/plugin.json +++ b/plugins/kyberforge/plugin.json @@ -13,5 +13,5 @@ "skills": [ "skills/" ], - "version": "1.2.2" + "version": "1.2.3" } diff --git a/plugins/kyberforge/skills/agent-author/SKILL.md b/plugins/kyberforge/skills/agent-author/SKILL.md index bcddd9f..936e6b7 100644 --- a/plugins/kyberforge/skills/agent-author/SKILL.md +++ b/plugins/kyberforge/skills/agent-author/SKILL.md @@ -57,7 +57,7 @@ Before touching the filesystem, confirm you have: - [ ] Agent purpose — one sentence describing the task this agent handles - [ ] Trigger condition — when should the runtime delegate to this agent? -If any are missing, stop and ask before proceeding. +If any are missing, stop and ask before proceeding. Then capture `git log --oneline -1` before touching the filesystem — Step 5 needs it to verify a real commit landed. Verify `kyberforge:agent-audit` is available — it ships with the kyberforge plugin and is co-installed with this skill. If unavailable, stop and tell the user to install the kyberforge plugin before continuing. @@ -180,19 +180,23 @@ Run this checklist before invoking the audit: - [ ] If plugin scope: no `hooks`, `mcpServers`, or `permissionMode` (silently ignored at plugin scope) - [ ] System prompt body present and non-empty - [ ] No `FILL IN:` placeholders remain +- [ ] No `` template comments remain in frontmatter **Copilot CLI file (`.agent.md`):** - [ ] File extension is `.agent.md` (not `.md`) - [ ] `name` field matches the filename stem (e.g. `name: my-agent` in `my-agent.agent.md`) - [ ] `description` field present -- [ ] No Claude Code-only fields (`maxTurns`, `isolation`, `memory`, `permissionMode`, `effort`) +- [ ] No Claude Code-only fields (`maxTurns`, `isolation`, `memory`, `permissionMode`, `effort`, `hooks`, `mcpServers`) - [ ] System prompt body present and non-empty - [ ] Body does not exceed 30,000 characters +- [ ] No `` template comments remain in frontmatter If the destination is inside a plugin directory, apply a **minor bump** to the `version` field in both `plugin.json` and `.claude-plugin/plugin.json` at the plugin root in the same edit pass (e.g. `1.0.4` → `1.1.0`). Invoke the `kyberforge:agent-audit` skill directly on the created files to confirm the pair is valid before closing. +**Commit verification.** Capture `git log --oneline -1` before Step 1 and keep it. Once the audit is clean, run `git add` and `git commit` for the new agent files — do not stop at staging. Then run `git log --oneline -1` again and confirm the hash changed from the one you captured at the start. A non-empty `git diff --stat` is not sufficient proof of completion: staged-but-uncommitted work isn't part of any commit and can be silently lost if the working tree is cleaned up before a commit lands. Only report the agent as done once the hash has actually changed. + ## Improving an existing agent ### Step 1 — Verify inputs @@ -201,6 +205,10 @@ Confirm the agent files exist and at least one improvement signal is present in If no signals: "This skill applies existing signals to an agent. For a blind review, examine the files manually or run a grill session first." +Verify `kyberforge:agent-audit` is available — it ships with the kyberforge plugin and is co-installed with this skill. If unavailable, stop and tell the user to install the kyberforge plugin before continuing. + +Capture `git log --oneline -1` now, before making any edits — Step 5 needs it to verify a real commit landed. + **Partial state** — if one provider file exists but the other does not, scaffold the missing file first (run `bash scripts/new-agent.sh ` — the file-by-file no-op means only the missing file is created), then continue with the improve flow on both files. ### Step 2 — Gather and group signals @@ -224,6 +232,8 @@ Before editing, state which root causes were identified, what evidence supports Edit any file the signals point to. Generalize the fix — find the underlying gap, not the specific example that failed. For every sentence you add, ask: "Would the agent get this wrong without it?" A shorter, focused definition consistently outperforms an exhaustive one. For Copilot files, verify no Claude Code-only fields are introduced. +If the edit adds or removes research-sourced content, update `source_keys` in the edited file(s) and the corresponding entry in `sources.md` per Create flow's Step 4. + ### Step 5 — Validate and close Re-run the validation checklist from the create flow's Step 5 on any edited file. @@ -231,3 +241,5 @@ Re-run the validation checklist from the create flow's Step 5 on any edited file If the agent lives inside a plugin directory, apply a **patch bump** to the `version` field in both `plugin.json` and `.claude-plugin/plugin.json` at the plugin root in the same edit pass (e.g. `1.0.4` → `1.0.5`). Invoke the `kyberforge:agent-audit` skill directly on the edited files to confirm no regressions before closing. + +**Commit verification.** Capture `git log --oneline -1` at the start of Step 1 and keep it. Once the audit is clean, run `git add` and `git commit` for the changed files — do not stop at staging. Then run `git log --oneline -1` again and confirm the hash changed from the one you captured at the start. A non-empty `git diff --stat` is not sufficient proof of completion: staged-but-uncommitted work isn't part of any commit and can be silently lost if the working tree is cleaned up before a commit lands. Only report the improvement as done once the hash has actually changed. diff --git a/plugins/kyberforge/skills/skill-author/SKILL.md b/plugins/kyberforge/skills/skill-author/SKILL.md index cd41916..35911d0 100644 --- a/plugins/kyberforge/skills/skill-author/SKILL.md +++ b/plugins/kyberforge/skills/skill-author/SKILL.md @@ -26,6 +26,7 @@ metadata: - Patching per symptom is the default failure mode. Three eval failures may all trace to one missing instruction — always identify the root cause before editing. - Do not create new scripts unless a signal explicitly calls for it. Writing scripts from scratch requires transcript analysis that is out of scope here; flag the opportunity as a suggestion instead. +- Never spawn a subagent to audit or recheck your own work during an authoring pass. Run `/skill-audit` yourself, inline, in the same context as the edits you just made. A *separate* independent recheck via a clean-context subagent is the `/forge` skill's outer-loop responsibility exclusively — delegating it inward here duplicates that layer and introduces a race: a stray self-spawned subagent can have its worktree torn down by concurrent cleanup, destroying an uncommitted draft before it was ever safe. ## Route @@ -50,6 +51,7 @@ Design for one coherent user intent — skills too narrow force multiple loads p - [ ] A clear purpose — what specific task will this skill handle? - [ ] Trigger scenarios — when should an agent activate it, including indirect cases? - [ ] Skill name (kebab-case) and destination path +- [ ] Capture `git log --oneline -1` now, before touching the filesystem — Step 6 needs it to verify a real commit landed If any are missing, stop and ask the user before proceeding. @@ -222,6 +224,8 @@ All FAIL findings must be resolved before the skill is considered done. If the skill is versioned (`metadata.version`), set it to the next **minor** version (e.g. `0.2.0` → `0.3.0`). New skills without a prior version start at `0.1.0`. +**Commit verification.** Capture `git log --oneline -1` before Step 1 and keep it. Once the audit is clean, run `git add` and `git commit` for the new skill files — do not stop at staging. Then run `git log --oneline -1` again and confirm the hash changed from the one you captured at the start. A non-empty `git diff --stat` is not sufficient proof of completion: staged-but-uncommitted work isn't part of any commit and can be silently lost if the working tree is cleaned up before a commit lands. Only report the skill as done once the hash has actually changed. + ## Improving an existing skill ### Step 1 — Verify inputs @@ -230,6 +234,8 @@ Confirm the skill directory path exists and that at least one improvement signal If the skill dir is missing, ask for it. If no signals are present, stop: "This skill applies existing signals to a skill. For a blind review without signals, use `/skill-audit` instead." +Capture `git log --oneline -1` now, before making any edits — Step 5 needs it to verify a real commit landed. + Signals can come from anywhere in the conversation or referenced files: - Grill session output (most common predecessor in the factory sequence) - `/skill-audit` findings (PASS/FAIL/SUGGESTION punch list) @@ -272,8 +278,6 @@ Edit any file in the skill directory that the signals point to: SKILL.md, script If a signal points to a script or reference file, edit that file directly rather than adding a workaround in SKILL.md. -**On scripts**: Fix and edit existing scripts freely when signals point to them. - ### Step 5 — Validate and close Before running the audit, confirm: @@ -284,3 +288,5 @@ Before running the audit, confirm: Run `/skill-audit` on the skill directory. Resolve any FAIL findings before considering the improvement complete. If the skill is versioned (`metadata.version`), bump the **patch** version (e.g. `0.1.0` → `0.1.1`). + +**Commit verification.** Capture `git log --oneline -1` at the start of Step 1 and keep it. Once the audit is clean, run `git add` and `git commit` for the changed files — do not stop at staging. Then run `git log --oneline -1` again and confirm the hash changed from the one you captured at the start. A non-empty `git diff --stat` is not sufficient proof of completion: staged-but-uncommitted work isn't part of any commit and can be silently lost if the working tree is cleaned up before a commit lands. Only report the improvement as done once the hash has actually changed.