Fix the Misleading ssh-add Signing Check in git-commit-conventions

[ptr727]

What happened

Working in a session on this host, I was about to make the fleet's first agent-authored commit
of the session and followed git-commit-conventions's verification step literally:

git config --get commit.gpgsign && ssh-add -L

commit.gpgsign read true. ssh-add -L failed: Could not open a connection to your authentication agent. I then checked the Windows ssh-agent service and found it Stopped /
Disabled.

Following the skill's rule ("If signing is not configured, do not commit... surface the missing
config and stop at git add"), I concluded signing was broken on this host, stopped short of
committing, and reported the ssh-agent gap to the maintainer as a blocker.

It was not a real blocker. A second agent, in a separate session, tested it directly: created a
scratch commit with git commit -S, then git log --show-signature verified it, "Good git
signature." Signing worked cleanly the whole time. I then reproduced that myself: git commit -S
on real work succeeded and verified clean, with the ssh-agent service still Stopped/Disabled,
unchanged.

Why the verification step is wrong, not just my reading of it

ssh-keygen -Y sign (what git commit -S shells out to under gpg.format = ssh) can sign
directly from a private key file on disk. It does not need a running ssh-agent, and only
reaches for one when the key is not otherwise available. ssh-add -L tests one specific delivery
path (an agent holding the key) that this host's actual setup does not use at all: a plain,
non-agent-backed SSH private key file. ssh-add -L failing here was a true, reproducible fact,
and it said nothing about whether git commit -S would succeed. I treated it as though it did.

I also spent real time chasing a second red herring once the mismatch surfaced: the last several
commits on this branch were signed with a GPG/OpenPGP RSA key, not SSH, which looked like more
evidence something was broken. It wasn't. This host was signing with GPG before switching this
repo's config to SSH at some point in its history, so older commits carry the old key and newer
ones carry the new one. Nothing was inconsistent; I just did not have a way to date the config
change against the commit log without asking.

Suggested fix

In .claude-plugin/fleet-skills/skills/git-commit-conventions/SKILL.md, "Signing, verified not
configured" currently reads:

Verify before the first agent-authored commit, don't assume a prior session left it set:
git config --get commit.gpgsign && ssh-add -L, or the GPG equivalent.

Replace the ssh-add -L check (or supplement it) with a real test that matches what actually
gets exercised, e.g. a scratch-repo git commit -S + git log --show-signature check, or state
explicitly that an unreachable ssh-agent is inconclusive on a host signing straight from a key
file, so an agent doesn't read that one signal as a stop condition. A note that GPG-signed
history predating an SSH switch is expected and not evidence of a broken setup would also have
saved a detour here.

Environment this was observed on

Windows 11, PowerShell 7, Git for Windows, SSH signing via ~/.ssh/id_ed25519, no ssh-agent
service running, commit.gpgsign = true, gpg.format = ssh.

[ptr727]

Follow-up on the "GPG history predating an SSH switch is expected" part of the writeup — that specific explanation doesn't hold, and it's worth correcting before it goes into the SKILL.md note.

What I checked: on this Windows host, commit.gpgsign=true / gpg.format=ssh is confirmed live (git commit -S + git log --show-signature → Good "git" signature), consistent with the rest of this issue.

But the last 15+ commits on develop, including today's 6418d25 at 09:31 and 75f1fbd at 08:21, are all signed with GPG/OpenPGP RSA key B5690EEEBB952194, not SSH:

6418d25 08-14 09:31  RSA key B5690EEEBB952194
75f1fbd 08-14 08:21  RSA key B5690EEEBB952194
c8a50a4 08-14 07:37  RSA key B5690EEEBB952194
...back through 08-13 11:47, all the same key

That's not stale history from before a switch — it's every commit through this morning. Since this host (Windows) is confirmed SSH-only right now, those commits were made from one of the other fleet hosts (Debian or WSL), which is still gpg.format=openpgp with that RSA key, actively, today.

GitHub does mark these verified: true (reason: valid, PGP signature) via the API, so nothing here rejects or "breaks" in the way the ssh-add check implied — no red herring on that front. But per the fleet's actual signing rule (commits must carry a key registered with GitHub as an allowed SSH signing key), a GPG-signed commit doesn't satisfy it even when GitHub shows it verified.

Suggested addition to the SKILL.md note: don't frame GPG-vs-SSH signatures in history as "expected, predates a switch" without checking commit dates against which host made them. In a multi-host fleet (this one spans Windows/Debian/WSL), a GPG signature can mean "this other host is still misconfigured," not "old history." Worth having the non-Windows hosts confirmed/switched to gpg.format=ssh with a GitHub-registered signing key the same way this one is.

[ptr727]

Fixed by #708 (7925c88 on develop, promoted to main in #718 at 0e84805). This issue was never linked to that PR, so it stayed open after the merge.

Verified in the tree at aa7bf78. .agents/skills/git-commit-conventions/SKILL.md "Signing, verified not configured" now states the rule this issue asked for, in both directions:

• The agent-liveness probe is banned by name rather than merely deprecated: "Probing agent liveness (ssh-add -L, a gpg-agent check) is not a valid test and must not be used.", with the reason spelled out, that gpg.format=ssh can sign straight from a key file with no agent running, called out as the common case on Git for Windows.
• The replacement is the scratch-commit probe suggested here, read back with git's own verdict rather than a text grep, and it is explicitly tech-agnostic across all four delivery paths (SSH agent-backed, SSH key-file, GPG agent-backed, GPG keyring).

The probe commit is deliberately plain rather than -S, which is a refinement on what was suggested here: forcing the flag would still pass on a host where commit.gpgsign is unset, which is the exact default-config gap the probe exists to catch.

One thing this issue asked for did not land: the note that GPG-signed history predating an SSH switch is expected rather than evidence of a broken setup. If that detour is worth guarding against, it is a small addition to the same section rather than a reason to hold this open.