Skip to content
AtomPRD

Contributing

The OSS half of AtomPRD welcomes contributions. The Cloud half is proprietary and not open to external PRs.

Bug reports

Section titled “Bug reports”

Open an issue at github.com/atomprd/atomprd (post-launch). Include:

  • AtomPRD spec version (@atomprd/spec package version).
  • Reproduction steps — ideally a minimal manifest.
  • Expected vs actual behavior.
  • Stack trace if a thrown error.

Spec RFCs

Section titled “Spec RFCs”

Spec-level changes go through the RFC process:

  1. Open a discussion issue.
  2. Once direction is rough-agreed, file a PR adding specs/rfcs/RFC-NNN-<slug>.md.
  3. Sections required: Motivation, Detailed design, Drawbacks, Alternatives, Unresolved questions.
  4. Merge requires two approvers + a 5-day comment window.

Examples of RFC-worthy changes:

  • New atom kind.
  • New relation type.
  • Change to an existing kind’s required fields.
  • Change to the Layer 2 schema for an existing kind.
  • New built-in for the rule expression grammar.

Examples of changes NOT requiring an RFC:

  • Bug fixes.
  • Documentation improvements.
  • New optional fields on existing kinds (additive in the v0.3.x line).
  • New codegen targets (separate package).

Codegen targets

Section titled “Codegen targets”

New codegen targets are welcome as separate packages outside @atomprd/*. The reference target @atomprd/codegen-senlang is the model — see Codegen → Custom targets.

If you want your target reviewed for inclusion under @atomprd/codegen-<target>, open an issue first to discuss scope.

Documentation

Section titled “Documentation”

This site (atomprd-cloud/app-docs) is proprietary. The MIT-licensed source content lives at:

  • atomprd/specs/atomprd-v0.3.md — the spec.
  • atomprd/specs/rfcs/*.md — RFCs.
  • atomprd/docs/*.md — user / developer / tutorial guides.

Documentation PRs go to the OSS repo. The cloud docs site syncs via the docs-sync map (private).

Code style

Section titled “Code style”
  • Prettier + ESLint configs live in @atomprd/config.
  • TypeScript strict mode.
  • Bun ≥ 1.2 for test runs (bun test).
  • Conventional commits encouraged but not enforced.

Inbound = outbound

Section titled “Inbound = outbound”

Contributions to the OSS half are accepted under MIT (the standard GitHub inbound = outbound rule). By submitting a PR you affirm you have the right to do so.

See also

Section titled “See also”
  • License — MIT for OSS, proprietary for Cloud.
  • BOUNDARIES — OSS ↔ Cloud charter.
  • RFCs — spec-change process.