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 75+ 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.