Menu
GitHub Issues + Project tracking. Use when creating, updating, or querying issues and managing the project board.
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.
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 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.
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.
Rust coding conventions. Apply when writing, reviewing, or modifying Rust code. Covers error handling, types, ownership, testing, and anti-patterns.
Based on SOC occupation classification
| name | issue |
| description | GitHub Issues + Project tracking. Use when creating, updating, or querying issues and managing the project board. |
Issues live in edochi/mdvs. The project board is at https://github.com/users/edochi/projects/2 (number 2, ID PVT_kwHOA2NvhM4BQ-9Z).
Every issue follows this template:
# Summary
One line or short paragraph.
# Changes
- Bullet list of concrete changes
# Description
Free-form, as detailed as needed.
## Sub-header
...
# Files
- `src/cmd/build.rs` — description
The Description section is optional but can be arbitrarily detailed with sub-headers.
On the issue (repo-level):
feat, fix, refactor, docs, test, chore, ci, perf, styleOn the project (board-level):
gh issue create --repo edochi/mdvs \
--title "<title>" \
--label "<type>" \
--body "$(cat <<'EOF'
# Summary
...
# Changes
- ...
# Files
- ...
EOF
)"
The issue is auto-added to the project via the project's auto-add workflow.
After creating an issue, set its priority on the project board:
gh project item-list 2 --owner edochi --format json --jq '.items[] | select(.content.number == <ISSUE_NUMBER>) | .id'
gh project item-edit --project-id "PVT_kwHOA2NvhM4BQ-9Z" \
--id "<ITEM_ID>" \
--field-id "PVTSSF_lAHOA2NvhM4BQ-9Zzg-8kwo" \
--single-select-option-id "<OPTION_ID>"
Priority option IDs:
20a900f04fedbaba20cdb34fManaged through GitHub issue relationships, not in the issue body. Use sub-issues or "tracked by" links in the project.
Branches reference the issue number:
<issue-number>-<short-description>
Examples: 1-cargo-dist, 5-enum-constraints, 12-mdbook-site
gh issue list --repo edochi/mdvs # all open
gh issue list --repo edochi/mdvs --label feat # by type
gh issue list --repo edochi/mdvs --state closed # closed
gh issue view <number> --repo edochi/mdvs # single issue
gh issue close <number> --repo edochi/mdvs
The project's "Item closed" workflow auto-sets Status to Done.