kyberforge skill/agent authoring should require git log verification, not just git diff, before reporting a task done #69

New Issue

Claude · 2026-07-05T11:35:59Z

Claude commented

2026-07-05 11:35:59 +00:00

Context

During the issue #6 gitea plugin redesign session, which involved many parallel subagents each authoring one skill via kyberforge:forge → kyberforge:skill-author (or agent-author), at least four separate agent runs reported task completion after only staging their changes (git add) — never actually running git commit. Each one had verified its own work only via git diff main --stat showing non-empty output, which is not sufficient: staged-but-uncommitted changes are not part of any commit and would be silently lost the moment that agent's worktree is cleaned up (which happened to be a real, recurring event in this session due to unrelated worktree-lifecycle issues).

The coordinator had to manually catch each instance via git status/git log --oneline -1 and run git commit on the agent's behalf before merging — this happened for the research-backfill task, the gitea-files skill, the gitea-releases skill, and the gitea-labels-milestones skill (4 of the ~8 authoring passes in the session).

Recommendation

The completion criteria documented in kyberforge:skill-author and kyberforge:agent-author (and anywhere else that instructs an agent to author-then-report-done) should explicitly require confirming a new commit hash exists — e.g. capture git log --oneline -1 before starting and again before reporting done, and assert they differ — rather than accepting git diff <base> --stat as sufficient proof of durable completion. git diff against a base ref shows working-tree state, not commit state, and doesn't protect against exactly the failure mode observed here.

## Context During the issue #6 gitea plugin redesign session, which involved many parallel subagents each authoring one skill via `kyberforge:forge` → `kyberforge:skill-author` (or `agent-author`), at least four separate agent runs reported task completion after only staging their changes (`git add`) — never actually running `git commit`. Each one had verified its own work only via `git diff main --stat` showing non-empty output, which is not sufficient: staged-but-uncommitted changes are not part of any commit and would be silently lost the moment that agent's worktree is cleaned up (which happened to be a real, recurring event in this session due to unrelated worktree-lifecycle issues). The coordinator had to manually catch each instance via `git status`/`git log --oneline -1` and run `git commit` on the agent's behalf before merging — this happened for the research-backfill task, the gitea-files skill, the gitea-releases skill, and the gitea-labels-milestones skill (4 of the ~8 authoring passes in the session). ## Recommendation The completion criteria documented in `kyberforge:skill-author` and `kyberforge:agent-author` (and anywhere else that instructs an agent to author-then-report-done) should explicitly require confirming a *new commit hash* exists — e.g. capture `git log --oneline -1` before starting and again before reporting done, and assert they differ — rather than accepting `git diff <base> --stat` as sufficient proof of durable completion. `git diff` against a base ref shows working-tree state, not commit state, and doesn't protect against exactly the failure mode observed here.

Claude added the Kind/Bug

Priority

Medium

3

labels 2026-07-05 11:35:59 +00:00

Defame1297 referenced this issue from a commit

2026-07-05 13:20:43 +00:00

fix(kyberforge): require commit-hash verification and forbid self-spawned rechecks in skill-author

Defame1297 referenced this issue from a commit

2026-07-05 13:20:43 +00:00

fix(kyberforge): surface commit-hash checklist earlier, drop redundant scripts line in skill-author

Defame1297 referenced this issue from a commit