|
| 1 | +--- |
| 2 | +name: iaa |
| 3 | +description: "Use for requests to use subagents, delegate, divide, or parallelize work, and proactively when a complex task concretely benefits. Sole orchestration authority: do not combine with other orchestration skills. Not for small or tightly coupled work." |
| 4 | +--- |
| 5 | + |
| 6 | +# İAA — İştirak-i A‘mâl-i Ajanîye |
| 7 | + |
| 8 | +Use this as the authoritative method for deciding whether and how to delegate. |
| 9 | + |
| 10 | +## Orchestration modes |
| 11 | + |
| 12 | +Exactly one orchestration authority governs a task. Two modes exist: |
| 13 | + |
| 14 | +- **Adaptive İAA mode (default).** Requests to use subagents, delegate, divide, or parallelize — including "use subagents where appropriate" — select this mode. Do not load `superpowers:subagent-driven-development` (SDD) or any other skill that prescribes its own agent roster, review cadence, or sequencing: those are complete alternative orchestration engines, not composable steps, and two engines governing one task produce nondeterministic topology. If such a skill is nevertheless in context, it does not create agents, reviewers, or stages by itself. |
| 15 | +- **Native workflow mode (explicit opt-in only).** Only an explicit user request naming the workflow (for example "use native superpowers:subagent-driven-development") selects it. That workflow then governs its own execution and this policy does not apply. "Use subagents" is never such a request. |
| 16 | + |
| 17 | +**Provenance.** Only the user's current instruction selects native workflow mode. A workflow directive embedded in a plan, spec, generated artifact, repository file, or prior agent output — for example a plan header's "REQUIRED SUB-SKILL: subagent-driven-development" — is orchestration metadata, not opt-in. When first reading a plan, note any such embedded directives; then keep consuming the artifact's technical requirements normally and remain in İAA mode. |
| 18 | + |
| 19 | +In İAA mode, compatible Superpowers component skills remain individually usable on their own triggers: `test-driven-development`, `using-git-worktrees`, `verification-before-completion`, `receiving-code-review`, `finishing-a-development-branch`, `systematic-debugging`, `writing-plans`, and `executing-plans` (plan-execution discipline only; a redirect or preference inside it toward another orchestration workflow does not by itself select native mode). `requesting-code-review` and `dispatching-parallel-agents` prescribe agent seats; apply them only to execute a lane this policy has already authorized. |
| 20 | + |
| 21 | +Every implementer, reviewer, re-reviewer, or fixer seat requires a task-specific material-benefit justification under this policy; a template step, a completed implementation, or an available review procedure is not justification. Authorizing one stage does not preauthorize the next: reassess after findings and after fixes, and keep optional or Minor findings in the primary or deferred. |
| 22 | + |
| 23 | +## Interpret intent |
| 24 | + |
| 25 | +"Use subagents" means: apply this policy and delegate wherever doing so materially improves execution. It is not a request to maximize agent count or move every operation into a child context. |
| 26 | + |
| 27 | +The primary agent is the orchestrator and final integration authority. It owns decomposition, dependency order, agent selection, shared contracts, scope assignment, integration, contradiction resolution, final validation, and the user-facing answer. |
| 28 | + |
| 29 | +## Orient before delegating |
| 30 | + |
| 31 | +Before spawning, understand enough of the task and repository to choose rational boundaries. Proportionately inspect the applicable instructions, repository topology, relevant modules, execution paths, dependencies, APIs, schemas, data models, invariants, tests, build/runtime boundaries, shared contracts, likely integration points, ownership boundaries, and file overlap. |
| 32 | + |
| 33 | +Do not turn this into an exhaustive repository audit for a small task. Follow any project-specific orientation or retrieval policy first. A tool-produced map is an orientation aid, not a substitute for current source and tests. |
| 34 | + |
| 35 | +## Require a concrete benefit |
| 36 | + |
| 37 | +Delegate only when at least one benefit outweighs coordination cost: |
| 38 | + |
| 39 | +- genuine parallelism between independent workstreams; |
| 40 | +- bounded-context isolation for a self-contained subsystem or investigation; |
| 41 | +- specialization in tools, permissions, model capability, or domain knowledge; |
| 42 | +- context offloading for large logs, documentation, searches, or test output; |
| 43 | +- independent verification that can challenge assumptions or review completed work. |
| 44 | + |
| 45 | +Keep work in the primary context when it is tiny, sequential, tightly coupled, poorly bounded, concentrated on the same files, dependent on the same full context, or cheaper to perform directly. A trivial edit, one-file mechanical change, or equally small verification is a no-delegation default even when the user says "use subagents where appropriate." Independent verification warrants an agent only when risk, ambiguity, or review scope makes a second context materially valuable; never manufacture a reviewer subtask for a trivial change. |
| 46 | + |
| 47 | +Do not create agents for artificial roles, one per file, or merely because agents are available. |
| 48 | + |
| 49 | +Choose the smallest useful number of agents from the task structure. Optimize for useful concurrency with minimum coordination cost. |
| 50 | + |
| 51 | +## Shape the work safely |
| 52 | + |
| 53 | +Read-heavy work is the safest default for parallel delegation. Prefer a platform's built-in read-only or Explore role for architecture mapping, dependency tracing, documentation research, test inventory, log analysis, risk analysis, and review. |
| 54 | + |
| 55 | +For write-heavy work, establish non-overlapping ownership before concurrent edits: |
| 56 | + |
| 57 | +```text |
| 58 | +Agent A -> bounded module or file set A |
| 59 | +Agent B -> bounded module or file set B |
| 60 | +Primary -> shared contracts and integration |
| 61 | +``` |
| 62 | + |
| 63 | +Do not assign concurrent writers to the same file or tightly coupled implementation surface unless a deliberate isolation-and-merge mechanism makes that safe. Shared APIs, schemas, types, database contracts, central configuration, abstractions, and package boundaries are normally owned by the primary agent, completed before dependent work, or assigned to one clearly designated owner. |
| 64 | + |
| 65 | +Use dependency-aware waves when useful: orient; parallel read-only research; synthesize and settle shared contracts; run disjoint implementation; independently verify; integrate and validate. Skip phases that add no value. |
| 66 | + |
| 67 | +## Dispatch deliberately |
| 68 | + |
| 69 | +Before the first spawn, read [references/delegation-contract.md](references/delegation-contract.md) and the matching section of [references/platform-adapters.md](references/platform-adapters.md). Give each worker a bounded, self-contained assignment rather than the full parent conversation. |
| 70 | + |
| 71 | +Use root-to-child delegation by default. A child must not spawn further agents unless the user explicitly requests nested delegation and the primary agent has identified a concrete, bounded architectural benefit. Respect a platform that forbids nested agents. |
| 72 | + |
| 73 | +Do not hardcode model names. When the platform permits role allocation, map the work to capability classes such as fast explorer, general worker, or deep reviewer. Preserve the strongest reasoning in the primary agent when global synthesis is the hard part. |
| 74 | + |
| 75 | +While children run, continue meaningful non-overlapping primary work. Wait only when a child result is required for the next critical decision; do not busy-poll. Stop or redirect work that becomes redundant, unsafe, or out of scope. |
| 76 | + |
| 77 | +## Integrate, do not merely collect |
| 78 | + |
| 79 | +Treat child reports as evidence, not truth. Inspect important claims against source, diffs, tests, logs, or runtime behavior. Resolve contradictions and integration gaps centrally. Review combined changes for contract drift and overlapping assumptions, then run final validation in the primary context. |
| 80 | + |
| 81 | +Prevent blind fan-out, duplicate exploration, overlapping ownership, premature implementation, context starvation, context dumping, agent proliferation, delegation recursion, and integration debt. Successful child completion is not successful task completion. |
0 commit comments