The git-workflow PR rule is in a composed skill an agent can finish a cross-repo task without ever loading #1114

New issue

Open

opened 2026-08-17 05:10:39 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-17 05:10:39 +00:00

Member

Filed by Lucia (AI Engineer seat) at Kai's direction, about my own violation during agentic-os#1104.

What I did

I pushed aos/claude/gh56-adopt-aos-eval to coilyco-flight-deck/agent-compose and stopped, opening no pull request. Kai opened it by hand as agent-compose#294 and asked whether a rule covered this. One does, verbatim in .agents/composed/coding-core-git-workflow/COMPOSED.md:

A pushed branch always gets a PR. Only remote-branch-only stops at the branch, and only when the caller resolved that lane. Unassigned work defaults to pull-request. A branch with no PR is litter nobody reviews.

agent-compose's resolved lane is merge-remote-main, not remote-branch-only, so the branch was litter. My reasoning was that the branch could not merge yet, because it pinned a tag the release train had not cut. Not-yet-mergeable is precisely what a PR is for, and the rule offers no such exemption.

The same file carries a second rule I also broke in the same commit:

Every commit closes a same-repo issue. File first, then commit with closes #N.

That commit referenced this repository's #1104, which is a different repo's tracker. agent-compose#295 is the retroactive same-repo issue.

Why this is worth an issue rather than a shrug

I had read this repo's AGENTS.md closely enough to quote its size caps and its promote-gate parity rule. coding-core-git-workflow was listed in my available skills the entire session. I never loaded it, because nothing in the task shape said "this is a git-workflow task" - it presented as a Python packaging task that happened to end in a push.

That is the failure mode: the rule fires at the end of a task whose beginning gave no signal to load it. Every substantive task ends in a commit and a push, so this skill is close to universal in practice while being opt-in by discovery.

Two things sharpen it:

AGENTS.md has a Release section that lists all four lanes (merge-remote-main, pull-request, pull-request-and-merge, remote-branch-only) and describes the PR-lane workflow in detail. Having read that, I had every reason to believe I knew the lane rules. What that section does not carry is the always-gets-a-PR rule or the same-repo-issue rule. So the eagerly-loaded source is not wrong, it is incomplete in a way that reads as complete.
The rule matters most in cross-repo work, where the lane differs per repo. This task touched agentic-os (pull-request-and-merge) and agent-compose (merge-remote-main). I resolved both lanes correctly from AGENTS.md frontmatter and still got the branch handling wrong, because the lane is not the whole rule.

Options, no strong preference

Promote the two sentences into AGENTS.md, next to the existing lane list, and leave the rest of the skill where it is. Smallest change, and it puts the rule in the source that already claims to describe the lanes. Costs AGENTS.md budget, which is deliberately tight here (290 lines / 26400 chars, currently near cap), so it likely has to displace something.
Make the skill's description fire on the actual trigger. It currently reads "Git workflow for Kai's repositories. Covers Forgejo, tracker choice, commits, pushes, PR lanes, issues, TODOs, and recovery." That describes contents rather than naming the moment an agent needs it. A description leading with "load before the first commit or push in any repo" would match how the rule is used.
Enforce it mechanically. A branch pushed to a non-remote-branch-only repo with no PR after some interval is detectable. ward exec up-to-date check git already exists as a read-only git-hygiene detector in agentic-os-kai and reports topology drift without repairing it. A no-PR-branch check fits that surface exactly, and unlike the doc options it catches the failure rather than hoping the agent read the right file.
Nothing. The rule is written and discoverable, and one agent not reading it is that agent's failure, which it was.

I lean toward 2 plus 3: the description fix is nearly free and targets discovery, and the detector catches what discovery misses. 1 is the one I would not do first, because AGENTS.md is already at deliberate back-pressure and this would displace something that binds every session for something that binds every push.

agent-compose#294 - the PR Kai opened by hand
agent-compose#295 - the retroactive same-repo issue
agentic-os#1104 - the work that produced the violation

Not claimed

I have not measured whether other agents hit this. One instance is one instance. If the detector in option 3 is built, its first run would answer that, and that is the evidence I would want before spending AGENTS.md budget on option 1.

Filed by Lucia (AI Engineer seat) at Kai's direction, about my own violation during agentic-os#1104. ## What I did I pushed `aos/claude/gh56-adopt-aos-eval` to `coilyco-flight-deck/agent-compose` and stopped, opening no pull request. Kai opened it by hand as agent-compose#294 and asked whether a rule covered this. One does, verbatim in [`.agents/composed/coding-core-git-workflow/COMPOSED.md`](.agents/composed/coding-core-git-workflow/COMPOSED.md): > A pushed branch always gets a PR. Only `remote-branch-only` stops at the branch, and only when the caller resolved that lane. Unassigned work defaults to `pull-request`. A branch with no PR is litter nobody reviews. agent-compose's resolved lane is `merge-remote-main`, not `remote-branch-only`, so the branch was litter. My reasoning was that the branch could not merge yet, because it pinned a tag the release train had not cut. Not-yet-mergeable is precisely what a PR is for, and the rule offers no such exemption. The same file carries a second rule I also broke in the same commit: > Every commit closes a same-repo issue. File first, then commit with `closes #N`. That commit referenced this repository's #1104, which is a different repo's tracker. agent-compose#295 is the retroactive same-repo issue. ## Why this is worth an issue rather than a shrug I had read this repo's `AGENTS.md` closely enough to quote its size caps and its promote-gate parity rule. `coding-core-git-workflow` was listed in my available skills the entire session. I never loaded it, because nothing in the task shape said "this is a git-workflow task" - it presented as a Python packaging task that happened to end in a push. That is the failure mode: **the rule fires at the end of a task whose beginning gave no signal to load it.** Every substantive task ends in a commit and a push, so this skill is close to universal in practice while being opt-in by discovery. Two things sharpen it: * `AGENTS.md` has a **Release** section that lists all four lanes (`merge-remote-main`, `pull-request`, `pull-request-and-merge`, `remote-branch-only`) and describes the PR-lane workflow in detail. Having read that, I had every reason to believe I knew the lane rules. What that section does not carry is the always-gets-a-PR rule or the same-repo-issue rule. So the eagerly-loaded source is not wrong, it is incomplete in a way that reads as complete. * The rule matters most in **cross-repo** work, where the lane differs per repo. This task touched agentic-os (`pull-request-and-merge`) and agent-compose (`merge-remote-main`). I resolved both lanes correctly from `AGENTS.md` frontmatter and still got the branch handling wrong, because the lane is not the whole rule. ## Options, no strong preference 1. **Promote the two sentences into `AGENTS.md`**, next to the existing lane list, and leave the rest of the skill where it is. Smallest change, and it puts the rule in the source that already claims to describe the lanes. Costs `AGENTS.md` budget, which is deliberately tight here (290 lines / 26400 chars, currently near cap), so it likely has to displace something. 2. **Make the skill's description fire on the actual trigger.** It currently reads "Git workflow for Kai's repositories. Covers Forgejo, tracker choice, commits, pushes, PR lanes, issues, TODOs, and recovery." That describes contents rather than naming the moment an agent needs it. A description leading with "load before the first commit or push in any repo" would match how the rule is used. 3. **Enforce it mechanically.** A branch pushed to a non-`remote-branch-only` repo with no PR after some interval is detectable. `ward exec up-to-date check git` already exists as a read-only git-hygiene detector in agentic-os-kai and reports topology drift without repairing it. A no-PR-branch check fits that surface exactly, and unlike the doc options it catches the failure rather than hoping the agent read the right file. 4. **Nothing.** The rule is written and discoverable, and one agent not reading it is that agent's failure, which it was. I lean toward 2 plus 3: the description fix is nearly free and targets discovery, and the detector catches what discovery misses. 1 is the one I would not do first, because `AGENTS.md` is already at deliberate back-pressure and this would displace something that binds every session for something that binds every push. ## Related * agent-compose#294 - the PR Kai opened by hand * agent-compose#295 - the retroactive same-repo issue * agentic-os#1104 - the work that produced the violation ## Not claimed I have not measured whether other agents hit this. One instance is one instance. If the detector in option 3 is built, its first run would answer that, and that is the evidence I would want before spending `AGENTS.md` budget on option 1.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agentic-os#1114

No description provided.

Rows
Columns