A requirements management CLI for repositories that store requirements as YAML files.

Install the latest published release directly from GitHub assets:

npm install -g \
  "https://github.com/jemoster/gitreqd/releases/download/v0.2.0/gitreqd-core-0.1.0.tgz" \
  "https://github.com/jemoster/gitreqd/releases/download/v0.2.0/gitreqd-0.1.0.tgz"

From your repository root:

gitreqd bootstrap

Run commands from the project root (where gitreqd.yaml or gitreqd.yml exists), or pass --project-dir /path/to/project.

Use Cursor Agent Skills in .cursor/skills/ to move from requirement text to implementation:

• /require helps draft or update requirement files in your requirements/ directory.
• /implement helps generate code changes that satisfy selected requirements.

A common flow is: define/refine requirements with /require, then switch to /implement to build the related code changes.

• gitreqd bootstrap - initialize gitreqd.yaml and requirements/.
• gitreqd validate - check requirement YAML against the active schema.
• gitreqd format - rewrite requirement YAML into canonical format.
• gitreqd migrate - convert legacy description fields to require and refinement.
• gitreqd html - generate a static HTML report.
• gitreqd schema - print or export the effective requirement schema.
• gitreqd resolve-conflicts - resolve requirement-file merge conflicts with optional LLM settings.

Use gitreqd --help or gitreqd <command> --help for full options.

Each requirement is one file ending in .req.yml or .req.yaml.

Required fields:

• id - stable identifier, usually matching the filename (without suffix).
• title - short requirement name.

Required normative field:

• require - single Shall, Should, or May statement for this requirement ID.

Common optional fields:

• refinement - supporting detail (Markdown supported in reports).
• attributes - metadata such as status, owner, or rationale.
• links - traceability links (for example satisfies: OTHER-ID).
• satisfied_by - artifacts (file paths or URLs) that implement or satisfy the requirement, each with an optional description.
• verified_by - artifacts (file paths or URLs) that verify the requirement was met, each with an optional description.
• parameters - reusable named values for interpolation in string fields.

Example artifact entry:

satisfied_by:
  - artifact: src/feature.ts
    description: Primary implementation.
verified_by:
  - artifact: test/feature.test.ts

Parameter placeholders in strings:

• {{ :name }} for local requirement parameters.
• {{ other_id:name }} for cross-requirement parameters.
• {{ "fixed text" }} for a quoted literal.

Bootstrap creates a requirements/ folder and lists it under requirement_dirs. Each entry is a path relative to the project root; the tool collects every *.req.yml and *.req.yaml file under those directories (recursively), except under node_modules. Use a single entry of . to include the whole project tree from the root down.

Choose how requirement YAML is interpreted and rendered. If omitted, standard is used.

Used by LLM-enabled commands such as resolve-conflicts.

• provider: ollama requires model; optional base_url (default http://localhost:11434).
• provider: claude requires api_key_env; optional model and base_url.

Developer-focused material (workspace layout, building from source, packaging, extension distribution, and pre-commit setup) is now in dev.md.