Bundle verify and commit skills

verify: confirm a change works by running the artifact the way a user would, and report what was not verified. commit: stage deliberately, one commit one reason, match the repository style, and the refusals around amending, hooks, and pushing.

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
This commit is contained in:
Muhammad Zakir Ramadhan
2026-09-03 16:42:46 +07:00
co-authored by Sisyphus
parent 8ee4c5bd2c
commit 6df41b56d2
2 changed files with 100 additions and 1 deletions
+99
View File
@@ -164,6 +164,105 @@ temp directory, a port, an unawaited promise, or ordering. Find which, do not ad
Run the test and watch it fail before the fix, pass after. A test you never saw fail is
not known to work.
`,
},
{
name: 'verify',
source: `---
name: verify
description: Confirm a change actually works by using it, not by reading it. Use before reporting a task complete, or when asked whether something works.
---
# Verification
A green test suite says the tests pass. It does not say the feature works.
## Run the artifact, not the source
Build it and use it the way a user would:
- **CLI** — build the binary and run it. Happy path, bad input, \`--help\`. Read the output.
- **HTTP service** — start it and \`curl\` the endpoint. Check the status and the body.
- **Library** — write a throwaway script that imports and calls the new code end to end.
- **Script or job** — run it against real input and inspect what it produced.
Delete the throwaway afterwards.
## What counts as evidence
Command output you actually saw. Paste the relevant lines, not a summary of them.
These are not evidence:
- "The tests pass" for a change tests do not cover.
- "The types check" for anything about runtime behaviour.
- "It should work now" for anything at all.
## Check the failure path too
Feed it the input you expect to be rejected and confirm it is rejected, with a message
that says why. A feature that works only on correct input is half-built.
## Report what you did not verify
Say plainly what you could not run and why: a missing credential, a service you cannot
start, a platform you are not on. An honest gap is useful; a claim that hides one is not.
## When verification fails
The defect is yours to fix in this turn. Do not report the task complete with a note that
it did not work.
`,
},
{
name: 'commit',
source: `---
name: commit
description: Stage and commit work. Use when asked to commit, or to split existing changes into commits.
---
# Committing
Never commit unless the user asked. If it is unclear whether they did, ask.
## Look before you stage
\`git_status\` and \`git_diff\` first. You are looking for two things:
1. Changes that are not yours. Another agent or the user may share this worktree, and
\`git add .\` takes their half-finished work with yours.
2. Files that should never be committed: \`.env\`, credentials, keys, large build output,
anything a \`.gitignore\` rule was supposed to catch and did not. Flag these to the user
rather than committing them.
Stage the specific paths you changed. \`git add .\` is how unrelated work ends up in a
commit that then has to be reverted whole.
## One commit, one reason
If the diff does two unrelated things, make two commits. A commit that both fixes a bug and
renames a module cannot be reverted, cherry-picked, or bisected usefully.
## The message
Match the repository's existing style — read \`git_log\` before writing one. Failing that:
- A subject line under 70 characters, imperative, saying what changed.
- A body explaining *why*, when the reason is not obvious from the diff. Wrap at 72.
- No "as requested", no restating the diff line by line, no emoji unless the repo uses them.
## Do not
- Do not \`--amend\` a commit that has been pushed. Write a new one.
- Do not \`--no-verify\`. If a hook rejects the commit, the hook found something.
- Do not \`git push\` unless asked, and never force-push without being asked explicitly.
- Do not commit and then immediately fix it up with a second commit. Get it right, or say
what is wrong.
## After committing
Report the short hash and the subject. If a hook rewrote files, say so and confirm the
final state is what was intended.
`,
},
];
+1 -1
View File
@@ -61,7 +61,7 @@ test('every bundled skill parses and has a usable description', () => {
test('the builtin skills load with no files on disk', async () => {
const skills = await loadSkills(work);
expect(skills.map((s) => s.name)).toEqual(['debug', 'refactor', 'review', 'test']);
expect(skills.map((s) => s.name)).toEqual(['commit', 'debug', 'refactor', 'review', 'test', 'verify']);
expect(skills.every((s) => s.origin === 'builtin')).toBe(true);
});