aurora-agent: Skill for Claude Code

Add a module

A module is a crate implementing one blueprint section. The blueprint lives outside the repo; the path is recorded in docs/ARCHITECTURE.md.

1. Register before writing

Create the skeleton and register it first, so the workspace stays buildable and so a subagent never has to touch the shared root manifest:

mkdir -p crates/<name>/src && printf '//! Placeholder.\n' > crates/<name>/src/lib.rs

Add crates/<name> to members and bioprism-<name> = { path = "crates/<name>" } to [workspace.dependencies] in the root Cargo.toml, then confirm:

cargo build -p bioprism-<name> --offline

Only ever add dependencies already in [workspace.dependencies], as { workspace = true }. Builds are offline against pinned versions; a new external crate will not resolve. Several things are hand-rolled for exactly this reason — the CSV reader, the arg parser, JSON-RPC, log-gamma, RFC 3339, the PRNG. Prefer writing the ~100 lines to reaching for a dependency.

2. Respect the dependency direction

ids depends on nothing. scope depends on ids. section depends on neither world nor fiber, deliberately — a consumer must be able to verify a compiled context without linking the engine that produced it. Do not break that to save an import.

If two crates would need each other, the fix is a trait in the lower one implemented by the higher one, as WorldSource does for the compiler and the store.

3. Read the spec module, then cite it

Open the blueprint modules the crate claims and cite their ids in the doc comments ("Blueprint 43.13 requires…"). Much of the spec is status Planned rather than build-ready — prose design, not a frozen contract. Where it under-specifies, say so in a doc comment instead of inventing a detail and presenting it as spec. Whole sections are near-identical boilerplate; §08, §31 and §33 each carry roughly 15 lines of distinguishing content per module. That is worth reporting, not working around silently.