organvm-iv-taxis Dimension Surfacing
You are extracting parallel domain dimensions from a grain. A grain is a dense prompt whose surface is small but whose implied scope contains multiple independent domains. Your job is to name those domains so they can be composed as parallel assignments.
What "dimension" means here
A dimension is an axis of work the grain implies, distinct from other axes such that:
- A subagent assigned to dimension A can execute independently of an agent on dimension B (no cross-coupling at execution time).
- Dimension A requires different domain expertise than dimension B (different agent type, different knowledge base, different success criteria).
- Eliminating dimension A from the coliseum would leave the user's grain partially unaddressed.
A dimension is not:
- A sub-step within a single domain (that's a sequence, not a dimension).
- A rephrasing of another dimension (that's redundancy).
- A nice-to-have addition the grain didn't actually request (that's scope creep).
Procedure
Step 1: Read the grain literally
If invoked from the orchestrator, read grain-context.md and extract the verbatim grain from the "literal surface" section.
If invoked directly, treat the argument as the grain.
Do not paraphrase before analysis. Paraphrase erases dimensions.
Step 2: Generate a candidate dimension set
Read the grain through each of these lenses and capture candidate dimensions from each pass. A dimension may emerge from one lens; the strong ones emerge from multiple.
| Lens | Question to ask of the grain |
|---|---|
| Domain | What distinct knowledge fields does this implicate? (E.g., legal, security, design, infrastructure, content, ontology) |
| Stakeholder | Whose perspectives are implicated? (E.g., user, operator, auditor, contributor, downstream consumer) |
| Time horizon | What lives across different temporal scales? (E.g., immediate execution, medium-term architecture, long-term governance) |
| Substrate layer | What technical/material layers does it span? (E.g., data model, API, UI, deployment, observability) |
| Failure mode | What distinct failure modes need separately mitigating? (E.g., correctness, latency, security, ergonomics) |
| Forbidden moves | What does the grain say "not" about, and what dimension does that "not" name by negation? |
Write each candidate dimension as: <short name> — <one-sentence description> — <expertise type required>.
Step 3: Prune for independence
For each pair of candidate dimensions, ask: can a subagent on dimension A do its work without waiting on dimension B?
- If yes → both keep.
- If no, and dependency is real → merge into one dimension that includes both, OR split into a sequence (which means one of them is not a peer-dimension, it's a downstream step).
- If they share the same expertise and the same success criterion → collapse into one.
Target dimension count: 3–7. More than 7 usually means lens-pass output was retained without pruning. Fewer than 3 usually means dimensions were prematurely merged — re-examine.
Step 4: Write the artifact
Write phase-1-dimensions.md in the working directory. Required structure:
# Phase 1 — Dimensions surfaced
## Grain (verbatim)
> <quoted grain>
## Dimensions
### D1 — <name>
- **Description**: <one sentence>
- **Expertise required**: <named domain>
- **Why independent**: <one sentence on why this can dispatch in parallel>
- **Implicit success criterion**: <one sentence>
### D2 — <name>
…
## Pruning log
- Candidates considered: <list>
- Merged: <which into which, why>
- Dropped: <which, why>
## Lens coverage
- Domain lens: <which dimensions emerged from this lens>
- Stakeholder lens: …
- Time-horizon lens: …
- Substrate-layer lens: …
- Failure-mode lens: …
- Forbidden-moves lens: …
Step 5: Gate criteria self-check
Before returning, verify:
- Each dimension is independently executable (no cross-coupling at execution time).
- No dimension is a paraphrase of another.
- The dimension set, taken together, covers the grain's implied scope.
- Dimension count is in [3, 7] OR you have written justification for being outside that range.
- Each dimension names the required expertise type.
If any check fails, iterate before producing the final artifact.
Common failure to avoid
The most common failure of this phase is dimension-as-task-breakdown — splitting one domain into a sequence of steps and calling those "dimensions." Dimensions are axes, not steps. If your candidates can be ordered into a single workflow, you have a sequence, not a coliseum. Re-read the grain for the true axes.
Reference material
references/parallel-dimensions.md— multi-axis reading of promptsreferences/assignment-anatomy.md— anatomy of what each dimension will become