Structs Power

Manages power infrastructure in Structs. Covers substations, allocations, player connections, and power monitoring. Use when power is low or overloaded, crea...

Security Scan

The skill's instructions match its stated purpose (managing Structs power) but the package metadata omits required runtime dependencies (structsd CLI and local key access) and there's minor metadata inconsistency, so proceed with caution.

Purpose & Capability

The SKILL.md actions (creating substations/allocations, connecting players, queries) align with the skill name and description. This is a coherent set of capabilities for a 'power management' skill for Structs.

Instruction Scope

All runtime instructions are concrete structsd CLI commands and queries; they stay within the stated domain (power/substations/allocations). However the instructions require submitting transactions (TX_FLAGS) with a '--from [key-name]' which implies the agent will need access to a local keyring or wallet configuration—this is not declared in the metadata.

Install Mechanism

The skill is instruction-only (no install spec), which is the lowest install risk. That said, it implicitly depends on the 'structsd' CLI being present on the host; the package metadata lists no required binaries, which is inconsistent with the instructions.

Credentials

requires.env lists none, but TX_FLAGS include '--from [key-name]' and the commands will use whatever keyring/config 'structsd' has access to. The skill may cause the agent to read local wallet keys or sign transactions. The lack of declared binary or credential requirements is a proportionality/visibility concern.

Persistence & Privilege

always:false and no install/write operations. The skill does not request persistent presence or system-level configuration changes in its files. The main risk is transactional (it will instruct the agent to submit on-chain txs if executed).

What to consider before installing

This skill appears to do what it says (manage substations/allocations via the structsd CLI), but it assumes the structsd binary and access to local signing keys (the TX_FLAGS --from value). The registry metadata does not declare these dependencies and there is no homepage/source to verify the author. Before installing or enabling autonomous use: (1) confirm you trust the skill owner and the source; (2) ensure structsd is installed intentionally and understand which local key the agent would use to sign transactions; (3) avoid giving the agent access to high-value keys—test in a sandbox or with a low-privilege key; (4) consider disabling autonomous invocation if you do not want the agent to submit transactions without manual approval. Also note a minor metadata mismatch: _meta.json shows version 1.0.1 while registry metadata lists 1.2.0 and there is no homepage—these reduce provenance confidence.

Important: Entity IDs containing dashes (like 3-1, 4-5) are misinterpreted as flags by the CLI parser. All transaction commands in this skill use -- before positional arguments to prevent this.

Procedure

1. Assess power state — Query player: structsd query structs player [id]. Compute: availablePower = (capacity + capacitySecondary) - (load + structsLoad). If load + structsLoad > capacity + capacitySecondary, player goes OFFLINE (cannot act). Player passive draw: 25,000 mW.
2. Create substation — First create allocation from reactor/generator: structsd tx structs allocation-create --allocation-type static|dynamic|automated|provider-agreement TX_FLAGS -- [source-id] [power]. The --controller flag accepts a PlayerId (e.g., 1-42). If omitted, the creating player is the default controller. Then: structsd tx structs substation-create TX_FLAGS -- [owner-id] [allocation-id].
3. Connect power — structsd tx structs substation-allocation-connect -- [substation-id] [allocation-id] to add source. structsd tx structs substation-allocation-disconnect -- [substation-id] [allocation-id] to remove.
4. Connect players — structsd tx structs substation-player-connect -- [substation-id] [player-id] to draw power. structsd tx structs substation-player-disconnect -- [substation-id] [player-id] to remove.
5. Migrate players — structsd tx structs substation-player-migrate TX_FLAGS -- [source-substation-id] [dest-substation-id] [player-id,player-id2,...].
6. Manage allocations — Update: structsd tx structs allocation-update -- [allocation-id] [new-power]. Delete: structsd tx structs allocation-delete -- [allocation-id].
7. Delete substation — structsd tx structs substation-delete -- [substation-id] (disconnect allocations/players first).

Commands Reference

Action	Command
Substation create	structsd tx structs substation-create -- [owner-id] [allocation-id]
Substation delete	structsd tx structs substation-delete -- [substation-id]
Allocation connect	structsd tx structs substation-allocation-connect -- [substation-id] [allocation-id]
Allocation disconnect	structsd tx structs substation-allocation-disconnect -- [substation-id] [allocation-id]
Player connect	structsd tx structs substation-player-connect -- [substation-id] [player-id]
Player disconnect	structsd tx structs substation-player-disconnect -- [substation-id] [player-id]
Player migrate	structsd tx structs substation-player-migrate -- [src-substation-id] [dest-substation-id] [player-ids]
Allocation create	structsd tx structs allocation-create --allocation-type [type] -- [source-id] [power]
Allocation update	structsd tx structs allocation-update -- [allocation-id] [power]
Allocation delete	structsd tx structs allocation-delete -- [allocation-id]

TX_FLAGS: --from [key-name] --gas auto --gas-adjustment 1.5 -y

Verification

• Player: structsd query structs player [id] — capacity, capacitySecondary, load, structsLoad, online status.
• Substation: structsd query structs substation [id] — connected allocations, players.
• Allocations: structsd query structs allocation-all-by-source [source-id], allocation-all-by-destination [dest-id] — power flow.

How to Increase Capacity

If capacity is too low (or you're going offline), there are three paths:

Method	Requires	Speed	Risk	Rate
Reactor infusion	Alpha Matter	Immediate	Low	1g ≈ 1 kW (minus commission)
Generator infusion	Alpha Matter + generator struct	Immediate	High (irreversible, raidable)	1g = 2-10 kW
Buy via agreement	A provider with capacity	Immediate	Medium (ongoing cost)	Varies by provider

Most common: Infuse Alpha Matter into your guild's reactor. Capacity increases automatically.

For step-by-step workflows, see the structs-energy skill.

Error Handling

• Going offline: Load exceeds capacity. Deactivate structs immediately (struct-deactivate), then increase capacity — see the structs-energy skill for options.
• Allocation exceeds source: Source (reactor/provider) has limited capacity. Query source; create smaller allocation or add capacity.
• Substation delete failed: Ensure no players or allocations connected. Disconnect first.
• Automated allocation limit: One automated allocation per source. Attempting a second from the same source will error. Use static/dynamic for multiple.
• capacity=0 false positive: A player connected to a substation pool may show capacity=0 while structs are online and drawing power. Check structsLoad > 0 as the real indicator of functionality, not capacity > 0.

See Also

• structs-energy skill — "I need more energy" decision tree and workflows
• knowledge/mechanics/power — Formulas, capacity, load, online status
• knowledge/mechanics/building — Build power requirements
• knowledge/mechanics/resources — Reactor vs generator conversion rates