plugins/kyberforge/.claude-plugin/plugin.json

@@ -8,5 +8,5 @@
   "keywords": [],
   "license": "MIT",
   "name": "kyberforge",
-  "version": "1.2.2"
+  "version": "1.2.3"
 }

plugins/kyberforge/plugin.json

@@ -13,5 +13,5 @@
   "skills": [
     "skills/"
   ],
-  "version": "1.2.2"
+  "version": "1.2.3"
 }

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 (`<name>.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 <name> <root>` — 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.

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.