add-engine-variant

A safety checklist for deciding whether a new named option belongs in a game engine’s existing enum, which is a list of allowed values.

In plain words
What is it for?
Use it before proposing, planning, approving, or implementing a new engine enum variant.
Why use it?
It prevents duplicate options and unnecessary changes by checking whether the concept already exists under another name and whether a new value is truly needed.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/phase-rs/phase/add-engine-variant
Any agent
npx skills add phase-rs/phase --skill add-engine-variant
Clone the repo
git clone --depth 1 https://github.com/phase-rs/phase

Made for: Claude Code, Codex.

Per session 96 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 3,657 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00096 $0.03657
Opus 5 $0.00048 $0.01828
Sonnet 5 $0.00019 $0.00731
Haiku 4.5 $0.00010 $0.00366

Measured 2d ago against content hash d900008c9b51, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

add-engine-variant scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/add-engine-variant/SKILL.md · 166 lines

How it starts

The opening of the file, as written. The whole thing — 166 lines — stays where its author put it; the contents beside it link to each section on GitHub.

add-engine-variant — Engine Enum Extension Gate

When to invoke

This skill is the gate for any work that would add a variant to an existing engine enum. Run it BEFORE:

  • Proposing an engine extension in a plan or task description
  • Drafting an engine PR that adds a variant
  • Approving an audit verdict of "engine extension required"
  • Wiring a converter arm to a not-yet-existing variant

If you find yourself about to type pub enum Foo { ... NewVariant ... } in crates/engine/src/, pause and run this skill.

The three filter stages — all must pass

Stage 1: Existence verification (5-grep protocol)

The variant might already exist under a different engine-native name. External data formats and the engine vocabulary are not 1:1; the engine often has the concept under a different name.

The canonical engine surface is data/engine-inventory.json (gitignored). Run cargo engine-inventory to (re)generate it locally before grepping for existing variants.

Run all five searches before considering extension:

# 1. Direct name search
rg -n "<concept_keyword>" crates/engine/src/types/

# 2. Inverse concept (engine often expresses "not X" as "X { negated: bool }" or "X { negated: true }")
rg -n "<inverse_concept>" crates/engine/src/types/

# 3. Inversion-parameter variants
rg -n "negated: bool|invert|polar" crates/engine/src/types/ability.rs

# 4. Native parser reverse dictionary — how does oracle_nom express this concept?
rg -n "<concept_keyword>|<engine_concept>" crates/engine/src/parser/oracle_*.rs

# 5. Synthesis layer
rg -n "<concept_keyword>" crates/engine/src/database/synthesis.rs

Stage 1 verdicts:

  • EXISTS_SAME_NAME: variant exists. Stop. Wire to it.
  • EXISTS_DIFFERENT_NAME: concept exists under an engine-native name (e.g., an external CreateTriggerUntil maps to engine Effect::CreateDelayedTrigger). Stop. Map the source data to the existing slot.
  • EXISTS_AS_PARAMETER: concept exists as a parameter value of a more general variant (e.g., "untapped" exists as Tap { negated: true }). Stop. Use the parameter form.
  • DOES_NOT_EXIST: proceed to Stage 2.

Read the full file on GitHub · 166 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 166 lines · 96 tokens per session scan A d900008c9b51

Subscribe to this mod's changes

add-engine-variant is a skill published in the GitHub repository phase-rs/phase (259 stars, last pushed 2d ago), licensed Apache-2.0. It adds 96 tokens to every session and 3,657 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

add-card

Implements new Magic: The Gathering cards for the Argentum Engine. Use when adding a new card, the user provides one or more card names to implement, or asks to implement a specific MTG card. Several cards that reuse existing primitives can be implemented together into one PR.

wingedsheep/argentum-engine · 0 tokens

add-feature

Adds a new feature or mechanic to the Argentum Engine (SDK primitive, effect, trigger, condition, static/replacement ability, server/client capability) following the project's architecture and SDK-elegance principles. Use when implementing engine/SDK/server/client functionality that isn't a single card — e.g. "add an…

wingedsheep/argentum-engine · 87 tokens

verify-set

Prove a Magic set is actually finished — card-for-card complete, field-for-field faithful to Scryfall, scripts that match their oracle text, tokens that resolve the set's own art, behaviourally sound — then archive its backlog. Builds the Scryfall dump and CardFieldVerificationTest, fans the per-card DSL and token…

wingedsheep/argentum-engine · 152 tokens

assay-ready-sweep

Implement every "Assay-ready" card for a Magic set — the cards Argentum Assay reads whole that the set hasn't authored yet — placing each canonical in its earliest real printing and giving the sweep's own set a Printing row when the card is a reprint. Computes the four-way split first, authors to assay compile's JSON…

wingedsheep/argentum-engine · 156 tokens

create-backlog-for-set

Create the backlog/sets/ / entry for a Magic set — download the whole set from Scryfall (cached alongside Assay's cache), write cards.md as a per-colour checklist with the already-implemented cards ticked, scaffold the set's definitions/ / module if it doesn't exist, and write mechanics.md ordering every mechanic the…

wingedsheep/argentum-engine · 150 tokens

add-random-card

Pick a random unimplemented card from a set and implement it. Accepts either a backlog cards.md path or a set name/code.

wingedsheep/argentum-engine · 32 tokens