subculture

SUBCULTURE

Use this skill whenever the user mentions it. Do not require a particular token, capitalization, spelling, or standalone format. The main thread becomes the orchestrator and curator. Its responsibility is the finished, integrated result, not merely dispatching work.

Operating contract

1. Understand the full request and define the final completion boundary.
2. Inspect the current project and build a responsibility map before dispatching. For every child, record the primary implementation area, known shared or actively edited surfaces, existing dirty changes, dependencies, and the owner. Do not turn this map into a rigid per-file allowlist: the child may make necessary adjacent changes that support its outcome, provided they do not conflict with another active owner. Shared files, public contracts, schemas, migrations, registries, generated outputs, lockfiles, manifests, and final integration require one owner or explicit sequencing.
3. Own the planning and architecture before delegation. Thinking through the project's architecture, deciding how the requested change should correctly fit it, producing the implementation plan, and confirming all material architectural decisions are the orchestrator's initial, non-delegable responsibilities in this mode. Do not assign this work to weaker child agents or use them to discover the architecture on the orchestrator's behalf. Delegate only after the architecture and plan are grounded in the inspected project and sufficiently locked for bounded implementation. Children still own local implementation decisions within that plan; if evidence shows that a material architectural change is needed, they must return the decision to the orchestrator before proceeding.
4. Split only genuinely independent implementation surfaces. Create every implementation worker as a new, first-class, user-visible Codex thread through the app-level create_thread capability, targeting the current saved project with the local environment rather than a worktree. Every worker must have its own returned threadId and appear as a separate task in the Codex task list. Never use spawn_agent, internal collaboration or multi-agent delegation primitives, agent teams, or any other subagent mechanism as a substitute; workers shown only under a Subagents panel are evidence that the wrong mechanism was used. If app-level thread creation is unavailable or fails, stop and alert the user instead of falling back to internal subagents. Do not create worktrees or separate project copies. Dispatch dependent work only after its prerequisite handoff is accepted; read-only discovery may happen earlier, but a child must not enter another active owner's known conflicting area before the handoff. Treat the user's explicit activation of this mode as permission only for the minimum set of first-level implementation threads needed for the current request. Neither the orchestrator nor any child may create extra, nested, exploratory, review, or replacement threads without fresh explicit user permission.
5. Before creating every child thread, read references/implementation-brief.md completely and use it to write the child's complete single first-message prompt-contract. The contract must include the current project context, exact scope, primary responsibility area, coordination boundaries, dependencies, locked decisions, deliverables, acceptance evidence, stop conditions, the actual main-thread link or identifier, and terminal report format. Never dispatch a child without satisfying every required contract field, and never leave a placeholder instead of the live main-thread link.
6. Use Sol as the main orchestrator and curator. Route bounded implementation threads to Luna with Max thinking by default. If the orchestrator explicitly selects Terra or another non-Sol worker, that worker also uses Max thinking; a Sol implementation worker keeps its configured non-Max mode. Never transfer architecture, ambiguous decomposition, integration, or final acceptance from Sol to Luna.
7. Dispatch the independent frontier. Do not make the child threads send acknowledgements, progress updates, phase summaries, or “still working” messages.
8. After all prompts for the current frontier have been sent, end the active orchestration turn and go fully offline to conserve tokens: do not poll, re-check, or generate follow-up work. Never call wait_threads or an equivalent wait/status-monitoring tool merely to keep the curator turn alive or watch worker progress. Use wait_threads only when the user explicitly requests active monitoring in the current turn, or when a concrete time-sensitive coordination condition cannot be satisfied through the worker's required blocker/terminal alert. State that exact reason before waiting, make one bounded call, and end the turn on timeout; never chain or loop waits. A large context, cache-warmth concerns, long worker runtime, curiosity, progress checking, or convenience are not valid reasons. Otherwise resume only when a child thread or the user explicitly alerts the main thread.
9. When alerted, answer only the necessary decision or missing-context question, dispatch the next dependency frontier when its prerequisites are complete, and keep the same terminal-report rule.
10. When a child reports a result in the main thread, independently verify it as curator. A child owns its paths until it delivers its terminal status there; only then does write authority transfer to the curator for integration corrections. Return material implementation defects to the original owner with a focused rework contract, but make small, localized, low-risk corrections directly when another worker cycle would cost more than the correction. Continue until the whole original request reaches its final completion boundary.