Docs / How It Works

How It Works

The execution model

ASDT gives you structure without removing control. When you run a specialist, it orchestrates a focused sequence of steps — each one producing a single artifact, each one reading only what the previous step produced.

You invoke the specialists. ASDT never runs them automatically. That is intentional: every step where a human confirms a plan is a step where wrong assumptions get caught before they compound.

The /asdt advisor analyzes your request and suggests which specialists to involve and in what order. You confirm the plan, then run each command yourself.

Knowledge flows forward automatically

Every specialist step produces one artifact — a structured document saved to the knowledge base with a stable key. The next specialist retrieves it by key. No manual context-passing. No copy-pasting between commands.

This means:

• Specialists are decoupled. The Developer reads the Architect’s decision record as a document — not a shared variable, not a file import.
• Artifacts survive sessions. Run PM on Monday, continue with Architect on Thursday. The knowledge base holds the context.
• Missing inputs degrade gracefully. If an artifact is missing, the next specialist notes it in a running list of gaps called open_items and proceeds with whatever is available.

Specialists adapt to complexity

Every specialist runs the right depth of steps for the complexity of the request. A quick bugfix runs fewer steps than a new authentication system. The overview below shows the full step sequence at moderate complexity:

• Researcher

  Frame the problem, diverge into candidate directions, judge feasibility with evidence, converge on one recommendation

  knowledge-recalldiscovery
• PM

  Turn the request into user stories in delivery order, explicit scope, measurable NFRs and acceptance criteria

  knowledge-recallbacklog
• UX/UI

  Turn the requirement into user flows mapped to existing components, with the accessibility each one owes

  knowledge-recallplatform-analysisux-spec
• Architect

  Decide the approach against its alternatives, then design the data model and API surface that follow

  knowledge-recallplatform-analysisdesign
• Developer

  Write the code — and its tests under strict TDD — within the edit roots the spec declared

  knowledge-recallexplorespecimplement
• Security

  Turn the assessment into prioritized findings with concrete mitigations and an actionable checklist

  knowledge-recallplatform-analysisassessharden
• QA

  Find the gaps and edge cases the acceptance criteria missed, turn them into test cases, and give a go/no-go verdict

  knowledge-recalltest-plan

Steps run as isolated sub-agents (separate single-task AI runs that don’t see each other’s reasoning) — they don’t share context with each other, which prevents earlier reasoning from leaking into later steps. Each step reads only its declared inputs, writes one artifact, and hands off.

The human is always in the loop

ASDT enforces a soft gate at two points:

1. After /asdt — the pipeline advisor presents a routing plan and waits for confirmation before telling you which commands to run.
2. Between specialists — you choose when to run the next one. Nothing is automated.

This isn’t a limitation. It’s the design. AI-generated architecture decisions benefit from human review before a developer acts on them. QA plans benefit from human review before they define what “done” means. ASDT gives you the structure; you apply the judgment.