with one click
speq-git-discipline
Enforce Git discipline for speq-skills.
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.
Menu
Enforce Git discipline for speq-skills.
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
Audit a speq project's health — spec-library structure, feature/decision-log/plan validation, mission-to-spec sync, unrecorded plans, and gitignore hygiene — then guide fixes. Use when the user asks to audit, health-check, doctor, lint, or sanity-check the specs or repo, or after cloning or inheriting a speq project.
Code review tag taxonomy and findings output format — guardrail violations, dead code, obsolete tests, bad comments, optimizations, YAGNI/over-engineering. Triggered by code-reviewer.
Headless follow-up to speq-plan-pr. Continues on a plan's feat/plan-name branch, runs speq-implement, bumps the version, runs the real test suites, records only if green, then pushes and opens/updates a PR. Arg: plan name, PR number, or branch name.
Orchestrate implementation of reviewed plans according to the spec deltas. Arg: <plan-name>.
Create specs/mission.md via interactive interview. Detects brownfield vs greenfield.
Headless, non-interactive version of speq-plan. Plans a feature without a live interview, commits the result to a feat/plan-name branch, and opens a PR. If a decision genuinely needs a human, it persists the partial plan and open questions and asks in a PR comment instead of blocking. Arg — plan name, feature intent text, PR number, or branch name.
| name | speq-git-discipline |
| description | Enforce Git discipline for speq-skills. |
Git read-only guardrails. User controls all git writes.
git status git diff git log git show git branch
add commit push pull fetch
merge rebase cherry-pick
checkout switch restore
reset revert stash tag
No exceptions.
Verify expected changes:
git status # Check files changed
git diff # Review actual changes
Never commit secrets (API keys, passwords, credentials, tokens).
Follow the Conventional Commits specification:
<type>[scope]: <description>
[body]
[footer]
| Type | Use |
|---|---|
feat | New feature (MINOR) |
fix | Bug fix (PATCH) |
perf | Performance |
refactor | Restructure, same behavior |
test | Tests |
docs | Documentation |
spec | Spec changes |
chore | Maintenance |
Breaking changes: Add ! after type or BREAKING CHANGE: footer → MAJOR version