Local Developer Workflow
From ticket to merged PR -- the interactive development workflow using /dx-* skills in your IDE. Works with ADO and Jira.
How It Works
Instead of writing complex prompts, you run skills — short commands like /dx-req or /dx-plan.
Each skill already knows what context to gather (tickets, codebase, config, prior specs — not just source code),
which subagents to spawn for parallel work, and what output format to produce.
Once a skill finishes, all context stays in the session. You can refine results with simple follow-up prompts (“make step 3 more granular”, “skip the SCSS changes”) — no need to re-explain the project, the ticket, or your conventions.
This is the key advantage: precision without repetition. Each step saves its output to local files, so even if a session ends, the next skill picks up where you left off.
First Time?
Before running skills, make sure your project is set up with /dx-init.
This generates .ai/config.yaml with your build commands, branch names, ADO/Jira settings, and coding conventions —
so every skill uses the right context from the start.
See the Setup Guide for full instructions.
Choose Your Entry Point
Don't memorize 76 skills. Pick the one that matches where you are right now.
/dx-req <id>Fetches ticket, validates, researches codebase
/dx-planReads existing specs, generates impl plan
/dx-step-allExecutes plan steps with auto-fix
/dx-prCommits, pushes, creates PR
/dx-agent-all <id>Full pipeline: req through PR
/dx-step-verifythen /dx-pr — verify and submit
/dx-bug-all <id>Triage, fix, verify, PR
The Full Pipeline
One command runs the entire sprint lifecycle. Or use individual skills for just the phase you need.
/dx-agent-all <ID or JIRA-KEY> One command runs the entire sprint lifecycle. Or use individual skills for just the phase you need.
/dx-req-* /dx-ticket-analyze /dx-figma-* /dx-plan /dx-step-* /dx-step-verify /dx-pr-commit /dx-pr /aem-editorial-guide /dx-doc-gen /aem-qa-handoff Requirements
Pull the work item (ADO or Jira), validate readiness, distill requirements, research codebase, and share with the team.
/dx-req <ID or JIRA-KEY> /dx-req /dx-req
Full requirements pipeline in one skill: fetches the work item (ADO or Jira), validates DoR, distills developer requirements, researches the codebase, and generates a team summary. Produces raw-story.md, dor-report.md, explain.md, research.md, and share-plan.md.
/dx-req
Coordinator that invokes /dx-req. Use this for the full orchestrated pipeline with run logging and metrics.
Output
5 documents in .ai/specs/<id>-<slug>/. Each skill is idempotent —
it checks if its output already exists before regenerating, so you can re-run safely.
Planning
A structured, validated implementation plan with dependency tracking and risk resolution.
/dx-plan /dx-plan-validate /dx-plan-resolve /dx-plan
Uses the Opus model with extended thinking for deep reasoning. Produces a step-by-step implementation plan where each step has: description, files to modify, dependencies, verification criteria, and status.
/dx-plan-validate
Cross-checks the plan against requirements. Every requirement covered? No extras? Dependencies correct? Flags risks and gaps for resolution.
/dx-plan-resolve
Fixes flagged risks by researching the codebase. Resolves ambiguities, fills gaps, and updates the plan. Loops with validate until the plan passes.
Plan Structure
Each step in implement.md includes: description, files to modify, dependencies on other steps,
verification criteria to confirm success, and a status field (pending to done).
Execution
Execute plan steps with a test, review, commit loop. Self-healing on failure.
/dx-step-all /dx-step <n> /dx-step-fix /dx-step-fix
Single targeted fix. When a test or review fails, this skill applies a focused correction to the specific problem. If the same fix fails twice, it escalates to heal.
/dx-step-fix (escalation)
Root cause analysis. When targeted fixes fail repeatedly, dx-step-fix escalates to root cause analysis, potentially restructuring the approach and creating new corrective steps in the plan.
Fix Memory
Every fix is logged to fixes.jsonl. When a fix pattern succeeds 3+ times, it is promoted
to a permanent rule — the system learns from its own mistakes.
Build & Verify
Compile, deploy, and run a 6-phase verification gate before proceeding to PR.
/dx-step-build /dx-step-verify /dx-step-build
Compile and deploy the project. Automatically detects build failures and applies up to 6 auto-fix attempts before stopping.
/dx-step-verify
Runs 6 verification phases in sequence. Each phase can auto-fix and retry. The code review phase uses Opus for high-confidence analysis.
| Phase | What | Fail Action |
|---|---|---|
| Compile | config.build.command | Auto-fix, retry |
| Lint | config.lint.command | Auto-fix, retry |
| Test | config.test.command | Auto-fix, retry |
| Secret Scan | Pattern match (keys, tokens, passwords) | Immediate fix |
| Architecture | Convention check (naming, structure, patterns) | Log warning |
| Code Review | dx-code-reviewer (Opus model) | Fix, rebuild, re-review |
Review-Fix Loop
The code review phase runs up to 3 cycles of review, fix, rebuild, re-review. If issues
persist after 3 cycles, it escalates to /dx-step-fix for root cause analysis. If that also fails, the pipeline
stops and asks for human input.
Accessibility & Quality Gates
WCAG compliance testing, Definition of Done validation, and estimation -- standalone skills that complement the build pipeline.
/dx-axe
Runs axe accessibility analysis on a URL via the axe MCP server (Docker). Detects WCAG violations, generates remediation suggestions, and can auto-fix common issues like missing alt text and ARIA attributes.
Definition of Done
/dx-req-dod validates your work against the story’s acceptance criteria, posts
a checklist to ADO, and auto-fixes failing items where possible.
/dx-estimate
Analyzes a story and produces structured estimation: hours per task, story points, affected AEM pages, and complexity breakdown. Useful for sprint planning.
PR, AEM Verification, Docs & QA Handoff
Commit, verify on AEM, create the PR, capture demo, generate documentation, and post testing steps for QA.
/dx-pr-commit /dx-pr /aem-editorial-guide /dx-doc-gen /aem-qa-handoff Pull Request
Creates a PR from share-plan.md with auto-generated description, linked
work item (ADO or Jira), and branch management.
AEM Verification
Takes a before/after snapshot of AEM pages, verifies component rendering, and captures a demo with browser automation.
Documentation
/dx-doc-gen generates wiki pages from spec files. /dx-doc-retro generates
docs retroactively from a work item + linked PRs — no spec files needed. Posts to ADO Wiki or Confluence.
QA Handoff
Generates structured testing steps and posts them as an ADO comment for the QA team.
Reuses /aem-doc-gen output (lightweight) or creates its own test page (full mode).
Run after /aem-doc-gen for best results.
Pick What You Need
You don't have to run the full pipeline. Use individual skills for just the phase you need.
| Command | Phase | What It Does |
|---|---|---|
/dx-req <id> | Requirements | Full requirements pipeline (fetch, DoR, explain, research, share) |
/dx-req-import | Requirements | Validate external requirements (non-ADO/Jira), generate explain.md |
/dx-req-tasks | Requirements | Create child Task work items under a story with hour estimates |
/dx-req-dod | Quality | Validate work against acceptance criteria, post checklist to ADO/Jira |
/dx-estimate | Planning | Structured estimation: hours, story points, complexity |
/dx-ticket-analyze <id> | Enrichment | Work item (ADO/Jira) to components, files, pages |
/dx-plan | Planning | Generate implementation plan |
/dx-plan-validate | Planning | Validate plan against requirements |
/dx-step-all | Execution | Execute all pending plan steps |
/dx-step <n> | Execution | Execute a single plan step |
/dx-step-build | Build | Compile and deploy with auto-fix |
/dx-step-verify | Build | 6-phase verification gate |
/dx-pr | PR | Create pull request |
/dx-pr-commit | PR | Stage, commit, and push changes |
/dx-pr-review-all | PR | Batch review multiple PRs |
/dx-pr-review-report | PR | Generate categorized report from review, post to wiki |
/dx-axe | Accessibility | WCAG compliance check + auto-remediation via axe MCP |
/dx-doc-gen | Docs | Generate wiki + authoring guide |
/dx-doc-retro | Docs | Retroactive docs from ADO story + linked PRs (no spec files) |
/aem-qa-handoff | QA Handoff | Generate testing steps, post to ADO for QA team (uses /aem-doc-gen output) |
Spec Directory
Every ticket gets a dedicated directory with all generated artifacts.
/dx-req/dx-req/dx-req/dx-req/dx-req/dx-plan/dx-figma-prototype/dx-req-dod/aem-snapshot/aem-verify/aem-qa-handoff/aem-editorial-guide/dx-doc-genPR Workflow
Three independent lifecycles that cover every aspect of pull request management.
Creating PRs
Generate the PR from your spec files with a structured description, linked work item, and proper branch setup.
Reviewing Others' PRs
Structured AI code review on a teammate’s PR — architecture, correctness, accessibility, performance. Posts structured comments with inline code patches that can be applied directly.
Handling Feedback
When reviewers leave comments on your PR, AI reads them, applies fixes, and posts replies — resolving feedback in minutes instead of days.
Applying Patches
Review comments include ready-to-apply code patches. Run /dx-pr-apply to apply
all suggested patches from a PR review, build, verify, and commit in one step.
Batch Review & Reports
/dx-pr-review-all reviews multiple PRs in batch. /dx-pr-review-report generates
a categorized report from reviews and posts it to ADO Wiki or Confluence. Ideal for tech leads and sprint reviews.