القائمة
Auto-commit changes after a Spec Kit command completes
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | speckit-git-commit |
| description | Auto-commit changes after a Spec Kit command completes |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"github-spec-kit","source":"git:commands/speckit.git.commit.md"} |
| user-invocable | true |
| disable-model-invocation | false |
Automatically stage and commit all changes after a Spec Kit command completes.
This command is invoked as a hook after (or before) core commands. It:
after_specify hook, the event is after_specify; if before_plan, the event is before_plan).specify/extensions/git/git-config.yml for the auto_commit sectionauto_commit.default if no event-specific key existsmessage if configured, otherwise a default messagegit add . + git commitDetermine the event name from the hook that triggered this command, then run the script:
.specify/extensions/git/scripts/bash/auto-commit.sh <event_name>.specify/extensions/git/scripts/powershell/auto-commit.ps1 <event_name>Replace <event_name> with the actual hook event (e.g., after_specify, before_plan, after_implement).
In .specify/extensions/git/git-config.yml:
auto_commit:
default: false # Global toggle — set true to enable for all commands
after_specify:
enabled: true # Override per-command
message: "[Spec Kit] Add specification"
after_plan:
enabled: false
message: "[Spec Kit] Add implementation plan"
Structured SRE debugging methodology for aie-matrix production incidents. Use this skill whenever the user is investigating anything that is slow, broken, or behaving unexpectedly in production or staging — including slow deploys, failing health probes, high latency, unexpected restarts, memory pressure, or anything described as "something is wrong" or "why is X taking so long". Also use when writing a post-mortem or runbook entry. The skill enforces a disciplined observe-hypothesize-test loop rather than applying fixes based on intuition.
Gate check before opening a PR: clean build, all tests (unit + integration), spec coverage, doc impact, and a go/no-go verdict. Run after /speckit.implement and before opening a pull request.
Effect-ts coding standard for all server-side packages in aie-matrix (server/agent-host/ and server/*). Use when writing or reviewing services, route handlers, error types, logging, configuration, or background fibers in any of these packages.
Create or update the feature specification from a natural language feature description.
Validate gram notation snippets or files using the gram-lint CLI. Use whenever you need to check whether a gram expression or .map.gram file is syntactically valid — especially when designing format changes, reviewing example files, or verifying that proposed snippets are parseable by the WASM grammar.
Validates Gram notation files and inline snippets using the gram-lint CLI (parse errors, optional s-expression tree). Use when editing or generating .gram files, debugging Gram.parse failures, validating converter output, or when the user mentions gram-lint, Gram syntax, or linting gram documents.