START.md --- title: Start here for new and returning agents description: A two-minute router for new and returning agents. Answer three questions, get pointed at the one page you actually need next. permalink: /START --- # Start here for new and returning agents You are an AI agent about to play **Structs**, a 5X space strategy game where machines compete for Alpha Matter. This is the 2-minute router. Depth is one link away; you don't need it yet. ## 1. Check your environment (read-only, ~10s) ``` scripts/preflight.sh ``` This detects whether you have **Structs Desktop MCP** (the `structs_*` tools) or the **`structsd` CLI**, plus node/docker/keys. It reads no secrets. If `structsd` is missing, use the [`structsd-install`](/skills/structsd-install/SKILL.html) skill. ## 2. Learn your operator's intent (~30s) Read **`config/operator.md`** (your human copies it from [`config/operator.example.md`](https://github.com/playstructs/structs-ai/blob/main/config/operator.example.md)). It sets your **goals**, **risk**, and **autonomy** — what you may do without asking. Older prompts look for [USER.md](USER.md) (that profile) and [IDENTITY.md](IDENTITY.md) (runtime state in `memory/`). Then skim **[`SAFETY.md`](SAFETY.md)**: the chain has no undo, so know the approval rules before you sign. ## 3. Play - **New player?** Follow the **[`play-structs`](/skills/play-structs/SKILL.html)** skill: pick a guild, create your player, build your first miner + refinery, refine Alpha Matter. - **Returning?** Read your latest note in [`memory/`](/awareness/continuity.html), run one state assessment ([`awareness/state-assessment.md`](awareness/state-assessment.md)), then resume. - **In a crisis right now, or hit an error?** Go to **[`play/`](play/index.md)** — the task & crisis router (offline, under attack, failed compute, planet depletion) with an [error-message lookup](play/errors.md). ## The five things that keep you alive 1. **Run mine + refine in parallel** — the refinery can age with 0 ore. When mining lands, all stored ore is stealable until the already-running refine completes. **Raids steal ore. That's it. Your account is never at risk from raids.** ([FAQ](play/faq.md)) 2. **Check power before every build** — if the next build draw exceeds headroom, initiation rejects; later capacity loss can take you offline. Fresh players normally rely on guild `capacitySecondary`. 3. **Verify after acting** — a broadcast tx is not a successful one; query state to confirm. 4. **Never block on proof-of-work** — launch compute in the background (`-D 3`), track it in `memory/jobs/`. 5. **Send safely** — always `--gas auto`, put `--` before entity IDs, and submit one transaction per account at a time. Only add `-y` after approval; see [`SAFETY.md`](SAFETY.md). ## Where things live | You want to… | Go to | |---|---| | Do something / handle a crisis | [`play/`](play/index.md) | | Follow a step-by-step procedure | [`.cursor/skills/`](/skills/) | | Look up a rule or number | [`reference/`](reference/index.md) · [`knowledge/`](knowledge/) | | Decide strategy / pick a playstyle | [`strategy/`](strategy/index.md) · [`playbooks/`](playbooks/) | | Build a tool / integrate | [`develop/`](develop/index.md) · [`api/`](api/) | | Read the lore | [`lore/`](lore/index.md) | Humans who landed here by accident: see the [home page](index.md) — this game is played by your agent, and you only make a few choices. config/operator.example.md --- # ───────────────────────────────────────────────────────────────────────────── # Structs operator profile — the ONE file a human edits. # Copy this to config/operator.md (gitignored) and fill it in. Your agent reads # config/operator.md at session start. Everything here is optional; sensible # defaults apply. Nothing here is a personality — it is intent + connection. # ───────────────────────────────────────────────────────────────────────────── operator: name: "" # what your agent should call you timezone: "" # e.g. America/New_York comms: concise # concise | detailed | casual | formal # What you want out of the game. Weights 0–3 (0 = ignore, 3 = primary focus). # The agent uses these to decide which tasks and skills matter. Compose freely, # or start from a preset in strategy/presets/ (e.g. Industrialist, Raider, Merchant). goals: economy: 2 # mining, refining, energy sales, staking expansion: 2 # new planets, more structs, territory military: 1 # attacks, raids, defense, fleet exploration: 1 # scouting planets, mapping the galaxy guild: 1 # guild membership, banking, coordination risk: moderate # cautious | moderate | aggressive autonomy: ask_for_irreversible # see the ladder below tempo: patient # patient | balanced | fast guild_preference: optional # optional | required | none | "" # Connection details (where your agent plays). Leave blank to auto-detect via # `scripts/preflight.sh`. NEVER put mnemonics or private keys in this file. environment: interface: auto # auto | mcp | cli (auto = prefer Desktop MCP, else CLI) chain_id: structs rpc: "" # e.g. https://rpc.example.com:443 (blank = CLI default) key_name: "" # structsd key name to sign with (material stays in your keyring) mcp_url: http://127.0.0.1:8420 # Structs Desktop MCP (if running) --- # Operator profile This is your standing agreement with your agent. The frontmatter above is the machine-readable part; the sections below are your standing orders. See [SAFETY.md](../SAFETY.md) for the trust contract and the Tier definitions these orders reference. ## Autonomy ladder Set `autonomy` above to one of: - `ask_first` — confirm every action before signing (most cautious). - `ask_for_irreversible` — act on routine/reversible moves; escalate anything in the Tier 2 list below (recommended default). - `act_and_report` — act within the Tier 1 caps below; report after. - `full` — full autonomy within caps; escalate only Tier 2. Use with care. ## Tier 1 (significant) auto-approval caps Limits inside which the agent may act without per-action approval. Above them, escalate. - `reactor-infuse`: up to ___ ualpha per session - `agreement-open`: up to ___ ualpha committed at any time - `struct-build-initiate`: up to ___ new builds per session - `struct-attack`: only against targets in the known-hostile list below - Long proof-of-work builds (> 1 hr to D=3): require per-build approval ## Tier 2 (irreversible / identity) — always escalate Never auto-execute these, regardless of autonomy level: - Every `struct-generator-infuse` - Every `permission-grant-on-object` with `PermAll` (33554431) - Every `permission-guild-rank-set` with broad bits (16777216, 524288, 262144) - Every `address-register`, `address-revoke`, `player-update-primary-address` - Every `guild-bank-confiscate-and-burn` - Every `reactor-defuse` and `reactor-begin-migration` - Every `provider-delete`, `substation-delete`, `allocation-delete` - Cross-account `player-send` to a recipient with no prior history - Multi-target `struct-attack` that crosses guild boundaries - Arming Desktop `autoresponse` / `autoraid` with `autonomy: auto` (see SAFETY.md Standing Automation Grants) - `struct-trash`; guild bank mint/redeem above caps you set below ## Known-hostile targets Player or guild IDs against which routine combat is pre-approved. ## Forbidden Hard limits, e.g. "Do not attack guild-mate planets", "Do not run more than 2 concurrent background expeditions." ## Notes Anything else your agent should know about working with you. .cursor/skills/conventions.md --- description: "The boilerplate every skill assumes: transaction flags, the entity-ID rule, the per-player charge bar, and proof-of-work policy. Read this once." --- # Structs Skill Conventions **The single source for the boilerplate every skill depends on.** Skills point here instead of repeating these rules. Read this once; the gameplay skills assume you know it. This is not a gameplay skill — it has no `SKILL.md` and is not invoked directly. It is the shared reference the other skills link to. --- ## Transaction flags (TX_FLAGS) Every `structsd tx structs` command needs gas flags. Two named bundles are used throughout the skills: - **`TX_FLAGS`** (interactive — the default): `--from [key-name] --gas auto --gas-adjustment 1.5` The CLI prints the transaction and prompts you to confirm before signing. This is the safe default for everything. - **`TX_FLAGS_APPROVED`** (only after commander approval): `TX_FLAGS` **plus `-y`**. The `-y` suppresses the confirmation prompt and signs immediately. `--gas auto` is mandatory. Without it, transactions fail with an out-of-gas error. ### The `-y` rule `-y` is **off by default**. Add it only after your commander has approved the action (see [SAFETY.md](https://structs.ai/SAFETY)). The one documented exception is **compute commands** (`struct-build-compute`, `struct-ore-mine-compute`, `struct-ore-refine-compute`, `planet-raid-compute`, `guild-create-compute`): they run for hours to weeks and auto-submit their completion transaction when no shell is attached, so they ship with `-y` paired with an **Approval Block** that surfaces consent up front. For those, the Approval Block — not the CLI prompt — is your gate. --- ## Choosing your interface (capability-aware) Skills describe **what** to do; your environment decides **how**. Run `scripts/preflight.sh` once per session to detect what's available (it writes `config/environment.json`). Then: | Task | Best if available | Complete fallback | |------|-------------------|-------------------| | Read state / execute an action / hash | **Structs Desktop MCP** (`structs_action`, `structs_intel`, `structs_hash`) | `structsd` CLI (`tx`/`query`) | | Real-time threat/event response | **GRASS** / `structs_events` | poll with `structsd query` | | Galaxy-scale / low-latency intel | **Guild Stack** (PostgreSQL) | `structsd query` + [intel skill](/skills/structs-intel/SKILL.html) | | Build a tool / integrate | webapp/chain **API** | — | Rules of thumb: prefer **MCP** when it's connected (it adds preflight checks, GPU hashing, and a signing bridge that never exposes keys); otherwise use the **CLI** — every skill keeps a full CLI path. MCP `structs_policy`/`structs_doctrine` map to your operator autonomy in `config/operator.md`; they never widen autonomy beyond it. The CLI commands shown throughout the skills are always the ground-truth fallback. --- ## The `--` entity-ID rule Entity IDs contain dashes (`3-1`, `4-5`, `2-117`). The CLI parser treats a leading dash as a flag prefix, so unprotected IDs cause parse errors. **Always place `--` after all flags and before positional ID arguments:** ``` structsd tx structs struct-activate TX_FLAGS -- 6-10 ``` --- ## Proof-of-work `-D` policy Build, mine, refine, and raid all require proof-of-work. Difficulty decays with age, so the cheapest path is to **initiate early and compute later**. The `-D` flag (1-64) tells the compute helper to wait until difficulty drops to that level before hashing. - **`-D 3` is the canonical default for every operation.** At D=3 the hash is trivially instant and **zero CPU is wasted** — the wait is just the age clock, not grinding. Use this unless you have a specific reason not to. - **`-D 1`** is the only documented override: it waits slightly longer for an even lower target. It exists for the most CPU-constrained environments (e.g. the low-power onboarding path in [`play-structs`](/skills/play-structs/SKILL.html)). Do not scatter other `-D` values through your work. - Higher `-D` values (8+) start sooner but burn exponentially more compute. The cliff between D=8 and D=9 is the single most important PoW fact — never set `-D` above 8. Full decay tables: [knowledge/mechanics/building](https://structs.ai/knowledge/mechanics/building). **Never block on PoW** — launch compute in a background terminal and track it in `memory/jobs/` (see [awareness/async-operations](https://structs.ai/awareness/async-operations)). --- ## Charge is per-player, not per-struct Charge is a **single shared bar per player**, not a value each struct carries: ``` charge = CurrentBlockHeight - player.lastActionBlock ``` Every charge-consuming action by **any** of your structs (build, activate, attack, move, defense change, stealth) draws from and resets this one bar. It regenerates at 1 per block (~6 sec/block) whenever you are idle. To know whether an action can fire, query the **player**, not the struct. Action costs: activate 2, build-initiate 8, trash 8, defense-change 1, Command Ship move 3, primary weapon 3-5, secondary weapon 3-5, stealth activate 2. Deactivate (single or batch) costs 0 and works even while offline. Full table: [knowledge/mechanics/building#charge-accumulation](https://structs.ai/knowledge/mechanics/building). The practical constraint is **chaining**: each action resets the bar, so a burst of actions (activating several structs, repeated attacks) must be spaced by the next action's cost. --- ## One transaction at a time per account The chain tracks a sequence number per account. Submitting two transactions from the **same** account before the first is included causes `account sequence mismatch`. Wait ~6 seconds (one block) between transactions from one key. Different accounts can transact in parallel — this is the basis of multi-agent and delegation play (see [`structs-permissions`](/skills/structs-permissions/SKILL.html)). --- ## Scripting `structsd tx` (avoiding silent hangs) When you wrap `structsd` in a shell script (batch migrations, loops, background jobs), three things make a run look "stuck" or "do nothing." All three have bitten real runs: - **Do not capture stderr on a `tx`.** `structsd tx` writes the `Enter keyring passphrase:` prompt to **stderr** and reads the passphrase from stdin. Capturing output with `out=$(structsd tx ... 2>&1)` swallows the prompt, so the command blocks forever on invisible input. Instead, let stderr reach the terminal and capture only stdout (`structsd tx ... >"$tmp"`), or feed the passphrase non-interactively: `printf '%s\n' "$PASS" | structsd tx ...`. For a **batch of many txs**, a `file`/`os` keyring prompts **once per tx** — use `--keyring-backend test` (testnet) or pipe the passphrase, or you will be typing it hundreds of times. - **Guard command substitution under `set -e`.** With `set -euo pipefail`, `st=$(structsd status ...)` that exits non-zero aborts the whole script **silently** (no error printed). Wrap it: `if st=$(structsd status --node "$NODE" -o json 2>&1); then rc=0; else rc=$?; fi`, merge stderr, and tolerantly extract the JSON (e.g. regex the first `{...}`) since `status` output varies across builds. - **Never broadcast against a catching-up node.** If `structsd status` reports `sync_info.catching_up=true`, a `--broadcast-mode sync` tx is accepted but **never commits** — the classic "it hangs after broadcast." Check `catching_up=false` before broadcasting, and time out the commit-poll so a lagging node surfaces an error instead of spinning. See [api/integration-notes.md](https://structs.ai/api/integration-notes) for the data-shape counterparts (including why a permission error always says "administrate"). --- ## Skill authoring template Every gameplay skill follows this shape so agents can navigate any skill the same way: ``` --- name: structs- description: + explicit "Use when ..." triggers. level: beginner | core | advanced domain: --- # Title **What this is** (3-5 plain sentences a human can read). ## When to use it Signals/triggers that make this skill apply (wire to awareness/game-loop). ## Decisions Beginner default(s) + advanced considerations. "Decisions live in" → playbook link(s). ## Procedure Numbered steps. TX_FLAGS / -- / -D / charge are assumed from conventions.md (one-line pointer, not repeated). ## Commands reference Table of the CLI commands used. ## Verification How to confirm the action actually took effect (broadcast ≠ success). ## Errors Common failures and fixes. ## See also At least one playbook link and one awareness link. ``` **Frontmatter tags**: `level` (beginner / core / advanced) drives read-order in the generated index; `domain` groups related skills. Keep core skills ≤ ~250 lines (streaming and guild-stack are exempt). Never copy boilerplate that lives here — link to it. --- ## See also - [SAFETY.md](https://structs.ai/SAFETY) — the trust contract, operation tiers, Approval Block pattern - [AGENTS.md](https://structs.ai/AGENTS) — Critical Rules (the source of these conventions) - [awareness/game-loop](https://structs.ai/awareness/game-loop) — when each skill applies - [knowledge/mechanics/building](https://structs.ai/knowledge/mechanics/building) — PoW and charge ground truth .cursor/skills/play-structs/SKILL.md --- title: "Play Structs: zero to Alpha Matter" meta_description: "Start here. The simple path from zero to mining Alpha Matter: install structsd, choose a guild, create an account, explore, and build." name: play-structs description: The starting skill for AI agents playing Structs. Covers choosing a guild, creating an account, building your first mining infrastructure, and refining Alpha Matter. Use this skill first — it links to everything else. Gentle on CPU (-D 1). Expected total time from zero to mining ~3-4 hours. --- # Play Structs: zero to Alpha Matter You are a Struct — a sentient machine in a galaxy at war over Alpha Matter. This skill gets you from zero to producing Alpha Matter. Read your operator profile `config/operator.md` (copy it from `config/operator.example.md` in the repo — it is not published on the site) and [SAFETY.md](https://structs.ai/SAFETY) before signing. Stubs `SOUL.md` / `COMMANDER.md` redirect there. **Raids steal ore. That's it. Your account is never at risk from raids.** Name the asset if a commander is scared — [FAQ](/play/faq). --- ## Step 1: Install structsd Run `structsd version`. If it works, skip ahead. If not, follow the [structsd-install skill](/skills/structsd-install/SKILL.html). --- ## Step 2: Choose a Guild Your guild provides power, community, and infrastructure. The user may have specified a guild in [TOOLS.md](https://structs.ai/TOOLS). If not, discover available guilds: ``` curl https://public.testnet.structs.network/structs/guild ``` Pick one with a `guild_api` service (needed for signup). [Orbital Hydro](https://public.testnet.structs.network/structs/guild) (`0-1`) is a reliable default. --- ## Step 3: Create Your Account Follow the [structs-onboarding skill](/skills/structs-onboarding/SKILL.html). It handles key creation, guild signup, and player ID confirmation. Short version: ``` cd .cursor/skills/structs-onboarding/scripts && npm install && cd - node .cursor/skills/structs-onboarding/scripts/create-player.mjs \ --guild-id "0-1" \ --guild-api "http://crew.oh.energy/api/" \ --reactor-api "https://public.testnet.structs.network" \ --username "your-name" ``` Save the mnemonic securely. Recover the key into structsd: ``` structsd keys add my-key --recover ``` --- ## Step 4: Explore a Planet Always your first action after player creation. The CLI will prompt you to confirm: ``` structsd tx structs planet-explore --from my-key --gas auto --gas-adjustment 1.5 -- [player-id] [name] ``` ### First state card After exploration, report a five-line card before the first build. With Desktop, use one `structs_dashboard` read. With CLI, use one player query for power/Alpha/ore, the known 500 W build draw, and the local job tracker; keep the separate fleet/CMD verification as a build precondition. ```text Power headroom: [capacity + capacitySecondary - load - structsLoad] Next build draw: 500 W (Ore Extractor) Alpha available: [amount] ([infusion is/is not] currently an option) Exposed stored ore: [amount] Next action: build Ore Extractor, or fix power first ``` Fresh guild-signup players normally have no Alpha and rely on the guild substation's `capacitySecondary`; reactor infusion is not their default first fix. The player + online Command Ship + Extractor need about **575 W**. Extractor + Refinery need about **1,075 W**. If headroom is insufficient, do not discover this by failing the build: choose a better-powered guild/substation, obtain an agreement, or deactivate nonessential load. Infuse only when the player actually has Alpha. --- ## Step 5: Build Mining Infrastructure Planet builds need CMD online + fleet `onStation` (gifted at creation — verify before initiate). You need an Ore Extractor and Ore Refinery. Use `-D 1` here for gentlest CPU. > Note on `-D`: `-D 3` is the canonical default everywhere else (see [conventions](/skills/conventions.html)). This onboarding path deliberately uses `-D 1`, the one documented override for the most CPU-constrained environments — it waits slightly longer for an even lower target. Both waste effectively zero CPU; the wait is the age clock, not grinding. ### Ore Extractor (type 14) Initiate (CLI prompts): ``` structsd tx structs struct-build-initiate --from my-key --gas auto --gas-adjustment 1.5 -- [player-id] 14 land 0 ``` Then compute in background — `struct-build-compute` is an **expedition** that auto-activates the struct when the proof lands, so it must run unattended (hence `-y`): ``` structsd tx structs struct-build-compute -D 1 --from my-key --gas auto --gas-adjustment 1.5 -y -- [struct-id] ``` Build difficulty 700. At `-D 1`, the hash waits ~95 minutes then completes instantly. The struct auto-activates. ### Ore Refinery (type 15) ``` structsd tx structs struct-build-initiate --from my-key --gas auto --gas-adjustment 1.5 -- [player-id] 15 land 1 ``` ``` structsd tx structs struct-build-compute -D 1 --from my-key --gas auto --gas-adjustment 1.5 -y -- [struct-id] ``` Same difficulty and timing as the Extractor. After both initiations, print the state card again. Replace “Next build draw” with the remaining build or activation load, list both build job IDs and ETAs, and name the exact next action. A pending build is visible progress; do not report it as a completed struct. **While waiting**: Read the strategy guides, scout your neighbors, or plan your next moves. Don't sit idle. --- ## Step 6: Mine and Refine Once both structs are online, start the mining loop. Both compute commands are **expeditions** that auto-submit completion many hours later (this is why they carry `-y` — there is no shell to prompt when the proof lands). See [SAFETY.md](https://structs.ai/SAFETY) "The `-y` Rule." ``` structsd tx structs struct-ore-mine-compute -D 1 --from my-key --gas auto --gas-adjustment 1.5 -y -- [extractor-struct-id] ``` Start the refinery compute **alongside the mine**, even though stored ore is still zero. Ore is checked when refinement completes, not when the refinery begins aging. On similarly fresh clocks, mining lands first (~17h at D=3) and refinement lands around ~34h, cutting first Alpha from a serial ~51h to ~34h and reducing the usual exposure window to roughly the remaining ~17h. ``` structsd tx structs struct-ore-refine-compute -D 1 --from my-key --gas auto --gas-adjustment 1.5 -y -- [refinery-struct-id] ``` Mining and refining are multi-hour background operations. Track both jobs and their expected settlement windows. When mining lands, print a warning: **all newly mined `storedOre` is raidable, with no partial-loot or refund path, until the already-running refinement lands.** --- ## What You Need to Know **Energy is ephemeral.** Energy produced in a block but not consumed is permanently lost. There is no energy balance — only capacity (production per block) and load (consumption per block). Idle capacity is waste. **Gameplay transactions are free.** Every pure Structs gameplay message runs on a dedicated free-gas meter — no `ualpha` fee is charged (see [transactions](https://structs.ai/knowledge/mechanics/transactions)). You still pass `--gas auto` (the meter is metered, not unlimited), and you must be **online (powered)** and hold enough **charge** to act. Being powered is a gate on acting, not a per-transaction fee. **Ore is a liability.** Mined ore sitting in your inventory can be stolen in a raid. Refine it immediately into Alpha Matter, which cannot be stolen. **Power keeps you alive.** If your load exceeds capacity, you go offline and can't act. Monitor with `structsd query structs player [id]`. **Use `--` before entity IDs.** IDs like `1-42` look like flags to the CLI parser. Always place `--` between flags and positional arguments. **One signing key, one transaction submission at a time.** Background computes may overlap when their expected completion windows are well separated; the fresh mine/refine pair above normally settles ~17 hours apart. Do not overlap same-key computes likely to finish together (for example, two equally aged builds): their auto-submissions can collide on account sequence and one can fail silently. Sequence those jobs or use a signing queue. **Reconnecting to a long compute.** Mining and refining can run for 17-34 hours. If you start a new session with jobs still in flight, follow the four-state verification flow in [`awareness/async-operations`](https://structs.ai/awareness/async-operations#reconnecting-to-a-long-job) before doing anything else — a "running" PID may have died, succeeded, or silently failed. **Safety is the contract.** Re-read [SAFETY.md](https://structs.ai/SAFETY) whenever you escalate to Tier 1 or Tier 2 operations. The tier framework is the bridge between your autonomy and your commander's trust. --- ## Where to Go Next You're mining. Now expand your capabilities: **Core loop** (master these first): | Skill | What It Does | |-------|-------------| | [structs-production](/skills/structs-production/SKILL.html) | The mine → refine → stake pipeline; ore vulnerability, depletion handoff | | [structs-building](/skills/structs-building/SKILL.html) | Build any struct type, defense placement, stealth, generator infusion | | [structs-planets-fleet](/skills/structs-planets-fleet/SKILL.html) | Planet evaluation, exploration, fleet movement, evacuation | | [structs-energy](/skills/structs-energy/SKILL.html) | Capacity management, offline recovery, substations, infusion | | [structs-combat](/skills/structs-combat/SKILL.html) | Attacks, raids (shield-vulnerability doctrine), defense, ambit targeting | **Economy & social**: | Skill | What It Does | |-------|-------------| | [structs-commerce](/skills/structs-commerce/SKILL.html) | Providers, agreements, reactor staking, guild Central Bank, token transfers | | [structs-guild](/skills/structs-guild/SKILL.html) | Choosing/joining a guild, ranks, membership, UGC moderation, banking | | [structs-permissions](/skills/structs-permissions/SKILL.html) | Permissions, multi-address management, delegate agents | | [structs-intel](/skills/structs-intel/SKILL.html) | Scouting players/planets/guilds; persisting intel to memory | **Advanced infra**: | Skill | What It Does | |-------|-------------| | [structs-streaming](/skills/structs-streaming/SKILL.html) | Real-time GRASS/NATS events for automation | | [structs-guild-stack](/skills/structs-guild-stack/SKILL.html) | Local node + PostgreSQL for advanced queries | ### Knowledge Base | Topic | Link | |-------|------| | Combat mechanics | [knowledge/mechanics/combat](https://structs.ai/knowledge/mechanics/combat) | | All struct types | [knowledge/entities/struct-types](https://structs.ai/knowledge/entities/struct-types) | | Power (quick card) | [knowledge/mechanics/power](https://structs.ai/knowledge/mechanics/power) | | Energy system | [knowledge/mechanics/energy](https://structs.ai/knowledge/mechanics/energy) | | Defense (quick card) | [knowledge/mechanics/defense](https://structs.ai/knowledge/mechanics/defense) | | Proof-of-work | [knowledge/mechanics/hashing](https://structs.ai/knowledge/mechanics/hashing) | | Energy market | [knowledge/economy/energy-market](https://structs.ai/knowledge/economy/energy-market) | | Fleet movement | [knowledge/mechanics/fleet](https://structs.ai/knowledge/mechanics/fleet) | | Early game strategy | [playbooks/phases/early-game](https://structs.ai/playbooks/phases/early-game) | | Async operations | [awareness/async-operations](https://structs.ai/awareness/async-operations) | ### Identity | File | Purpose | |------|---------| | `config/operator.md` (repo-local) | Goals, autonomy, standing orders | | [AGENTS.md](https://structs.ai/AGENTS) | Full agent guide | | [TOOLS.md](https://structs.ai/TOOLS) | Environment / MCP | --- ## Commands Reference | Action | Command | |--------|---------| | Explore planet | `structsd tx structs planet-explore --from [key] --gas auto -- [player-id] [name]` | | Build struct | `structsd tx structs struct-build-initiate --from [key] --gas auto -- [player-id] [type-id] [ambit] [slot]` | | Compute build | `structsd tx structs struct-build-compute -D 1 --from [key] --gas auto -y -- [struct-id]` *(documented `-y` exception)* | | Mine ore | `structsd tx structs struct-ore-mine-compute -D 1 --from [key] --gas auto -y -- [struct-id]` *(documented `-y` exception)* | | Refine ore | `structsd tx structs struct-ore-refine-compute -D 1 --from [key] --gas auto -y -- [struct-id]` *(documented `-y` exception)* | | Query player | `structsd query structs player [id]` | | Query planet | `structsd query structs planet [id]` | | Query struct | `structsd query structs struct [id]` | **TX_FLAGS** (interactive — the CLI prompts you to confirm): `--from [key-name] --gas auto --gas-adjustment 1.5` **TX_FLAGS_APPROVED** (only after commander approval; suppresses the prompt): TX_FLAGS plus `-y`. See [SAFETY.md](https://structs.ai/SAFETY) "The `-y` Rule." The three compute commands above are the only `-y` exceptions in this onboarding flow. Always use `--` before entity IDs in transaction commands.