Skip to content

Rules Bootstrap — Operational Instructions

Used by the rules-bootstrap skill (and reproducible by hand).

Inputs

  • A rules-manifest.yaml (or .json) at the target project root, validating against manifest.schema.json.
  • Read access to this shared/rules/ directory.

Outputs

  • A populated .cursor/rules/ directory in the target project containing the composed .mdc files.
  • A generated .cursor/rules/_BOOTSTRAP_RECEIPT.md capturing what was composed, from which version, when, and by whom.

Composition order

For each .mdc file in: 1. global-baseline/ (after applying include/exclude), 2. each requested stack module under stack-modules/<stack>/, 3. each override path under project-overrides/,

copy (or symlink, per rendered.mode) into the target's .cursor/rules/ keeping the numeric prefix so Cursor evaluates them deterministically.

Conflict policy

If two slices define the same rule file name, the latter (higher number) wins. Document any override that knowingly suppresses a global baseline.

Receipt format

# Bootstrap Receipt

- generated_at: <ISO 8601>
- generated_by: rules-bootstrap@<version>
- global.version: <string>
- stacks: [backend, frontend, data, infra]
- overrides: [<paths>]
- file_list:
  - 010-style.mdc (from global-baseline)
  - ...

Re-bootstrapping

  • Idempotent: rerunning with the same manifest produces the same .cursor/rules/ (modulo timestamp in receipt).
  • A change in global.version triggers a diff report comparing old vs new baseline.

Validation

  • Manifest must validate against manifest.schema.json.
  • All referenced override paths must exist before any file is written.
  • Every .mdc written must contain valid YAML frontmatter.