draton

Choose and use Draton repository-local Codex tools for safe command execution and tool discovery. Use when Codex needs to run potentially expensive commands, constrain time or memory, avoid spawning too many concurrent processes, recover from interrupted guarded runs, or decide whether local tools should replace raw shell execution.

Apply Draton branch policy and promotion flow. Use when Codex works on branch creation, branch cleanup, merge strategy, contributor branch guidance, release-candidate promotion, or any task that decides whether work belongs on dev, unstable, or main.

Keep Draton commit history disciplined and policy-compliant. Use when Codex has completed a meaningful change, needs to split work into logical commits, must choose commit boundaries, or must write clear commit messages that reflect repository rules.

Keep Draton docs, examples, contributor guides, migration notes, and release-facing text aligned with implementation and policy. Use when Codex changes user-visible syntax, CLI behavior, tooling flow, branch policy, release workflow, self-host status, contributor guidance, or any behavior that can drift away from documentation.

Protect Draton canonical language rules, syntax philosophy, and parser-doc-example alignment. Use when Codex changes syntax, parser behavior, typechecker behavior, language examples, migration notes, contributor rules, or any implementation that might introduce competing canonical syntax or drift away from documented Draton language policy.

Protect Draton inferred-ownership memory-model rules. Use when Codex changes runtime lowering, ownership logic, allocation and free behavior, GC-related docs, LLVM IR generation that might reintroduce GC artifacts, or any task that touches memory-management semantics.

Prepare and validate Draton release work, preview packaging, smoke tests, and release-facing docs. Use when Codex touches release workflows, packaging scripts, install docs, release notes, preview artifacts, or tasks that need confidence before a tag or public preview update.

Review Draton changes with a bug-risk-regression mindset. Use when the user asks for a review, when Codex must audit a diff, pull request, parser change, runtime change, docs-policy change, or any update where findings should be prioritized over summaries.

Keep Draton self-host work scoped, documented, and subordinate to the Rust frontend. Use when Codex touches compiler/, self-host parity plans, migration status docs, or any work that could blur the boundary between current Rust authority and future self-host implementation.

Handle Draton vendored LLVM setup, environment, packaging, and validation workflows. Use when Codex touches scripts/vendor_llvm.py, LLVM bundle environment variables, build failures tied to vendored LLVM, packaging of llvm/, or release smoke tests that depend on the bundled toolchain.

Choose and run focused verification for Draton changes. Use when Codex modifies Rust crates, compiler components, parser or typechecker behavior, CLI tooling, release scripts, vendored LLVM workflows, docs that need sanity checks, or any change that should be proven runnable before completion.

Respect Draton repository boundaries and sources of truth. Use when Codex must decide whether work belongs in crates/, compiler/, src/, docs/, scripts/, or contributor docs, especially when tasks risk mixing the Rust frontend, docs site, and self-host reintroduction areas.