kyberforge:skill-author must not self-spawn its own independent-recheck subagent #71

New Issue

Claude · 2026-07-05T11:37:11Z

Claude commented

2026-07-05 11:37:11 +00:00

Context

During the issue #6 gitea plugin redesign session, an agent building the gitea-prs skill routed through kyberforge:forge → kyberforge:skill-author as designed. Per forge's documented process, the flow should be: author (in a fork), inline audit (skill-audit, same context), then forge's own outer loop runs a separate independent recheck via a clean-context subagent — that independent-recheck layer is explicitly forge's responsibility, not the author fork's.

In this run, the skill-author authoring fork instead self-spawned its own "independent recheck" subagent internally — a violation of that process boundary. While that self-spawned stray subagent was running, its worktree was torn down by concurrent cleanup (a separate environment issue, but triggered by this bug), destroying the first draft of the skill before any commit had happened. The parent agent had to detect this, rebuild all six files from scratch in a stable checkout, fold in the (still-valid) findings from the stray recheck, and commit for real — then the coordinator separately ran forge's actual required independent recheck (a fresh general-purpose agent invoking kyberforge:skill-audit with no inherited context) against the committed artifact, since the self-spawned one didn't count.

Recommendation

kyberforge:skill-author's documented process should explicitly forbid spawning any further subagents for auditing/rechecking purposes during the authoring pass — that responsibility belongs solely to forge's outer loop, never delegated inward. This should be stated as a hard rule in the skill's body, not just implied by the division of responsibility between forge and skill-author.

Follow-up from the issue #6 gitea plugin redesign session.

## Context During the issue #6 gitea plugin redesign session, an agent building the `gitea-prs` skill routed through `kyberforge:forge` → `kyberforge:skill-author` as designed. Per forge's documented process, the flow should be: author (in a fork), inline audit (skill-audit, same context), then forge's own outer loop runs a *separate* independent recheck via a clean-context subagent — that independent-recheck layer is explicitly forge's responsibility, not the author fork's. In this run, the `skill-author` authoring fork instead self-spawned its own "independent recheck" subagent internally — a violation of that process boundary. While that self-spawned stray subagent was running, its worktree was torn down by concurrent cleanup (a separate environment issue, but triggered by this bug), destroying the first draft of the skill before any commit had happened. The parent agent had to detect this, rebuild all six files from scratch in a stable checkout, fold in the (still-valid) findings from the stray recheck, and commit for real — then the coordinator separately ran forge's *actual* required independent recheck (a fresh general-purpose agent invoking `kyberforge:skill-audit` with no inherited context) against the committed artifact, since the self-spawned one didn't count. ## Recommendation `kyberforge:skill-author`'s documented process should explicitly forbid spawning any further subagents for auditing/rechecking purposes during the authoring pass — that responsibility belongs solely to `forge`'s outer loop, never delegated inward. This should be stated as a hard rule in the skill's body, not just implied by the division of responsibility between forge and skill-author. Follow-up from the issue #6 gitea plugin redesign session.

Claude added the Kind/Bug

Priority

Medium

3

labels 2026-07-05 11:37:11 +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): tighten skill-author checklist/phrasing/reference style

Defame1297 referenced this issue from a commit