القائمة
Use when the user asks to commit, commit and push, or make a git commit. Covers branching, commit workflow, conventional commits, TODO updates, and push/PR rules.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use `mdvs search` for any content lookup in a markdown directory — semantic / hybrid / SQL-filtered, beats Grep / Glob for finding by meaning. `mdvs init` infers a schema from existing markdown, `mdvs check` validates frontmatter, `mdvs update` evolves the schema as the KB grows. Activate whenever the project contains markdown with frontmatter, whether or not `mdvs.toml` exists yet.
Release process for mdvs. Use when the user asks to make a release (patch, minor, major, or release candidate).
Use when writing, modifying, or removing Rust code in the mdvs codebase. Covers implementation workflow, testing, verification, and downstream updates (specs, example_kb, mdbook).
mdBook documentation conventions. Apply when writing, editing, or reviewing pages in book/src/. Covers content rules, example verification, tone, and structure.
GitHub Issues + Project tracking. Use when creating, updating, or querying issues and managing the project board.
Rust coding conventions. Apply when writing, reviewing, or modifying Rust code. Covers error handling, types, ownership, testing, and anti-patterns.
| name | commit |
| description | Use when the user asks to commit, commit and push, or make a git commit. Covers branching, commit workflow, conventional commits, TODO updates, and push/PR rules. |
Never push directly to main. All work goes through feature branches + PRs.
feat/description, fix/description, docs/descriptionmain: git checkout -b feat/my-feature mainNever commit unless the user explicitly asks. No autonomous commits. Wait for "commit", "commit and push", or similar.
done before committing (use the todo skill). This lets the user review the TODO update as part of the same diff.Run git add, git commit, and git push as separate commands — never chained together.
git add -A or git add ..env, credentials)Use Conventional Commits format. A commit-msg hook (cocogitto) enforces this.
Format: <type>[optional scope]: <description>
Types: feat, fix, refactor, docs, test, chore, ci, perf, style
git commit -m "$(cat <<'EOF'
feat: add enum constraints on string fields
EOF
)"
Only push when the user explicitly asks. "Commit" does not imply "push". Wait for "push", "commit and push", or similar.
After pushing a feature branch, create a PR to main when the user asks. Use gh pr create with a clear title and summary. CI must pass before merging. Use regular merge (not squash).
maingit rebase -i)