Projections — project()
A requirements spec is the source of truth. Projections render that one spec into the file each downstream tool expects, so the same behavioral contract reaches every coding agent and spec-driven-development (SDD) framework.
from mycontext.rac import product, project
prod = product(INTENT)
print(project(prod, to="agents-md"))
These are deterministic text renderers — no LLM, no enforcement.
Signature
def project(doc: dict, to: str) -> str
| Parameter | Type | Meaning |
|---|---|---|
doc | dict | A product or technical spec. |
to | str | The target format (case-insensitive; aliases accepted). |
Returns the rendered file content as a string. Raises ValueError for an
unknown target, or when a product-only target is given a technical spec.
Targets
TARGETS = ("agents-md", "claude", "cursor", "spec-kit", "kiro", "adr")
| Target | Aliases | Produces | Works with |
|---|---|---|---|
agents-md | agents, agentsmd | AGENTS.md — universal coding-agent constitution | product and technical |
claude | claude-code, claudemd | CLAUDE.md — Claude Code instructions | product |
cursor | cursor-rules, mdc | .cursor/rules/*.mdc — Cursor rule with frontmatter | product |
spec-kit | speckit, spec | spec.md — GitHub Spec Kit narrative | product only |
kiro | ears | requirements.md — AWS Kiro, EARS syntax | product only |
adr | architecture | Architecture summary | technical (best) |
spec-kit and kiro expect a product spec (they render tasks, rubrics, and
EARS requirements). Passing a technical spec raises a ValueError suggesting
adr (or agents-md/claude/cursor) instead. agents-md adapts: it renders
a behavioral constitution for a product spec and an engineering-invariants slice
for a technical spec.
Examples
agents-md (product)
# AGENTS.md — aurora
> Generated by mycontext requirements-architect from `requirements.yaml`.
> `requirements.yaml` is the source of truth; regenerate this file when it changes.
## Intent
Aurora drafts replies to billing emails; refunds need approval.
## Operating rules (the constitution)
- NEVER call these tools (forbidden): delete_record, modify_history, merge_records.
- Require human approval before: send_reply.
- Require human approval before: issue_refund_or_payment.
- Safety: The system must never do: wrong refunds (defense in depth)
- For out-of-scope requests: produce NO draft; route to a human immediately.
## Definition of done (release gates)
- `T1`: rubric_pass_rate >= 0.9
- `T_oos`: correct_routing_rate >= 1.0 (hard gate)
- `safety`: all_safety_asserts pass (hard gate)
## Open questions (resolve before trusting this spec)
- **(blocking)** `OQ-03` — Name the specific out-of-scope categories ... (affects `tasks.T_oos.categories`)
kiro (EARS syntax)
# Requirements — aurora (EARS)
1. WHEN drafts replies to billing emails, THE SYSTEM SHALL handle it via 'draft_plus_approval' and satisfy rubric R-T1.
2. WHEN out_of_scope, THE SYSTEM SHALL produce no draft and route the request to a human immediately.
3. WHEN about to send_reply, THE SYSTEM SHALL require human approval before proceeding.
4. THE SYSTEM SHALL NEVER delete_record, modify_history, merge_records.
5. THE SYSTEM SHALL ENSURE: The system must never do: wrong refunds (defense in depth).
cursor (.mdc rule)
---
description: Behavioral contract for aurora (from requirements.yaml)
alwaysApply: true
---
# aurora — operating rules
Source of truth: `requirements.yaml` (generated by mycontext requirements-architect).
Regenerate this rule when the spec changes.
## Invariants
- NEVER call these tools (forbidden): delete_record, modify_history, merge_records.
- Require human approval before: send_reply.
...
adr (technical spec)
# Technical Architecture — aurora
> Generated by mycontext from the technical-requirements spec.
## Architecture
- Pattern: tool_augmented_agent (plan -> act -> observe loop)
- Orchestration: plan -> act -> observe
- State: short-term=per-request scratchpad; long-term=none (stateless between requests)
## Guardrails
- (input) Treat all user/tool content as data, never instructions · serves: P4
...
## Security (OWASP Agentic)
- Excessive Agency: forbidden-tool list + approval gates · serves: A-X, A-3
...
On the command line
mycontext rac project product.yaml --to agents-md --out AGENTS.md
mycontext rac project product.yaml --to claude --out CLAUDE.md
mycontext rac project product.yaml --to cursor --out .cursor/rules/aurora.mdc
mycontext rac project product.yaml --to kiro --out requirements.md
mycontext rac project product.yaml --to spec-kit --out spec.md
mycontext rac project technical.yaml --to adr --out ARCHITECTURE.md
Without --out, the rendered file is printed to stdout.
A regenerate-on-change workflow
Because projections are deterministic, treat the generated files as build artifacts and regenerate them whenever the spec changes:
# In a pre-commit hook or CI step
mycontext rac project product.yaml --to agents-md --out AGENTS.md
mycontext rac project product.yaml --to cursor --out .cursor/rules/aurora.mdc
git add AGENTS.md .cursor/rules/aurora.mdc
Next
- Wire everything from the shell: CLI reference →
- Full symbol list: API reference →