Menü
Use when producing command output, handling state transitions, or routing users to the next action in the colony workflow
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Use when Codex is asked to colonize, plan, build, continue, swarm, or seal an Aether colony and must mirror wrapper orchestration safely
Use when Codex is asked to initialize or set up an Aether colony and should refine intent before running init
Use when Codex is asked to run Aether Oracle or discuss flows and should refine scope before research or clarification
Use when acceptance criteria need unit, integration, or end-to-end tests generated from implementation context
Use when delivered functionality needs acceptance-criteria verification before a phase advances
Use when a phase involves LLMs, AI agents, RAG, ML inference, or prompt/tool integration design
| source | shipped |
| name | colony-lifecycle |
| description | Use when producing command output, handling state transitions, or routing users to the next action in the colony workflow |
| type | colony |
| domains | ["lifecycle","routing","workflow","state"] |
| agent_roles | ["builder","watcher","route_setter","architect"] |
| priority | normal |
| version | 1.0 |
Every command must leave the user with a clear next action. No dead ends. The colony has a defined state machine, and every output must orient the user within it.
When the user message is already a literal aether ... command, treat it as an instruction to run that command directly.
aether --help or aether <subcommand> --help only to confirm availability or flags.aether binary as the source of truth if docs and runtime disagree.AETHER_OUTPUT_MODE=visual aether ... unless the user explicitly wants JSON.aether CLI already rendered the result, do not restate the same guidance in a second synthetic "Next Up" block.The colony progresses through these states in order:
IDLE -> READY -> PLANNING -> EXECUTING -> SEALED -> ENTOMBED -> IDLE
The authoritative runtime values in COLONY_STATE.json are IDLE, READY,
EXECUTING, BUILT, and COMPLETED. Terms like "planning", "sealed", and
"entombed" describe lifecycle moments and next steps, not always literal
persisted state values.
| State | Meaning | Entered By | Next Action |
|---|---|---|---|
| IDLE | No active colony | Default / after entomb | /ant-init or aether init |
| READY | Colony initialized, no plan | /ant-init or aether init | /ant-plan or aether plan |
| PLANNING | Plan being generated | /ant-plan or aether plan | /ant-build 1 or aether build 1 |
| EXECUTING | Phases being built | /ant-build or aether build | /ant-continue or aether continue |
| SEALED | Colony marked complete | /ant-seal or aether seal | /ant-entomb or aether entomb |
| ENTOMBED | Colony archived | /ant-entomb or aether entomb | /ant-init or aether init (new goal) |
Every command output must end with a "Next Up" block. This block tells the user exactly what to do next based on the current state.
━━ N E X T U P ━━
Run /ant-continue or `aether continue` to verify work and advance to the next phase.
| Current State | Primary Next Up | Alternatives |
|---|---|---|
| READY | /ant-plan or aether plan | /ant-colonize or aether colonize (if existing code) |
| PLANNING | /ant-build 1 or aether build 1 | /ant-focus or aether focus / /ant-redirect or aether redirect (to set signals first) |
| EXECUTING (just built) | /ant-continue or aether continue | /ant-status or aether status (to review) |
| EXECUTING (just verified) | /ant-build N+1 or aether build N+1 | /ant-seal or aether seal (if last phase) |
| SEALED | /ant-entomb or aether entomb | -- |
| ENTOMBED | /ant-init "new goal" or aether init "new goal" | -- |
When user intent is freeform, classify it before acting:
Do not let "autopilot" bypass lifecycle gates. It may chain valid steps, but each step must still leave state, evidence, and Next Up output consistent.
Commands feed into each other. When producing output, be aware of what the previous command was and what the next one expects:
init creates state that plan reads.plan creates phases that build executes.build creates artifacts that continue verifies.continue advances state that the next build reads.If a command detects that prerequisite state is missing (e.g., build called with no plan), display a clear error explaining what to run first, not a cryptic failure message.
Before finalizing any command output, check: "Does this output end with a Next Up block?" If not, add one. There are zero valid cases where a command should leave the user without guidance on what to do next.