Menú
GitHub Issues + Project tracking. Use when creating, updating, or querying issues and managing the project board.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
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.
Basado en la clasificación ocupacional SOC
| 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.