Skip to content

Docs Tutorial

Tutorial: Your First Pipeline

In this tutorial you will install ASDT, ask a specialist one question about a repo you already have, and only then run a complete PM → Architect → Developer delivery for a concrete feature: adding a contact form with validation.

ASDT works with two AI assistants — Claude Code and OpenCode. The steps below are identical for both; wherever they differ (config location, restart, auth) both are shown side by side. Pick whichever you use.

Estimated time: 15 minutes.

  1. Install
  2. Initialize
  3. Recommendation
  4. PM
  5. Architect
  6. Developer

Prerequisites

Before starting, make sure you have:

  • Claude Code or OpenCode installed and authenticated. If your session has expired, re-authenticate through your assistant’s login flow (claude for Claude Code, opencode for OpenCode).
  • Engram running as an MCP server, wired into your assistant’s MCP configuration. See Memory & Engram for setup.
  • A bash or zsh terminal.

Step 1 — Install ASDT

Run the install script:

curl -fsSL https://raw.githubusercontent.com/vitualizz/asdt/main/install.sh | bash

The binary is placed at ~/.local/bin/asdt-tui. If your shell doesn’t find it, add this to your shell profile:

export PATH="$HOME/.local/bin:$PATH"

Then install the specialist skills into your assistant:

asdt-tui

This interactive menu lets you pick your assistant(s) and copies the skill files in. It installs into:

  • Claude Code → ~/.claude/skills (executor agents in ~/.claude/agents/)
  • OpenCode → ~/.config/opencode/skills (executor agents in ~/.config/opencode/agents/, plus command wrappers in ~/.config/opencode/commands/)

Then restart your assistant — both Claude Code and OpenCode load skill (and command) definitions on startup.

If asdt-tui shows command not found, see Troubleshooting.

Step 2 — Initialize ASDT in your project

Open your assistant (Claude Code or OpenCode) in your project directory and run:

/asdt-init

This creates .asdt/config.yaml (memory provider settings) and .asdt/knowledge/platform.yaml (detected stack), so every specialist tailors its output to your project.

Step 3 — Ask a specialist something

Before building anything, try the shortest path in. Point a specialist at code you already have:

/asdt-security "audit how we handle sessions"

It reads the relevant code, tells you what it found in plain prose, and keeps the findings so anything you run later over that area starts already knowing them. Nothing was planned, nothing was routed — one question, one answer.

Every specialist works this way. /asdt-architect "does this structure scale?", /asdt-qa "what don't our tests cover?". That is the whole of it, and for many days it is all you need.

The rest of this tutorial is the other half: handing the team something to build.

Step 4 — Ask ASDT for a pipeline recommendation

In your assistant, run:

/asdt "Add a contact form with validation"

ASDT analyzes your request and recommends which specialists to involve and in what order.

# Example output — your results will vary based on your project

Analyzing: "Add a contact form with validation"

Recommended pipeline:
  1. /asdt-pm        → Define scope and acceptance criteria
  2. /asdt-architect → Design validation approach and API contract
  3. /asdt-developer → Implement the form handler and validation logic

Run each command in order. Each specialist reads the previous one's output automatically.

Step 5 — Run the Product Manager

/asdt-pm "Add a contact form with validation"

PM locks scope, writes user stories, and saves a pm/handoff artifact to the knowledge base (see Memory & Engram).

# Example output — your results will vary based on your project

Running PM specialist...

Produced: pm/handoff

  Feature: Contact form with validation
  
  User stories:
    US-01: As a visitor, I want to submit a contact form so that I can reach the team.
      AC1: Form fields: name (required), email (required, valid format), message (required, max 500 chars).
      AC2: Submission shows a success message and sends an email notification.
      AC3: Invalid fields show inline error messages without losing existing input.
    
    US-02: As a visitor, I want the form to prevent submission if my email is invalid
      so that I don't have to wait for a bounce to know something went wrong.
      AC1: Email field validates format on blur and on submit.
      AC2: Submit button is disabled while validation errors exist.

  In scope: form UI, client-side validation, form submission handler, email notification.
  Out of scope: CAPTCHA, rate limiting, analytics tracking.

Artifact saved to knowledge base.

Step 6 — Run the Architect

/asdt-architect

Architect reads the PM backlog entry automatically, evaluates technical approaches, and produces an Architecture Decision Record (ADR) and system design.

# Example output — your results will vary based on your project

Running Architect specialist...
Loading: pm/handoff ✓

Produced: architectural-decision + system-design

  ADR: Use native HTML5 Constraint Validation API with progressive enhancement
  
  Decision: Use the browser's native Constraint Validation API for field validation,
  augmented with a thin JS layer for custom error messages and blur-event handling.
  
  Alternatives considered:
    - Zod schema validation (rejected: over-engineered for a contact form)
    - React Hook Form (rejected: introduces unnecessary dependency)
  
  System design:
    - POST /api/contact — accepts { name, email, message }, returns 200 or 422
    - Email notification via nodemailer (existing dep)
    - No database write — form data forwarded directly to email

Artifacts saved to knowledge base.

Step 7 — Run the Developer

/asdt-developer

Developer reads the ADR and system design, breaks work into ordered tasks, and produces an implementation plan (or writes code in writing mode).

# Example output — your results will vary based on your project

Running Developer specialist...
Loading: architectural-decision ✓
Loading: system-design ✓

Produced: developer/dev-implementation

  Implementation plan:

  T-01  Create src/components/ContactForm.astro
        — Form markup with native constraint validation attributes
        
  T-02  Create src/pages/api/contact.ts
        — POST handler: validate, send email via nodemailer, return 200/422
        
  T-03  Create src/styles/contact-form.css
        — Error state styles for invalid fields
        
  T-04  Update src/pages/contact.astro
        — Import and render ContactForm component

Artifact saved to knowledge base.

What’s next

Your pipeline is complete. From here you can:

  • Run QA (/asdt-qa) to validate acceptance criteria coverage and generate a test plan.
  • Run Security (/asdt-security) to review the form handler for OWASP vulnerabilities.
  • Browse Recipes for command sequences for other common scenarios.
  • See Troubleshooting if anything went wrong.