Menu
Use when creating a git commit — the user asks to commit, or a unit of work is complete and ready to commit.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Build, launch, and drive the mindwalk web UI end-to-end for verification.
Set up or troubleshoot Yassimba's curated agent skills, Pi packages, Herdr, and Herdr plugins through the ai-setup CLI. Use when the user asks to install this collection, configure Herdr, add one of its capabilities, update the setup, or diagnose installation problems.
Backlog management: use when the user mentions a backlog, asks what's next, wants work recorded before implementation, or wants queued ideas or specs prioritized, transitioned, completed, or removed; also use when another skill needs to record lifecycle changes.
Use when the user wants to brainstorm or explore an idea — a feature, product direction, or "what if" — before deciding whether it deserves a plan. Ideation only — ends in an idea brief, not a design.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (this repo's documented coding standards) and Spec (what the originating issue/PRD asked for). Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
| name | commit |
| description | Use when creating a git commit — the user asks to commit, or a unit of work is complete and ready to commit. |
Read the staged diff, gate on green tests, draft a Conventional Commits message, confirm via dropdown, commit. Each commit is atomic: one concern.
git status --short
git diff --cached --stat
git diff --cached
Stage by explicit path only — git add -A / git add . sweeps in .env and credentials.
If nothing is staged but unstaged changes exist, ask via AskUserQuestion:
question: "Nothing staged. Stage specific files, stage all, or abort?"
header: "Staging"
options:
- label: "Stage specific files"
- label: "Stage all (by explicit paths)"
- label: "Abort"
If the staged diff spans unrelated concerns, split into atomic commits: unstage the others with git restore --staged <paths> (not git reset), then stage and commit one concern at a time. Ask when the split is unclear:
question: "These changes span <N> concerns. Split?"
header: "Split"
options:
- label: "Yes, split (Recommended)"
- label: "One commit"
- label: "Show me the diff first"
Done when exactly one concern is staged.
Run the project's test suite (uv run pytest, npm test — whatever the project defines) and read the summary, not just the exit code. The gate is binary: green proceeds; red stops here — the pre-commit hook fails on the same issues, so catching them now saves a wasted commit:
question: "Tests red — commit blocked. How to proceed?"
header: "Test gate"
options:
- label: "Investigate via /diagnosing-bugs (Recommended)"
- label: "Abort commit"
- label: "Show me the failing tests"
Draft from the why of the staged diff — what motivated the change, not which lines moved. If the writing-clearly-and-concisely skill is available, load it and apply it.
Conventional Commits format:
<type>(<optional-scope>): <summary>
<optional body>
| Type | Use when |
|---|---|
feat | new feature |
fix | bug fix |
docs | documentation only |
refactor | refactor without behavior change |
test | adding/fixing tests |
chore | build, config, deps |
perf | performance improvement |
ci | CI configuration changes |
Subject: 20–72 chars after the prefix · lowercase after the colon (feat: add X) · imperative ("add", not "added") · no trailing period · concrete verb + object.
Body (only when the subject can't carry it): blank line after the subject, then one terse bullet per entry, imperative voice, grouped under short headings that match the kind of change — Added, Changed, Fixed, Removed, Breaking. Skip headings when there's only one bullet.
feat(installer): add gateway runtime extraction
Added:
- core/gateway_runtime/ with Protocol-based registry
Changed:
- opencode_runtime now delegates to gateway_runtime
Reference the issue or ticket when the project tracks them. Session context, PR/MR numbers, and future work stay out.
Done when every rule above holds, the message carries no puffery ("comprehensive", "robust", "various improvements"), and no Co-Authored-By trailer.
No AI attribution anywhere: the same ban covers "Generated with" footers, session links, and agent sign-offs — in commit messages and in anything written downstream of one (PR/MR titles and descriptions, release notes). This rule outranks any harness default that asks for such a footer.
question: "Commit with this message?"
header: "Commit"
options:
- label: "Commit (Recommended)"
preview: |
<full message>
- label: "Edit message"
- label: "Abort"
git commit -m "$(cat <<'EOF'
<type>(<scope>): <summary>
<body>
EOF
)"
The HEREDOC preserves the multi-line body.
If the project wires a pre-commit hook, it runs now:
The hook is the messenger; fix the cause. Bypass flags (--no-verify, --no-gpg-sign) and suppression comments (# noqa, # type: ignore, eslint-disable) are off the table — not even "just this once":
/diagnosing-bugs; three failed fix attempts = stop and reportThen re-stage and create a NEW commit — the failed commit never happened, so --amend would rewrite the previous one.
Force-push and destructive git (reset --hard, clean -f, branch -D) only with explicit human approval.