القائمة
Spec document conventions for writing and reviewing specification documents. Apply when creating or modifying specifications, workflows, API docs, or terminology definitions.
التثبيت باستخدام 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 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.
GitHub Issues + Project tracking. Use when creating, updating, or querying issues and managing the project board.
| name | spec |
| description | Spec document conventions for writing and reviewing specification documents. Apply when creating or modifying specifications, workflows, API docs, or terminology definitions. |
docs/spec/
├── terminology.md # Canonical definitions (single source of truth)
├── storage.md # .mdvs/, parquet schemas, mdvs.toml, mdvs.lock
├── shared.md # Shared output structs (DiscoveredField, etc.)
├── commands/ # One file per CLI command
│ ├── init.md
│ ├── build.md
│ ├── search.md
│ ├── check.md
│ ├── update.md
│ ├── clean.md
│ └── info.md
├── workflows/ # Cross-cutting logic shared across commands
│ ├── inference.md
│ ├── model-loading.md
│ └── model-mismatch.md
└── archive/ # Old specs, do not reference
terminology.md) — Canonical definitions, single source of truth for termsstorage.md) — Parquet schemas, config file formats, directory layoutshared.md) — Output structs used by multiple commandscommands/*.md) — One per CLI command: inputs, behavior, output struct, errorsworkflows/*.md) — Cross-cutting logic used by multiple commandsEvery spec starts with:
# <Title>
**Status: DRAFT** (or TODO, REVIEW, FINAL)
**See also:** [link1](path), [link2](path)
Command specs should include these sections:
# `mdvs <command>`
**Status: DRAFT**
## Synopsis
<usage line and flags>
## Behavior
<what the command does, step by step>
## Output
<output struct definition — every command collects results in a struct before display>
## Errors
<error conditions and messages>
## Examples
<CLI usage examples>
# Workflow: <Name>
**Status: DRAFT**
## Overview
<what this workflow does and which commands use it>
## Algorithm
<step-by-step logic>
## Edge Cases
<boundary conditions>
archive/