dx-core

Plugin dx-core from marketplace dx-aem-flow in easingthemes/dx-aem-flow. Commands read from the repo's manifest — 3 days ago.

Skills (49)

• dx-adapt

  Auto-detect project type, structure, build commands, and AEM values. Updates .ai/config.yaml with project profile and substitutes real values into installed .claude/rules/. Run after /dx-init and /aem-init. Re-run anytime to refresh detected values.

• dx-agent-all

  Full pipeline from ADO story to code and PR — requirements, plan, execution, build, review, commit, PR — with optional review checkpoints. Use for 'implement this story', 'do the whole story'.

• dx-agent-dev

  Dev Agent: implement code from an RE spec — implement, self-check (build/test/lint), fix failures, commit. Use for 'dev agent', 'implement from spec'.

• dx-agent-re

  RE Agent: analyze an ADO/Jira User Story into a structured requirements spec with task breakdown, and post a summary comment. Use for 're agent', 'requirements agent'.

• dx-axe

  Accessibility-test a URL with the axe MCP server — find WCAG violations, get remediation, apply fixes, re-verify. Use for 'a11y audit', 'check accessibility'.

• dx-bug-all

  Full bug workflow in one command for an ADO Bug — triage, reproduce in the browser, fix, PR. Use for 'fix bug <id>'. Not for a single phase (dx-bug-triage, dx-bug-verify, dx-bug-fix).

• dx-bug-fix

  Plan, implement, test and open a PR for a bug fix from triage.md / verification.md. Use after /dx-bug-triage or /dx-bug-verify. Not before triage exists, not for the whole workflow (dx-bug-all) or reproduction (dx-bug-verify).

• dx-bug-triage

  Fetch a Bug from ADO/Jira, find the affected component, write raw-bug.md and triage.md with a root-cause hypothesis. Use to start a bug ticket. Not for reproducing (dx-bug-verify), fixing (dx-bug-fix) or the whole flow (dx-bug-all).

• dx-bug-verify

  Reproduce a bug in the browser (Playwright) — follow repro steps, screenshot, confirm; modes before (default), after (post-fix), qa. Not for fetching the ticket (dx-bug-triage), fixing (dx-bug-fix) or story QA on AEM (aem-qa).

• dx-council

  Put a question, decision or artifact to a council of 3 AI advisors who analyze it, peer-review each other and give a verdict. Use for 'council this', 'pressure-test this', 'debate this', or a real trade-off. Not for yes/no or factual questions.

• dx-doc-gen

  Generate wiki docs from completed spec files — decisions, usage, API changes — and post to ADO Wiki or Confluence. Final step after implementation; used by /dx-agent-all Phase 7 and /dx-req-dod. For a done story without spec files, the user runs /dx-doc-retro.

• dx-doc-retro

  Generate technical documentation retroactively for completed stories — fetches ADO story, finds linked PRs, searches codebase, and produces wiki-ready docs without needing spec files. Posts to ADO Wiki or Confluence depending on provider config. Use when documentation was never generated during deve

• dx-doctor

  Check health of the dx workflow files — config, rules, scripts, seed data, MCP, settings — for each installed plugin. Use after upgrading plugins or when something seems broken.

• dx-dor

  Validate a story's Definition of Ready — fetch the wiki checklist, evaluate, post an ADO comment. Use at sprint start ('check DoR', 'is this story ready'), in batch, or via /dx-req.

• dx-eject

  Eject all plugin assets into the consumer repo — copies skills, agents, rules, templates, shared files, hooks, and MCP config so the project works without plugins installed. Use when a team wants to own all dx files locally instead of depending on plugins.

• dx-estimate

  Analyze an Azure DevOps/Jira User Story and produce a structured estimation — understanding, implementation plan, recommended hours/SP, AEM pages affected, and open questions. Posts result as an ADO/Jira comment. Use when you want an AI-generated estimation for a story.

• dx-figma-all

  Full Figma design-to-code flow in one command — extract, prototype, verify. Use when a story has a Figma URL: 'figma all', 'turn this figma into code'.

• dx-figma-extract

  Extract design context, tokens and screenshots from a Figma URL into figma-extract.md. Use after requirements when the story has a Figma URL. Not for general Figma browsing or without a spec directory.

• dx-figma-prototype

  Generate a standalone HTML/CSS prototype from figma-extract.md, following project conventions. Use after /dx-figma-extract. Not without figma-extract.md or for non-design tasks.

• dx-figma-verify

  Compare a generated prototype with the Figma reference screenshot in a browser, fix gaps, write a report. Use after /dx-figma-prototype. Not for components on AEM (aem-fe-verify) or pre-PR checks (dx-step-verify).

• dx-help

  Answer questions about the project's architecture, components, patterns and dx workflow — 'how does X work?', 'where do I find Z?'. Not for a specific ticket or a component's files.

• dx-init

  Set up the dx workflow for a new project. Detects your environment, asks a few questions, and generates .ai/config.yaml plus supporting files. Run this first before using any other dx skill.

• dx-pattern-extract

  Scan completed tickets for recurring patterns and promote to cross-ticket knowledge. Run periodically or after completing several tickets. Creates .ai/graph/nodes/patterns/ entries.

• dx-plan-resolve

  Resolve risks flagged by /dx-plan-validate — research the codebase and update implement.md steps with concrete fixes. Use for 'resolve plan issues', 'fix plan risks'.

• dx-plan-validate

  Cross-check implement.md against the requirements — every requirement covered, nothing unrequested, dependencies in order. Use for 'validate plan', 'check the plan', between /dx-plan and /dx-step.

• dx-plan

  Generate implement.md, a plan with status-tracked steps, from explain.md and research.md. Use after requirements are ready ('plan this story').

• dx-pr-answer

  Answer open comments on your PRs in the configured SCM (only ado is implemented) — draft and post replies, apply reviewer patches. Not for reviewing a PR (dx-pr-review) or creating/pushing one (dx-pr, dx-pr-commit).

• dx-pr-commit

  Commit changes (work item ID in the message, rebase onto base) and optionally open a PR in the configured SCM (only ado is implemented). Use for 'commit', 'push', 'open PR', 'create PR'. Not for reviews (dx-pr-review) or replies (dx-pr-answer); the end-of-plan PR is dx-pr.

• dx-pr-review-all

  Review multiple Azure DevOps pull requests in batch. Use when reviewing several PRs at once or checking active PRs for a repo.

• dx-pr-review-report

  Write a categorized report of an existing PR review (bug, a11y, regression, …) with patch status, posted to ADO Wiki or Confluence. Not for doing the review (dx-pr-review) or many reviews at once (/dx-pr-reviews-report).

• dx-pr-review

  Review a pull request by ID or URL in the configured SCM (only scm.provider ado is implemented) — analyze the diff, report findings, optionally post comments. Not for a local diff, creating a PR (dx-pr, dx-pr-commit), answering comments (dx-pr-answer) or a review write-up (dx-pr-review-report).

• dx-pr-reviews-report

  Generate categorized reports for multiple PR reviews — lists reviewed PRs, generates a report for each, and posts all to ADO Wiki or Confluence. Use when you want to document all recent PR reviews, mentions "report reviews", or wants batch PR review reports.

• dx-pr

  Create the PR when all plan steps are done — write the description from share-plan.md, push, open it in the configured SCM (only scm.provider ado is implemented). Not for staging or committing (dx-pr-commit), reviews (dx-pr-review) or replies (dx-pr-answer).

• dx-req-dod

  Check Definition of Done and auto-fix gaps — PR, tasks, docs — then post a summary to ADO. Use for 'check DoD'. Not for fetching requirements (dx-req), child Tasks (dx-req-tasks) or pre-PR checks (dx-step-verify).

• dx-req-import

  Validate external requirements and create spec structure without ADO. Reads a requirements document, checks completeness, and generates explain.md + optional research.md. Use when you have requirements from a BA, Confluence page, or email instead of an ADO ticket.

• dx-req-tasks

  Create or close child Tasks under an ADO/Jira User Story — FE/BE/Authoring with hour estimates; 'close' closes them after development. Not for requirements (dx-req) or DoD (dx-req-dod).

• dx-req

  Start any ticket — fetch the ADO/Jira story, check DoR, distill requirements, research the codebase, write a team summary. Not for requirements from a file (/dx-req-import), child Tasks (dx-req-tasks) or DoD (dx-req-dod).

• dx-scan

  Deep project scan — discover conventions from actual code, customize rule files with real values, and generate seed data. Interactive. Run after /dx-init + /dx-adapt + /aem-init. Use when setting up a new project or when project structure changes significantly.

• dx-security

  Security audit — OWASP Top 10, secrets scan, dependency audit, input validation, auth review. Use before a PR or when code handles user input, auth or external integrations.

• dx-simple

  Apply a small AEM change (a11y label, color, spacing, copy, CSS class, icon, focus trap) via authoring (JCR) or code (PR) paths, read from the ADO story. Use for 'simple change', 'small tweak', '@kai-simple'.

• dx-simplify

  Simplify working code without changing its behavior — Chesterton's Fence, Rule of 500. Use for 'simplify', 'reduce complexity', 'refactor for clarity'.

• dx-step-all

  Run every plan step hands-free (implement, test, review, commit), with step-fix on failures; stops after 2 failed fixes on one step. Use for 'execute plan', 'run all steps'.

• dx-step-build

  Build and deploy to the local dev environment, fixing errors until the build passes. Use after code changes ('build', 'compile', 'build and deploy').

• dx-step-fix

  Diagnose and fix a blocked step — compile error, test failure, review rejection — directly or by adding corrective steps to implement.md. Use when /dx-step fails.

• dx-step-verify

  6-phase pre-PR verification with auto-fix — compile, lint, test, secrets, architecture, code review (max 3 cycles). Use after /dx-step-build. Not for checks on a running AEM (aem-verify, aem-fe-verify, aem-qa) or existing PRs (dx-pr-review).

• dx-step

  Execute the next pending step in implement.md — implement, test, review, commit, update status. Use to go one step at a time ('next step').

• dx-sync

  Sync plugin updates to consumer repos — runs sync-consumers.sh with selected repos and options. Use when you say "sync plugins", "update consumers", "push to all repos".

• dx-ticket-analyze

  Research an ADO/Jira ticket and list the source files and assets it involves. Use for 'analyze ticket', 'what files does this touch?', 'find files for this story'.

• dx-upgrade

  Upgrade a consumer project to the installed plugin versions — run dx-doctor, fix stale and missing files, list manual actions. Use after upgrading plugins.

Subagents (7)

• dx-code-reviewer

  Senior code reviewer. Reviews code changes against plans, project conventions, and production readiness. Uses confidence-based filtering (>=80) to report only issues that truly matter. Use for full-diff reviews before merging.

• dx-doc-searcher

  Searches .ai/ index and reference files to look up components, architecture patterns, and feature context. Avoids expensive MCP calls. Used by dx-help, dx-ticket-analyze, and component lookup skills.

• dx-figma-components

  Analyzes Figma extraction to identify UI building blocks (buttons, images, cards, forms, etc.) and searches the codebase for existing components that can be reused. Used by dx-figma-prototype.

• dx-figma-markup

  Discovers HTML and accessibility conventions from the consumer project — semantic patterns, component structure, ARIA usage, keyboard handling. Used by dx-figma-prototype.

• dx-figma-styles

  Discovers CSS/SCSS conventions from the consumer project — variables, breakpoints, typography, spacing, theming, naming patterns. Used by dx-figma-prototype.

• dx-file-resolver

  Resolves all source files for a component or module across project repos. Returns file paths as clickable ADO URLs. Used by dx-ticket-analyze and component lookup skills.

• dx-pr-reviewer

  Reviews a single ADO pull request — fetches diff, loads project conventions, analyzes code changes, and returns structured findings with severity and line-level comments. Does NOT post to ADO — returns findings for user approval. Used by review and reviews skills.

MCP servers (2)

• axe-mcp-server

  runs: npx -y axe-mcp-server

• figma

  connects to: http://127.0.0.1:3845/mcp

Hooks (10)

• SessionStart

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/session-start.sh"

• SessionStart

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/context-loader.sh"

• SessionStart

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/next-step.sh"

• PreToolUse

  bash -c 'grep -q "git commit" || exit 0; BRANCH=$(git branch --show-current 2>/dev/null); if [ "$BRANCH" = "main" ] || [ "$BRANCH" = "master" ] || [ "$BRANCH" = "development" ] || [ "$BRANCH" = "devel

• Stop

  [ -f "$CLAUDE_PROJECT_DIR/.claude/hooks/stop-guard.sh" ] && bash "$CLAUDE_PROJECT_DIR/.claude/hooks/stop-guard.sh" || true

• PostToolUse

  [ -f "$CLAUDE_PROJECT_DIR/.ai/lib/figma-screenshot-hook.sh" ] && bash "$CLAUDE_PROJECT_DIR/.ai/lib/figma-screenshot-hook.sh" || true

• PostToolUse

  [ -f "$CLAUDE_PROJECT_DIR/.ai/lib/figma-screenshot-hook.sh" ] && bash "$CLAUDE_PROJECT_DIR/.ai/lib/figma-screenshot-hook.sh" || true

• PostToolUse

  f="$(sed -n 's/.*"file_path" *: *"\([^"]*\)".*/\1/p' | head -1)"; if [ -n "$f" ]; then bash "${CLAUDE_PLUGIN_ROOT}/data/lib/validate-plugin-edit.sh" "$f"; fi

• PostToolUse

  mkdir -p "$CLAUDE_PROJECT_DIR/.claude" && echo "[$(date '+%H:%M:%S')] Subagent completed" >> "$CLAUDE_PROJECT_DIR/.claude/subagent-log.txt" || true

• PostToolUse

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/compaction-reminder.sh"

Similar plugins