[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H47W1CABRCY25G27FC3824":3,"skill-same:01M6H47W1CABRCY25G27FC3824":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6H47W1CABRCY25G27FC3824","dx-step",null,"Execute the next pending step in implement.md — implement, test, review, commit, update status. Use to go one step at a time ('next step').","easingthemes\u002Fdx-aem-flow","easingthemes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2750284?v=4","01M6H3XYGJY8QCX9ES36P2WF4H","Dragan Filipović","01M6H3XYMN1XVSGKN7N79SW3RH",7,"MIT","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-core\u002Fskills\u002Fdx-step\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"dx step","dx","id","implement","use","next step","sonnet","go","status","edit","write","read","at","update","next","work","review","commit","search","time","2026-11-10 10:12:30",false,"---\nname: dx-step\ndescription: \"Execute the next pending step in implement.md — implement, test, review, commit, update status. Use to go one step at a time ('next step').\"\nargument-hint: \"[Work Item ID or slug (optional — uses most recent if omitted)]\"\nmodel: sonnet\ncontext: fork\nallowed-tools: [\"read\", \"edit\", \"search\", \"write\", \"agent\", \"AEM\u002F*\"]\n---\n\n**Isolation check.** This skill is meant to run in its own context (`context: fork`). If you can see the user's messages from before this skill was invoked, you are running inline (Copilot CLI ignores `context: fork`): do not run the steps below yourself. Start one subagent with your task\u002Fsubagent tool, give it only this instruction — \"Invoke the dx-core:dx-step skill with these arguments: \u003Cthe arguments you were given, or none>. Run it fully and reply with its final report only.\" — then show the user that report and stop. If you cannot see earlier user messages, or your only earlier message is that instruction to invoke dx-core:dx-step (you are a fork or that subagent), continue below.\n\nYou execute the next pending step from implement.md — implement the changes, verify compilation, run tests, review against plan and conventions, commit, and mark the step done.\n\nYou run forked (`context: fork`): coordinators (`dx-step-all`, `dx-bug-fix`) call you once per step and read only your final `## Return` block. Before printing anything user-facing, check whether a step loop is driving you (see `plugins\u002Fdx-core\u002Fshared\u002Forchestration-check.md` § Step-loop marker):\n\n```bash\nIN_STEP_LOOP=0\nLOOP_FLAG=\".ai\u002Frun-context\u002Fstep-loop.flag\"\nif [ -f \"$LOOP_FLAG\" ]; then\n  AGE=$(( $(date +%s) - $(date -r \"$LOOP_FLAG\" +%s) ))\n  [ \"$AGE\" -lt 7200 ] && IN_STEP_LOOP=1\nfi\n```\n\nYou are the worker for **one** step. Never invoke `Skill(dx-step)` or `\u002Fdx-step-all` yourself. The loop belongs to the coordinator.\n\n`$IN_STEP_LOOP == 1` only suppresses the \"run X next\" hints addressed to a human — it never changes what the step does.\n\n## Progress Tracking\n\nFollow `.ai\u002Frules\u002Ftask-progress.md` (plugin default: `rules\u002Ftask-progress.md`). The progress **file** is the source of truth — write it at every step transition:\n\n```bash\nDX_PROGRESS_FILE=\"dev-all-progress.md\" DX_PROGRESS_TITLE=\"Pipeline Progress\" \\\n  bash \"${CLAUDE_PLUGIN_ROOT}\u002Fshared\u002Fupdate-progress.sh\" \"$SPEC_DIR\" \"\u003Cn>: \u003Ctitle>\" \"\u003Cstatus>\"\n```\n\nThe row key is `\u003Cn>: \u003Ctitle>` — the step number and title exactly as they appear\nin `implement.md`. `dx-step-all` invokes this skill once per step and writes the\nsame file with the same key and the same `DX_PROGRESS_TITLE`, so a step must\nproduce **one** row however it was started, and `dx-agent-all` counts it (its\ncounters anchor on `^\\| [0-9]+:`). Never key a row on a free-form label.\n\nStatus values: `pending` · `in_progress` · `done` · `failed` · `skipped` · `blocked`. One row per step, updated in place.\n\nIf `TaskCreate` is in this session's tool list, also mirror the same steps into tasks so the user gets a live checklist — `TaskList` first to cancel stale tasks from an interrupted run. If it is absent (the default on Opus 4.8 \u002F Sonnet 5 \u002F Fable 5 \u002F Mythos 5 and newer), skip that silently and rely on the file. Never block a step transition on a task tool being present.\n\n## Flow\n\n```dot\ndigraph step {\n    \"Locate spec directory\" [shape=box];\n    \"Hub mode check\" [shape=diamond];\n    \"Find next step\" [shape=diamond];\n    \"All done\" [shape=doublecircle];\n    \"Step status?\" [shape=diamond];\n    \"Mark in-progress\" [shape=box];\n    \"AEM MCP Pre-Check\" [shape=box];\n    \"Execute the step\" [shape=box];\n    \"Verify compilation\" [shape=box];\n    \"Verification passed?\" [shape=diamond];\n    \"Classify error\" [shape=diamond];\n    \"TRANSIENT: Retry\" [shape=box];\n    \"Retry passed?\" [shape=diamond];\n    \"VALIDATION: Auto-fix\" [shape=box];\n    \"Auto-fix passed?\" [shape=diamond];\n    \"Run tests\" [shape=box];\n    \"Tests passed?\" [shape=diamond];\n    \"Review against plan\" [shape=box];\n    \"Review passed?\" [shape=diamond];\n    \"Stage and commit\" [shape=box];\n    \"Commit succeeded?\" [shape=diamond];\n    \"Mark done + present summary\" [shape=doublecircle];\n    \"Mark blocked + present summary\" [shape=doublecircle];\n\n    \"Locate spec directory\" -> \"Hub mode check\";\n    \"Hub mode check\" -> \"Find next step\" [label=\"not hub mode\"];\n    \"Hub mode check\" -> \"All done\" [label=\"hub dispatched\"];\n    \"Find next step\" -> \"All done\" [label=\"none pending\"];\n    \"Find next step\" -> \"Step status?\" [label=\"found\"];\n    \"Step status?\" -> \"Mark in-progress\" [label=\"pending\"];\n    \"Step status?\" -> \"AEM MCP Pre-Check\" [label=\"in-progress (resume)\"];\n    \"Step status?\" -> \"Find next step\" [label=\"blocked (skip)\"];\n    \"Mark in-progress\" -> \"AEM MCP Pre-Check\";\n    \"AEM MCP Pre-Check\" -> \"Execute the step\";\n    \"Execute the step\" -> \"Verify compilation\";\n    \"Verify compilation\" -> \"Verification passed?\";\n    \"Verification passed?\" -> \"Run tests\" [label=\"yes\"];\n    \"Verification passed?\" -> \"Classify error\" [label=\"no\"];\n    \"Classify error\" -> \"TRANSIENT: Retry\" [label=\"TRANSIENT\"];\n    \"Classify error\" -> \"VALIDATION: Auto-fix\" [label=\"VALIDATION\"];\n    \"Classify error\" -> \"Mark blocked + present summary\" [label=\"PERMANENT\"];\n    \"TRANSIENT: Retry\" -> \"Retry passed?\";\n    \"Retry passed?\" -> \"Run tests\" [label=\"yes\"];\n    \"Retry passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"VALIDATION: Auto-fix\" -> \"Auto-fix passed?\";\n    \"Auto-fix passed?\" -> \"Run tests\" [label=\"yes\"];\n    \"Auto-fix passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"Run tests\" -> \"Tests passed?\";\n    \"Tests passed?\" -> \"Review against plan\" [label=\"yes\"];\n    \"Tests passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"Review against plan\" -> \"Review passed?\";\n    \"Review passed?\" -> \"Stage and commit\" [label=\"yes\"];\n    \"Review passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"Stage and commit\" -> \"Commit succeeded?\";\n    \"Commit succeeded?\" -> \"Mark done + present summary\" [label=\"yes\"];\n    \"Commit succeeded?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n}\n```\n\n## Node Details\n\n### Locate spec directory\n\n```bash\nSPEC_DIR=$(bash .ai\u002Flib\u002Fdx-common.sh find-spec-dir $ARGUMENTS)\n```\n\nRead `implement.md` from `$SPEC_DIR`.\n\n### Hub mode check\n\nRead `..\u002F..\u002Fshared\u002Fhub-dispatch.md` for hub detection logic.\n\nIf hub mode is active (`hub.enabled: true` AND cwd is `.hub\u002F`):\n1. Determine which repo owns this step:\n   - Read `implement.md` step instructions for file paths\n   - Match file paths to repo capabilities from config\n   - Or: if step specifies a repo tag (from cross-repo plan), use that\n2. Dispatch to the correct repo: `cd \u003Crepo.path> && claude -p \"\u002Fdx-step \u003Cticket-id>\" --output-format json --allowedTools \"Bash,Read,Edit,Write,Glob,Grep\" --permission-mode bypassPermissions`\n3. Collect result, write state\n4. Print: `✓ \u003Crepo> — step \u003CN> \u003Cstatus>`\n5. Go to → \"All done\" (step executed in target repo)\n\nIf hub mode is not active: continue to \"Find next step\" (normal flow).\n\n### Find next step\n\nParse implement.md and find the first step with `**Status:** pending`.\n\nIf a step has `**Status:** in-progress`, it was interrupted — route to \"Step status?\" with `in-progress`.\n\nIf a step has `**Status:** blocked`, skip it and find the next pending step. Print: \"Skipping Step N (blocked). Executing Step M instead.\"\n\n### All done\n\n1. Check if implement.md has an `**Other repos required:**` line. If so, print:\n   ```\n   > Cross-repo: This plan covers \u003Ccurrent repo> only. Switch to \u003Cother repo(s)> and run `\u002Fdx-req \u003Cid>` there.\n   ```\n2. If `$IN_STEP_LOOP == 0`, print: \"All steps are done. Run `\u002Fdx-pr` to create a pull request.\"\n3. End with the `## Return` block (`verdict: pass`, `next_action: none — no pending steps`).\n\n### Step status?\n\nRoute based on the step's current status:\n- **pending** → go to \"Mark in-progress\"\n- **in-progress** → go to \"AEM MCP Pre-Check\" (resume interrupted step — pre-check is idempotent)\n- **blocked** → go back to \"Find next step\" (skip and find next pending)\n\n### Mark in-progress\n\nUpdate the step's status in implement.md:\n```\n**Status:** in-progress\n```\n\n**Note:** When updating status in implement.md, preserve the provenance frontmatter block at the top of the file unchanged.\n\n### AEM MCP Pre-Check\n\n**Trigger:** Only runs when the current step modifies files under `aem.component-path` or frontend component paths from config. Skip for pure Java, config, test-only, or non-component steps.\n\n**Prerequisite:** `aem.author-url-qa` configured in `.ai\u002Fconfig.yaml`. If not configured, skip pre-check silently.\n\nThree quick validation queries against AEM QA:\n\n1. **Component exists** — `mcp__plugin_dx-aem_AEM__getNodeContent` on the component definition path. If not found: warn \"Component `\u003Cname>` not found on QA. May be new or not yet deployed. Skipping AEM pre-check.\" and skip remaining queries.\n\n2. **Field exists** — `mcp__plugin_dx-aem_AEM__getNodeContent` on `\u003Ccomponent-path>\u002F\u003Cname>\u002F_cq_dialog` (depth 6). Check that every dialog field referenced in the plan step actually exists in the dialog. If a referenced field is missing: warn \"Plan references field `\u003Cfield>` but it's not in the QA dialog. Possible: not yet deployed or field name is wrong.\"\n\n3. **Field semantic check** — `mcp__plugin_dx-aem_AEM__getNodeContent` on a component instance from a known page (use pages from `research.md` AEM Component Intelligence, or query for one). Compare the plan's assumption about the field's purpose against the actual `fieldLabel` and authored value. If mismatch: warn \"Plan says `\u003Cfield>` is `\u003Cplan assumption>`, but QA shows label `\u003Cactual label>` with value `\u003Cactual value>`. Review the step.\"\n\n**All results are warnings — never block execution.** The agent uses warnings to adjust its implementation approach if needed. Pre-check informs, does not gate.\n\n**What this does NOT do:** No page scanning (init territory), no variant discovery (planning territory), no content comparison (aem-verify territory), no full dialog walk (aem-snapshot territory). This is a focused 3-query sanity check.\n\n### Execute the step\n\n#### Incremental Implementation Principles\n\nBefore writing code, apply these guardrails:\n\n- **Vertical slices** — implement the smallest complete piece of functionality. Each change should leave the system in a working state.\n- **Safe defaults** — new code opts into behavior conservatively. New features default to OFF.\n- **Rollback-friendly** — prefer additive changes (new files, new methods) over modifications. Additive changes are independently revertable.\n- **Scope discipline** — touch only files listed in the step's **Files:** section. Note adjacent improvements in a comment, don't fix them.\n- **No premature abstraction** — three similar lines of code beat a premature helper. Only abstract when the third use appears.\n\nRead the step's full instructions:\n- **Files** — which files to modify or create\n- **What** — specific instructions for changes\n- **Why** — requirement being addressed (for context)\n\nImplement the changes:\n- Read each file listed in **Files** before modifying it\n- Follow the **What** instructions precisely\n- **Before creating any new utility, helper, or abstraction:** search the codebase (`commons\u002F`, `utils\u002F`, `shared\u002F`, `lib\u002F`, `scripts\u002Flibs\u002F`, `mixins\u002F`) for existing implementations. If one exists, use it instead of creating new code. If `research.md` exists in the spec directory, check its \"Existing Implementation Check\" section for reusable code.\n- Use Edit tool for modifications, Write tool for new files\n- Follow project conventions — read `.claude\u002Frules\u002F` for rules matching the file types being modified (e.g., `fe-javascript.md` for JS, `fe-styles.md` for SCSS). If `.github\u002Finstructions\u002F` exists, also read the relevant instruction file for framework-specific patterns. For AEM frontend work involving modals, overlays, or focus traps, check if `shared\u002Faem-dom-rules.md` exists (dx-aem plugin) and follow its DOM constraints.\n\n**Test-first approach:**\n\nIf the step has a `Test:` line and `superpowers:test-driven-development` is available, invoke it to guide the RED-GREEN-REFACTOR cycle.\n\n**Fallback (if superpowers not installed):** Follow the Red-Green-Refactor cycle from `..\u002F..\u002Fshared\u002Ftesting-patterns.md`:\n1. **RED:** Write\u002Flocate the test first. Run it — confirm it fails (proves the test validates something).\n2. **GREEN:** Write the minimal implementation to pass the test. No extras (YAGNI).\n3. **REFACTOR:** Clean up only after green — duplication, naming, structure — while staying green.\n\nIf a test passes immediately before any code change, the test isn't validating new behavior — fix it.\n\n### Verify compilation\n\nRun the step's **Test** command if specified. Otherwise, read the build command from `.ai\u002Fconfig.yaml` `build.command` and run a compile check (not full build):\n\nIf the project uses Maven: `mvn compile -pl \u003Cmodule> -q`\nIf the project uses npm: `npm run build`\nOtherwise: use whatever compile\u002Ftypecheck command is configured.\n\n### Verification passed?\n\n- **yes** — compilation\u002Ftest exits 0 → go to \"Run tests\"\n- **no** — error detected → go to \"Classify error\"\n\n### Classify error\n\nClassify the error against the taxonomy in `..\u002F..\u002Fshared\u002Ferror-handling.md`:\n- **TRANSIENT** → go to \"TRANSIENT: Retry\"\n- **VALIDATION** → go to \"VALIDATION: Auto-fix\"\n- **PERMANENT** → go to \"Mark blocked + present summary\"\n\n### TRANSIENT: Retry\n\nRetry the command (up to 2 times). If still failing, go to \"Mark blocked + present summary\".\n\n### Retry passed?\n\n- **yes** — retry succeeded → go to \"Run tests\"\n- **no** — still failing after retries → go to \"Mark blocked + present summary\"\n\n### VALIDATION: Auto-fix\n\nAttempt ONE auto-fix (syntax fix, missing import, lint fix). Re-run verification. Do NOT attempt more than one auto-fix.\n\n### Auto-fix passed?\n\n- **yes** — fix + verify passes → go to \"Run tests\"\n- **no** — fix fails or verify still fails → go to \"Mark blocked + present summary\"\n\n### Run tests\n\nDetermine the test command:\n1. Check the current step's **Test:** line\n2. Fall back to `build.test` from `.ai\u002Fconfig.yaml`\n3. Fall back to common patterns: Maven → `mvn test -pl \u003Cmodule>`, npm → `npm test`\n\nExecute with a 5-minute timeout. Parse output:\n- **Tests run** \u002F **Passed** \u002F **Failed** \u002F **Errors** \u002F **Skipped** \u002F **Time elapsed**\n- For each failure: extract test name and assertion message (max 10 lines per failure)\n\n### Tests passed?\n\n- **yes** — all tests pass (zero failures, zero errors) → go to \"Review against plan\"\n- **no** — any test failure or error → go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"test\", error: \"\u003Cfailure summary>\" }`\n\n### Review against plan\n\nUse ultrathink for deep reasoning about correctness.\n\nGet the diff: `git diff` for uncommitted changes, or `git diff HEAD~1` if already committed. Read modified files in full for context.\n\n**Plan compliance:** Do changes match the step's instructions? Are all **Files:** modified? Any extra files changed?\n\n**Convention check:** Read `.claude\u002Frules\u002F` and `.github\u002Finstructions\u002F` for relevant file types. Check naming, framework patterns, interface separation, template patterns, test patterns.\n\n**Bug check:** Null pointer risks, resource leaks, hardcoded values that should be configurable, missing imports, property name mismatches.\n\nVerdict: APPROVED, APPROVED WITH NOTES, or CHANGES REQUESTED.\n\n### Review passed?\n\n- **yes** — verdict is APPROVED or APPROVED WITH NOTES → go to \"Stage and commit\"\n- **no** — verdict is CHANGES REQUESTED → go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"review\", error: \"\u003Clist of required changes>\" }`\n\n### Stage and commit\n\n**Before anything else**, read `..\u002F..\u002Fshared\u002Fgit-rules.md` — all git\u002FSCM conventions.\n\n**Branch check:** Verify on `feature\u002F*` or `bugfix\u002F*` branch. If not, run `bash .ai\u002Flib\u002Fensure-feature-branch.sh $SPEC_DIR`.\n\n**Determine files:** From the step's **Files:** list + `git status` for files clearly part of this step. Never stage unrelated files, .env, credentials, or secrets.\n\n**Stage specifically** (never `git add -A`):\n```bash\ngit add \u003Cfile1> \u003Cfile2> ... \u003Cimplement.md>\n```\nAlways include implement.md to capture the status update.\n\n**Commit message:** Extract work item ID from spec directory name. Format: `#\u003CID> \u003Cimperative description>`. Use HEREDOC:\n```bash\ngit commit -m \"$(cat \u003C\u003C'EOF'\n#\u003CID> \u003Cdescription>\nEOF\n)\"\n```\n\nIf nothing to stage, report \"Nothing to stage — no commit created\" and go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"commit\", error: \"nothing to stage\" }`.\n\n### Commit succeeded?\n\n- **yes** — commit created with valid hash → go to \"Mark done + present summary\"\n- **no** — commit failed → go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"commit\", error: \"\u003Cmessage>\" }`\n\n### Mark done + present summary\n\nUpdate implement.md:\n```\n**Status:** done\n```\n\nPrint:\n```markdown\n## Step N complete: \u003Cstep title>\n\n**Files modified:** \u003Clist>\n**Compilation:** passed\n**Tests:** passed (\u003CN> tests, \u003Ctime>)\n**Review:** \u003Cverdict>\n**Commit:** `\u003Cshort hash>` — `\u003Ccommit message>`\n**Next:** Step \u003CN+1> — \u003Ctitle> (or \"All steps done — run `\u002Fdx-pr`\")\n```\n\nIf `$IN_STEP_LOOP == 0`, add: \"Run `\u002Fdx-step` for the next step, or `\u002Fdx-step-all` to continue autonomously.\" When a loop is driving you, omit it — the coordinator already continues.\n\nThen end with the `## Return` block (`verdict: pass`).\n\n### Mark blocked + present summary\n\nUpdate implement.md:\n```\n**Status:** blocked\n```\n\nInclude the phase, error category, message, and suggested action:\n```\n{ status: \"blocked\", phase: \"compile|test|review|commit\", error: \"\u003Cmessage>\" }\n```\n\nPrint the summary with the failure details, then end with the `## Return` block (`verdict: fail`, the phase and error in `summary`). The coordinator (`dx-step-all`) branches on that verdict to decide whether to call `dx-step-fix`.\n\n## Success Criteria\n\n- [ ] Target step status updated: pending → done (or blocked with reason)\n- [ ] If done: compilation\u002Fbuild command exits 0\n- [ ] If done: tests pass (zero failures)\n- [ ] If done: review verdict is APPROVED or APPROVED WITH NOTES\n- [ ] If done: commit created with work item ID in message\n- [ ] If done: files modified match step's `**Files:**` list\n- [ ] implement.md updated in-place (no corruption of other steps)\n\n## Examples\n\n### Execute next step (full pipeline)\n```\n\u002Fdx-step 2435084\n```\nFinds the first pending step in `implement.md`, marks it `in-progress`, implements code, verifies compilation, runs tests, reviews against plan and conventions, commits, and marks `done`.\n\n### Resume interrupted step\n```\n\u002Fdx-step 2435084\n```\nIf a step is `in-progress` (from a previous interrupted run), resumes it instead of starting the next pending step.\n\n### All steps complete\n```\n\u002Fdx-step 2435084\n```\nIf no pending steps remain, prints \"All steps are done. Run `\u002Fdx-pr` to create a pull request.\"\n\n## Troubleshooting\n\n### Step marked blocked after compilation failure\n**Cause:** The implemented code doesn't compile, and the one auto-fix attempt also failed.\n**Fix:** Run `\u002Fdx-step-fix` to diagnose and fix the error, or manually fix and reset the status to `pending` in `implement.md`.\n\n### Step marked blocked after test failure\n**Cause:** Tests fail after implementation.\n**Fix:** Run `\u002Fdx-step-fix` to diagnose and fix failures, then reset status to `pending`.\n\n### Step marked blocked after review\n**Cause:** Code review found issues (convention violations, bugs, plan deviations).\n**Fix:** Run `\u002Fdx-step-fix` to address the required changes, then reset status to `pending`.\n\n### Step creates a new helper instead of reusing existing one\n**Cause:** The step instructions in `implement.md` say \"create new\" when an existing utility would work.\n**Fix:** Fix `implement.md` first — update the step's What instructions to reference the existing code. Then re-run `\u002Fdx-step`.\n\n### \"No implement.md found\"\n**Cause:** Planning hasn't been done yet.\n**Fix:** Run `\u002Fdx-plan \u003Cid>` to generate the implementation plan first.\n\n### \"Not on a feature branch\"\n**Cause:** Working on `development`, `main`, or another protected branch.\n**Fix:** The skill auto-runs `ensure-feature-branch.sh`. If that fails, manually create: `git checkout -b feature\u002F\u003Cid>-\u003Cslug>`.\n\n## Decision Examples\n\n### Fixable Error (VALIDATION)\n**Error:** `error TS2304: Cannot find name 'HeroProps'`\n**Classification:** VALIDATION \u002F SYNTAX — missing import\n**Action:** Add `import { HeroProps } from '.\u002Fhero.types'`, re-run compilation\n**Outcome:** Fixed. Proceed to tests.\n\n### Unfixable Error (PERMANENT)\n**Error:** `bash: mvn: command not found`\n**Classification:** PERMANENT \u002F MISSING_DEPENDENCY\n**Action:** Do NOT attempt fix. Mark step blocked: \"Maven not installed on this machine.\"\n\n### Ambiguous Error (needs classification)\n**Error:** `ECONNREFUSED 127.0.0.1:4502`\n**Classification:** TRANSIENT \u002F TIMEOUT — AEM is not running\n**Action:** Retry once (AEM may be starting). If still failing → mark blocked: \"AEM instance not available.\"\n\n### Test Failure\n**Tests:** 3 failed out of 47\n**Action:** Mark blocked with `{ status: \"blocked\", phase: \"test\", error: \"3 test failures: TestDialog#testDropdown, ...\" }`. Coordinator calls `\u002Fdx-step-fix`.\n\n### Review Rejection\n**Verdict:** CHANGES REQUESTED — hardcoded color `#FF0000` should use SCSS variable\n**Action:** Mark blocked with `{ status: \"blocked\", phase: \"review\", error: \"Convention violation: use $primary-color instead of #FF0000\" }`. Coordinator calls `\u002Fdx-step-fix`.\n\n## Anti-Rationalization\n\nCommon excuses for cutting corners during step execution — and why they're wrong:\n\n| False Logic | Reality Check |\n|---|---|\n| \"I'll test at the end\" | Bugs cascade — a Step 1 error corrupts Steps 2-5. Test every step. |\n| \"This is too small to commit separately\" | Small commits are costless; large ones hide problems and block bisection. |\n| \"I know what this file does, no need to read it\" | Assumptions cause wrong edits. Reading is cheap, debugging is expensive. |\n| \"I'll skip the review — it compiled and tests pass\" | Compilation proves syntax, not correctness. Reviews catch logic bugs. |\n| \"The plan is wrong, I'll improvise a better approach\" | Mark the step blocked and let the user decide. Don't freelance. |\n| \"I'll refactor this adjacent code while I'm here\" | Scope creep causes merge conflicts and breaks unrelated tests. Touch only what the step requires. |\n| \"Tests pass immediately, so they're fine\" | A test that passes before implementation proves nothing — fix it. |\n\n## Rules\n\n- **One step at a time** — execute exactly one step, then end with the `## Return` block. The coordinator or user decides what's next.\n- **Read before writing** — always read a file before editing it. Never blindly edit.\n- **Follow conventions** — read `.claude\u002Frules\u002F` and `.github\u002Finstructions\u002F` (if it exists) for the relevant file types before writing code. For AEM modal\u002Foverlay work, also check `shared\u002Faem-dom-rules.md`.\n- **Don't improvise** — implement exactly what the step says. If instructions are unclear, mark the step blocked with a note rather than guessing.\n- **Update status immediately** — mark in-progress before starting, done\u002Fblocked when finished. This is the state machine that coordinators rely on.\n- **Compile check is mandatory** — never mark a step done without verifying compilation passes.\n- **Tests are mandatory** — never mark a step done without running tests.\n- **Review is mandatory** — never mark a step done without reviewing against the plan.\n- **Commit is mandatory** — never mark a step done without committing changes.\n- **Follow git-rules.md** — read `..\u002F..\u002Fshared\u002Fgit-rules.md` before committing. Stage specifically, never `git add -A`.\n- **No empty commits** — if nothing to stage, report and mark blocked.\n\n## Return\n\nThis skill runs in a forked context. It MUST end with a `## Return` block per `plugins\u002Fdx-core\u002Fshared\u002Fskill-return-contract.md` — in both the standalone and the step-loop case.\n\n- `verdict: pass` — step committed and marked `done` (or no pending steps remain)\n- `verdict: fail` — step marked `blocked`; `summary` names the phase (`compile|test|review|commit`) and the error\n\nExamples:\n\n```markdown\n## Return\nverdict: pass\nsummary: Step 3 done — Add dialog fields; committed 4bf6fe5; 12 tests passed; review APPROVED.\nartifacts:\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fimplement.md\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fdev-all-progress.md\nnext_action: next pending step is 4 — Wire the model\n```\n\n```markdown\n## Return\nverdict: fail\nsummary: Step 3 blocked in phase test — 2 failures in HeroModelTest (null title).\nartifacts:\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fimplement.md\nnext_action: run \u002Fdx-step-fix\n```\n","**Isolation check.** This skill is meant to run in its own context (`context: fork`). If you can see the user's messages from before this skill was invoked, you are running inline (Copilot CLI ignores `context: fork`): do not run the steps below yourself. Start one subagent with your task\u002Fsubagent tool, give it only this instruction — \"Invoke the dx-core:dx-step skill with these arguments: \u003Cthe arguments you were given, or none>. Run it fully and reply with its final report only.\" — then show the user that report and stop. If you cannot see earlier user messages, or your only earlier message is that instruction to invoke dx-core:dx-step (you are a fork or that subagent), continue below.\n\nYou execute the next pending step from implement.md — implement the changes, verify compilation, run tests, review against plan and conventions, commit, and mark the step done.\n\nYou run forked (`context: fork`): coordinators (`dx-step-all`, `dx-bug-fix`) call you once per step and read only your final `## Return` block. Before printing anything user-facing, check whether a step loop is driving you (see `plugins\u002Fdx-core\u002Fshared\u002Forchestration-check.md` § Step-loop marker):\n\n```bash\nIN_STEP_LOOP=0\nLOOP_FLAG=\".ai\u002Frun-context\u002Fstep-loop.flag\"\nif [ -f \"$LOOP_FLAG\" ]; then\n  AGE=$(( $(date +%s) - $(date -r \"$LOOP_FLAG\" +%s) ))\n  [ \"$AGE\" -lt 7200 ] && IN_STEP_LOOP=1\nfi\n```\n\nYou are the worker for **one** step. Never invoke `Skill(dx-step)` or `\u002Fdx-step-all` yourself. The loop belongs to the coordinator.\n\n`$IN_STEP_LOOP == 1` only suppresses the \"run X next\" hints addressed to a human — it never changes what the step does.\n\n## Progress Tracking\n\nFollow `.ai\u002Frules\u002Ftask-progress.md` (plugin default: `rules\u002Ftask-progress.md`). The progress **file** is the source of truth — write it at every step transition:\n\n```bash\nDX_PROGRESS_FILE=\"dev-all-progress.md\" DX_PROGRESS_TITLE=\"Pipeline Progress\" \\\n  bash \"${CLAUDE_PLUGIN_ROOT}\u002Fshared\u002Fupdate-progress.sh\" \"$SPEC_DIR\" \"\u003Cn>: \u003Ctitle>\" \"\u003Cstatus>\"\n```\n\nThe row key is `\u003Cn>: \u003Ctitle>` — the step number and title exactly as they appear\nin `implement.md`. `dx-step-all` invokes this skill once per step and writes the\nsame file with the same key and the same `DX_PROGRESS_TITLE`, so a step must\nproduce **one** row however it was started, and `dx-agent-all` counts it (its\ncounters anchor on `^\\| [0-9]+:`). Never key a row on a free-form label.\n\nStatus values: `pending` · `in_progress` · `done` · `failed` · `skipped` · `blocked`. One row per step, updated in place.\n\nIf `TaskCreate` is in this session's tool list, also mirror the same steps into tasks so the user gets a live checklist — `TaskList` first to cancel stale tasks from an interrupted run. If it is absent (the default on Opus 4.8 \u002F Sonnet 5 \u002F Fable 5 \u002F Mythos 5 and newer), skip that silently and rely on the file. Never block a step transition on a task tool being present.\n\n## Flow\n\n```dot\ndigraph step {\n    \"Locate spec directory\" [shape=box];\n    \"Hub mode check\" [shape=diamond];\n    \"Find next step\" [shape=diamond];\n    \"All done\" [shape=doublecircle];\n    \"Step status?\" [shape=diamond];\n    \"Mark in-progress\" [shape=box];\n    \"AEM MCP Pre-Check\" [shape=box];\n    \"Execute the step\" [shape=box];\n    \"Verify compilation\" [shape=box];\n    \"Verification passed?\" [shape=diamond];\n    \"Classify error\" [shape=diamond];\n    \"TRANSIENT: Retry\" [shape=box];\n    \"Retry passed?\" [shape=diamond];\n    \"VALIDATION: Auto-fix\" [shape=box];\n    \"Auto-fix passed?\" [shape=diamond];\n    \"Run tests\" [shape=box];\n    \"Tests passed?\" [shape=diamond];\n    \"Review against plan\" [shape=box];\n    \"Review passed?\" [shape=diamond];\n    \"Stage and commit\" [shape=box];\n    \"Commit succeeded?\" [shape=diamond];\n    \"Mark done + present summary\" [shape=doublecircle];\n    \"Mark blocked + present summary\" [shape=doublecircle];\n\n    \"Locate spec directory\" -> \"Hub mode check\";\n    \"Hub mode check\" -> \"Find next step\" [label=\"not hub mode\"];\n    \"Hub mode check\" -> \"All done\" [label=\"hub dispatched\"];\n    \"Find next step\" -> \"All done\" [label=\"none pending\"];\n    \"Find next step\" -> \"Step status?\" [label=\"found\"];\n    \"Step status?\" -> \"Mark in-progress\" [label=\"pending\"];\n    \"Step status?\" -> \"AEM MCP Pre-Check\" [label=\"in-progress (resume)\"];\n    \"Step status?\" -> \"Find next step\" [label=\"blocked (skip)\"];\n    \"Mark in-progress\" -> \"AEM MCP Pre-Check\";\n    \"AEM MCP Pre-Check\" -> \"Execute the step\";\n    \"Execute the step\" -> \"Verify compilation\";\n    \"Verify compilation\" -> \"Verification passed?\";\n    \"Verification passed?\" -> \"Run tests\" [label=\"yes\"];\n    \"Verification passed?\" -> \"Classify error\" [label=\"no\"];\n    \"Classify error\" -> \"TRANSIENT: Retry\" [label=\"TRANSIENT\"];\n    \"Classify error\" -> \"VALIDATION: Auto-fix\" [label=\"VALIDATION\"];\n    \"Classify error\" -> \"Mark blocked + present summary\" [label=\"PERMANENT\"];\n    \"TRANSIENT: Retry\" -> \"Retry passed?\";\n    \"Retry passed?\" -> \"Run tests\" [label=\"yes\"];\n    \"Retry passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"VALIDATION: Auto-fix\" -> \"Auto-fix passed?\";\n    \"Auto-fix passed?\" -> \"Run tests\" [label=\"yes\"];\n    \"Auto-fix passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"Run tests\" -> \"Tests passed?\";\n    \"Tests passed?\" -> \"Review against plan\" [label=\"yes\"];\n    \"Tests passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"Review against plan\" -> \"Review passed?\";\n    \"Review passed?\" -> \"Stage and commit\" [label=\"yes\"];\n    \"Review passed?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n    \"Stage and commit\" -> \"Commit succeeded?\";\n    \"Commit succeeded?\" -> \"Mark done + present summary\" [label=\"yes\"];\n    \"Commit succeeded?\" -> \"Mark blocked + present summary\" [label=\"no\"];\n}\n```\n\n## Node Details\n\n### Locate spec directory\n\n```bash\nSPEC_DIR=$(bash .ai\u002Flib\u002Fdx-common.sh find-spec-dir $ARGUMENTS)\n```\n\nRead `implement.md` from `$SPEC_DIR`.\n\n### Hub mode check\n\nRead `..\u002F..\u002Fshared\u002Fhub-dispatch.md` for hub detection logic.\n\nIf hub mode is active (`hub.enabled: true` AND cwd is `.hub\u002F`):\n1. Determine which repo owns this step:\n   - Read `implement.md` step instructions for file paths\n   - Match file paths to repo capabilities from config\n   - Or: if step specifies a repo tag (from cross-repo plan), use that\n2. Dispatch to the correct repo: `cd \u003Crepo.path> && claude -p \"\u002Fdx-step \u003Cticket-id>\" --output-format json --allowedTools \"Bash,Read,Edit,Write,Glob,Grep\" --permission-mode bypassPermissions`\n3. Collect result, write state\n4. Print: `✓ \u003Crepo> — step \u003CN> \u003Cstatus>`\n5. Go to → \"All done\" (step executed in target repo)\n\nIf hub mode is not active: continue to \"Find next step\" (normal flow).\n\n### Find next step\n\nParse implement.md and find the first step with `**Status:** pending`.\n\nIf a step has `**Status:** in-progress`, it was interrupted — route to \"Step status?\" with `in-progress`.\n\nIf a step has `**Status:** blocked`, skip it and find the next pending step. Print: \"Skipping Step N (blocked). Executing Step M instead.\"\n\n### All done\n\n1. Check if implement.md has an `**Other repos required:**` line. If so, print:\n   ```\n   > Cross-repo: This plan covers \u003Ccurrent repo> only. Switch to \u003Cother repo(s)> and run `\u002Fdx-req \u003Cid>` there.\n   ```\n2. If `$IN_STEP_LOOP == 0`, print: \"All steps are done. Run `\u002Fdx-pr` to create a pull request.\"\n3. End with the `## Return` block (`verdict: pass`, `next_action: none — no pending steps`).\n\n### Step status?\n\nRoute based on the step's current status:\n- **pending** → go to \"Mark in-progress\"\n- **in-progress** → go to \"AEM MCP Pre-Check\" (resume interrupted step — pre-check is idempotent)\n- **blocked** → go back to \"Find next step\" (skip and find next pending)\n\n### Mark in-progress\n\nUpdate the step's status in implement.md:\n```\n**Status:** in-progress\n```\n\n**Note:** When updating status in implement.md, preserve the provenance frontmatter block at the top of the file unchanged.\n\n### AEM MCP Pre-Check\n\n**Trigger:** Only runs when the current step modifies files under `aem.component-path` or frontend component paths from config. Skip for pure Java, config, test-only, or non-component steps.\n\n**Prerequisite:** `aem.author-url-qa` configured in `.ai\u002Fconfig.yaml`. If not configured, skip pre-check silently.\n\nThree quick validation queries against AEM QA:\n\n1. **Component exists** — `mcp__plugin_dx-aem_AEM__getNodeContent` on the component definition path. If not found: warn \"Component `\u003Cname>` not found on QA. May be new or not yet deployed. Skipping AEM pre-check.\" and skip remaining queries.\n\n2. **Field exists** — `mcp__plugin_dx-aem_AEM__getNodeContent` on `\u003Ccomponent-path>\u002F\u003Cname>\u002F_cq_dialog` (depth 6). Check that every dialog field referenced in the plan step actually exists in the dialog. If a referenced field is missing: warn \"Plan references field `\u003Cfield>` but it's not in the QA dialog. Possible: not yet deployed or field name is wrong.\"\n\n3. **Field semantic check** — `mcp__plugin_dx-aem_AEM__getNodeContent` on a component instance from a known page (use pages from `research.md` AEM Component Intelligence, or query for one). Compare the plan's assumption about the field's purpose against the actual `fieldLabel` and authored value. If mismatch: warn \"Plan says `\u003Cfield>` is `\u003Cplan assumption>`, but QA shows label `\u003Cactual label>` with value `\u003Cactual value>`. Review the step.\"\n\n**All results are warnings — never block execution.** The agent uses warnings to adjust its implementation approach if needed. Pre-check informs, does not gate.\n\n**What this does NOT do:** No page scanning (init territory), no variant discovery (planning territory), no content comparison (aem-verify territory), no full dialog walk (aem-snapshot territory). This is a focused 3-query sanity check.\n\n### Execute the step\n\n#### Incremental Implementation Principles\n\nBefore writing code, apply these guardrails:\n\n- **Vertical slices** — implement the smallest complete piece of functionality. Each change should leave the system in a working state.\n- **Safe defaults** — new code opts into behavior conservatively. New features default to OFF.\n- **Rollback-friendly** — prefer additive changes (new files, new methods) over modifications. Additive changes are independently revertable.\n- **Scope discipline** — touch only files listed in the step's **Files:** section. Note adjacent improvements in a comment, don't fix them.\n- **No premature abstraction** — three similar lines of code beat a premature helper. Only abstract when the third use appears.\n\nRead the step's full instructions:\n- **Files** — which files to modify or create\n- **What** — specific instructions for changes\n- **Why** — requirement being addressed (for context)\n\nImplement the changes:\n- Read each file listed in **Files** before modifying it\n- Follow the **What** instructions precisely\n- **Before creating any new utility, helper, or abstraction:** search the codebase (`commons\u002F`, `utils\u002F`, `shared\u002F`, `lib\u002F`, `scripts\u002Flibs\u002F`, `mixins\u002F`) for existing implementations. If one exists, use it instead of creating new code. If `research.md` exists in the spec directory, check its \"Existing Implementation Check\" section for reusable code.\n- Use Edit tool for modifications, Write tool for new files\n- Follow project conventions — read `.claude\u002Frules\u002F` for rules matching the file types being modified (e.g., `fe-javascript.md` for JS, `fe-styles.md` for SCSS). If `.github\u002Finstructions\u002F` exists, also read the relevant instruction file for framework-specific patterns. For AEM frontend work involving modals, overlays, or focus traps, check if `shared\u002Faem-dom-rules.md` exists (dx-aem plugin) and follow its DOM constraints.\n\n**Test-first approach:**\n\nIf the step has a `Test:` line and `superpowers:test-driven-development` is available, invoke it to guide the RED-GREEN-REFACTOR cycle.\n\n**Fallback (if superpowers not installed):** Follow the Red-Green-Refactor cycle from `..\u002F..\u002Fshared\u002Ftesting-patterns.md`:\n1. **RED:** Write\u002Flocate the test first. Run it — confirm it fails (proves the test validates something).\n2. **GREEN:** Write the minimal implementation to pass the test. No extras (YAGNI).\n3. **REFACTOR:** Clean up only after green — duplication, naming, structure — while staying green.\n\nIf a test passes immediately before any code change, the test isn't validating new behavior — fix it.\n\n### Verify compilation\n\nRun the step's **Test** command if specified. Otherwise, read the build command from `.ai\u002Fconfig.yaml` `build.command` and run a compile check (not full build):\n\nIf the project uses Maven: `mvn compile -pl \u003Cmodule> -q`\nIf the project uses npm: `npm run build`\nOtherwise: use whatever compile\u002Ftypecheck command is configured.\n\n### Verification passed?\n\n- **yes** — compilation\u002Ftest exits 0 → go to \"Run tests\"\n- **no** — error detected → go to \"Classify error\"\n\n### Classify error\n\nClassify the error against the taxonomy in `..\u002F..\u002Fshared\u002Ferror-handling.md`:\n- **TRANSIENT** → go to \"TRANSIENT: Retry\"\n- **VALIDATION** → go to \"VALIDATION: Auto-fix\"\n- **PERMANENT** → go to \"Mark blocked + present summary\"\n\n### TRANSIENT: Retry\n\nRetry the command (up to 2 times). If still failing, go to \"Mark blocked + present summary\".\n\n### Retry passed?\n\n- **yes** — retry succeeded → go to \"Run tests\"\n- **no** — still failing after retries → go to \"Mark blocked + present summary\"\n\n### VALIDATION: Auto-fix\n\nAttempt ONE auto-fix (syntax fix, missing import, lint fix). Re-run verification. Do NOT attempt more than one auto-fix.\n\n### Auto-fix passed?\n\n- **yes** — fix + verify passes → go to \"Run tests\"\n- **no** — fix fails or verify still fails → go to \"Mark blocked + present summary\"\n\n### Run tests\n\nDetermine the test command:\n1. Check the current step's **Test:** line\n2. Fall back to `build.test` from `.ai\u002Fconfig.yaml`\n3. Fall back to common patterns: Maven → `mvn test -pl \u003Cmodule>`, npm → `npm test`\n\nExecute with a 5-minute timeout. Parse output:\n- **Tests run** \u002F **Passed** \u002F **Failed** \u002F **Errors** \u002F **Skipped** \u002F **Time elapsed**\n- For each failure: extract test name and assertion message (max 10 lines per failure)\n\n### Tests passed?\n\n- **yes** — all tests pass (zero failures, zero errors) → go to \"Review against plan\"\n- **no** — any test failure or error → go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"test\", error: \"\u003Cfailure summary>\" }`\n\n### Review against plan\n\nUse ultrathink for deep reasoning about correctness.\n\nGet the diff: `git diff` for uncommitted changes, or `git diff HEAD~1` if already committed. Read modified files in full for context.\n\n**Plan compliance:** Do changes match the step's instructions? Are all **Files:** modified? Any extra files changed?\n\n**Convention check:** Read `.claude\u002Frules\u002F` and `.github\u002Finstructions\u002F` for relevant file types. Check naming, framework patterns, interface separation, template patterns, test patterns.\n\n**Bug check:** Null pointer risks, resource leaks, hardcoded values that should be configurable, missing imports, property name mismatches.\n\nVerdict: APPROVED, APPROVED WITH NOTES, or CHANGES REQUESTED.\n\n### Review passed?\n\n- **yes** — verdict is APPROVED or APPROVED WITH NOTES → go to \"Stage and commit\"\n- **no** — verdict is CHANGES REQUESTED → go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"review\", error: \"\u003Clist of required changes>\" }`\n\n### Stage and commit\n\n**Before anything else**, read `..\u002F..\u002Fshared\u002Fgit-rules.md` — all git\u002FSCM conventions.\n\n**Branch check:** Verify on `feature\u002F*` or `bugfix\u002F*` branch. If not, run `bash .ai\u002Flib\u002Fensure-feature-branch.sh $SPEC_DIR`.\n\n**Determine files:** From the step's **Files:** list + `git status` for files clearly part of this step. Never stage unrelated files, .env, credentials, or secrets.\n\n**Stage specifically** (never `git add -A`):\n```bash\ngit add \u003Cfile1> \u003Cfile2> ... \u003Cimplement.md>\n```\nAlways include implement.md to capture the status update.\n\n**Commit message:** Extract work item ID from spec directory name. Format: `#\u003CID> \u003Cimperative description>`. Use HEREDOC:\n```bash\ngit commit -m \"$(cat \u003C\u003C'EOF'\n#\u003CID> \u003Cdescription>\nEOF\n)\"\n```\n\nIf nothing to stage, report \"Nothing to stage — no commit created\" and go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"commit\", error: \"nothing to stage\" }`.\n\n### Commit succeeded?\n\n- **yes** — commit created with valid hash → go to \"Mark done + present summary\"\n- **no** — commit failed → go to \"Mark blocked + present summary\" with `{ status: \"blocked\", phase: \"commit\", error: \"\u003Cmessage>\" }`\n\n### Mark done + present summary\n\nUpdate implement.md:\n```\n**Status:** done\n```\n\nPrint:\n```markdown\n## Step N complete: \u003Cstep title>\n\n**Files modified:** \u003Clist>\n**Compilation:** passed\n**Tests:** passed (\u003CN> tests, \u003Ctime>)\n**Review:** \u003Cverdict>\n**Commit:** `\u003Cshort hash>` — `\u003Ccommit message>`\n**Next:** Step \u003CN+1> — \u003Ctitle> (or \"All steps done — run `\u002Fdx-pr`\")\n```\n\nIf `$IN_STEP_LOOP == 0`, add: \"Run `\u002Fdx-step` for the next step, or `\u002Fdx-step-all` to continue autonomously.\" When a loop is driving you, omit it — the coordinator already continues.\n\nThen end with the `## Return` block (`verdict: pass`).\n\n### Mark blocked + present summary\n\nUpdate implement.md:\n```\n**Status:** blocked\n```\n\nInclude the phase, error category, message, and suggested action:\n```\n{ status: \"blocked\", phase: \"compile|test|review|commit\", error: \"\u003Cmessage>\" }\n```\n\nPrint the summary with the failure details, then end with the `## Return` block (`verdict: fail`, the phase and error in `summary`). The coordinator (`dx-step-all`) branches on that verdict to decide whether to call `dx-step-fix`.\n\n## Success Criteria\n\n- [ ] Target step status updated: pending → done (or blocked with reason)\n- [ ] If done: compilation\u002Fbuild command exits 0\n- [ ] If done: tests pass (zero failures)\n- [ ] If done: review verdict is APPROVED or APPROVED WITH NOTES\n- [ ] If done: commit created with work item ID in message\n- [ ] If done: files modified match step's `**Files:**` list\n- [ ] implement.md updated in-place (no corruption of other steps)\n\n## Examples\n\n### Execute next step (full pipeline)\n```\n\u002Fdx-step 2435084\n```\nFinds the first pending step in `implement.md`, marks it `in-progress`, implements code, verifies compilation, runs tests, reviews against plan and conventions, commits, and marks `done`.\n\n### Resume interrupted step\n```\n\u002Fdx-step 2435084\n```\nIf a step is `in-progress` (from a previous interrupted run), resumes it instead of starting the next pending step.\n\n### All steps complete\n```\n\u002Fdx-step 2435084\n```\nIf no pending steps remain, prints \"All steps are done. Run `\u002Fdx-pr` to create a pull request.\"\n\n## Troubleshooting\n\n### Step marked blocked after compilation failure\n**Cause:** The implemented code doesn't compile, and the one auto-fix attempt also failed.\n**Fix:** Run `\u002Fdx-step-fix` to diagnose and fix the error, or manually fix and reset the status to `pending` in `implement.md`.\n\n### Step marked blocked after test failure\n**Cause:** Tests fail after implementation.\n**Fix:** Run `\u002Fdx-step-fix` to diagnose and fix failures, then reset status to `pending`.\n\n### Step marked blocked after review\n**Cause:** Code review found issues (convention violations, bugs, plan deviations).\n**Fix:** Run `\u002Fdx-step-fix` to address the required changes, then reset status to `pending`.\n\n### Step creates a new helper instead of reusing existing one\n**Cause:** The step instructions in `implement.md` say \"create new\" when an existing utility would work.\n**Fix:** Fix `implement.md` first — update the step's What instructions to reference the existing code. Then re-run `\u002Fdx-step`.\n\n### \"No implement.md found\"\n**Cause:** Planning hasn't been done yet.\n**Fix:** Run `\u002Fdx-plan \u003Cid>` to generate the implementation plan first.\n\n### \"Not on a feature branch\"\n**Cause:** Working on `development`, `main`, or another protected branch.\n**Fix:** The skill auto-runs `ensure-feature-branch.sh`. If that fails, manually create: `git checkout -b feature\u002F\u003Cid>-\u003Cslug>`.\n\n## Decision Examples\n\n### Fixable Error (VALIDATION)\n**Error:** `error TS2304: Cannot find name 'HeroProps'`\n**Classification:** VALIDATION \u002F SYNTAX — missing import\n**Action:** Add `import { HeroProps } from '.\u002Fhero.types'`, re-run compilation\n**Outcome:** Fixed. Proceed to tests.\n\n### Unfixable Error (PERMANENT)\n**Error:** `bash: mvn: command not found`\n**Classification:** PERMANENT \u002F MISSING_DEPENDENCY\n**Action:** Do NOT attempt fix. Mark step blocked: \"Maven not installed on this machine.\"\n\n### Ambiguous Error (needs classification)\n**Error:** `ECONNREFUSED 127.0.0.1:4502`\n**Classification:** TRANSIENT \u002F TIMEOUT — AEM is not running\n**Action:** Retry once (AEM may be starting). If still failing → mark blocked: \"AEM instance not available.\"\n\n### Test Failure\n**Tests:** 3 failed out of 47\n**Action:** Mark blocked with `{ status: \"blocked\", phase: \"test\", error: \"3 test failures: TestDialog#testDropdown, ...\" }`. Coordinator calls `\u002Fdx-step-fix`.\n\n### Review Rejection\n**Verdict:** CHANGES REQUESTED — hardcoded color `#FF0000` should use SCSS variable\n**Action:** Mark blocked with `{ status: \"blocked\", phase: \"review\", error: \"Convention violation: use $primary-color instead of #FF0000\" }`. Coordinator calls `\u002Fdx-step-fix`.\n\n## Anti-Rationalization\n\nCommon excuses for cutting corners during step execution — and why they're wrong:\n\n| False Logic | Reality Check |\n|---|---|\n| \"I'll test at the end\" | Bugs cascade — a Step 1 error corrupts Steps 2-5. Test every step. |\n| \"This is too small to commit separately\" | Small commits are costless; large ones hide problems and block bisection. |\n| \"I know what this file does, no need to read it\" | Assumptions cause wrong edits. Reading is cheap, debugging is expensive. |\n| \"I'll skip the review — it compiled and tests pass\" | Compilation proves syntax, not correctness. Reviews catch logic bugs. |\n| \"The plan is wrong, I'll improvise a better approach\" | Mark the step blocked and let the user decide. Don't freelance. |\n| \"I'll refactor this adjacent code while I'm here\" | Scope creep causes merge conflicts and breaks unrelated tests. Touch only what the step requires. |\n| \"Tests pass immediately, so they're fine\" | A test that passes before implementation proves nothing — fix it. |\n\n## Rules\n\n- **One step at a time** — execute exactly one step, then end with the `## Return` block. The coordinator or user decides what's next.\n- **Read before writing** — always read a file before editing it. Never blindly edit.\n- **Follow conventions** — read `.claude\u002Frules\u002F` and `.github\u002Finstructions\u002F` (if it exists) for the relevant file types before writing code. For AEM modal\u002Foverlay work, also check `shared\u002Faem-dom-rules.md`.\n- **Don't improvise** — implement exactly what the step says. If instructions are unclear, mark the step blocked with a note rather than guessing.\n- **Update status immediately** — mark in-progress before starting, done\u002Fblocked when finished. This is the state machine that coordinators rely on.\n- **Compile check is mandatory** — never mark a step done without verifying compilation passes.\n- **Tests are mandatory** — never mark a step done without running tests.\n- **Review is mandatory** — never mark a step done without reviewing against the plan.\n- **Commit is mandatory** — never mark a step done without committing changes.\n- **Follow git-rules.md** — read `..\u002F..\u002Fshared\u002Fgit-rules.md` before committing. Stage specifically, never `git add -A`.\n- **No empty commits** — if nothing to stage, report and mark blocked.\n\n## Return\n\nThis skill runs in a forked context. It MUST end with a `## Return` block per `plugins\u002Fdx-core\u002Fshared\u002Fskill-return-contract.md` — in both the standalone and the step-loop case.\n\n- `verdict: pass` — step committed and marked `done` (or no pending steps remain)\n- `verdict: fail` — step marked `blocked`; `summary` names the phase (`compile|test|review|commit`) and the error\n\nExamples:\n\n```markdown\n## Return\nverdict: pass\nsummary: Step 3 done — Add dialog fields; committed 4bf6fe5; 12 tests passed; review APPROVED.\nartifacts:\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fimplement.md\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fdev-all-progress.md\nnext_action: next pending step is 4 — Wire the model\n```\n\n```markdown\n## Return\nverdict: fail\nsummary: Step 3 blocked in phase test — 2 failures in HeroModelTest (null title).\nartifacts:\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fimplement.md\nnext_action: run \u002Fdx-step-fix\n```\n",{"name":5,"model":30,"context":49,"description":7,"allowed-tools":50,"argument-hint":53},"fork",[35,33,42,34,51,52],"agent","AEM\u002F*","[Work Item ID or slug (optional — uses most recent if omitted)]","main","5c642842a92100dc7561ae0682a152a74846e186","plugins\u002Fdx-core\u002Fskills\u002Fdx-step",3,"https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow","https:\u002F\u002Fgithub.com\u002Feasingthemes","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fdraganfilipovic\u002F","Agentic SDLC platform in production. I build agent-ready codebases. AEM MCP Server author.","2026-11-11 09:59:48",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add easingthemes\u002Fdx-aem-flow --skill dx-step",{"tool":69,"command":70},"bunx","bunx skills add easingthemes\u002Fdx-aem-flow --skill dx-step",{"tool":72,"command":73},"pnpm","pnpm dlx skills add easingthemes\u002Fdx-aem-flow --skill dx-step","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-core\u002Fskills\u002Fdx-step\u002FSKILL.md",true,[],[78,98,118,137,153,167],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":44},"01M6H48W19F46A7B7TSSQAMYRW","dx-hub-status","Show hub dispatch status — which repos are running, done, blocked or failed. Use for 'hub status', 'what's running'.","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-hub\u002Fskills\u002Fdx-hub-status\u002FSKILL.md",[],[25,85,86,32,87,88,89,90,91,92,28,93,94,26,95,35,34,96,97],"dx hub status","hub","hub status","which","show","for","ticket","clean","done","Bash","dispatch","repos","grep",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":44},"01M6H48R6ZH7YMVPMVWMMWT3RA","dx-hub-init","Initialize a hub directory for multi-repo orchestration. Discovers sibling repos, merges configs, validates CLI compatibility. Use when setting up hub mode for the first time. Trigger on \"init hub\", \"set up hub\", \"multi-repo setup\".","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-hub\u002Fskills\u002Fdx-hub-init\u002FSKILL.md",[],[105,106,25,107,86,108,43,109,110,111,112,113,114,115,94,116,117,35,34,33],"init","hub init","dx hub init","SET","mode","default","up","repo setup","orchestration","configure","multi-repo","cli","directory",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":125,"publishedAt":44},"01M6H48K267CWEF8YNN3Y49BVT","dx-hub-dispatch","Dispatch a ticket to several repos — open an independent Claude session per repo in VS Code terminals. Use for 'hub dispatch', 'work on ticket across repos'.","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-hub\u002Fskills\u002Fdx-hub-dispatch\u002FSKILL.md",[124],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,126,95,86,127,90,128,129,130,91,131,132,28,133,94,134,135,136,26,39],"dx hub dispatch","ado","repo","work on","session","open","MCP","URL","vscode","code","across",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":44},"01M6H48FAWKTT6AAWT3H80ZKE0","dx-hub-config","View and edit hub configuration — add repos, adjust terminal delay. Use to manage hub settings. Trigger on \"hub config\", \"add repo to hub\", \"terminal delay\".","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-hub\u002Fskills\u002Fdx-hub-config\u002FSKILL.md",[],[25,144,86,145,89,146,128,147,148,149,150,28,114,94,151,35,152,34,33,96],"dx hub config","config","view","manage","trigger","true","adjust","terminal","settings",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":44},"01M6H48BNMYEJY6CCWPYHNQDAT","dx-discover-repos","Resolve which repos a work item touches (explicit directive → simple block → cross-repo table → LLM). Used by the KAI-HUB router to fan an agent out across repos; 'which repos'.","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-hub\u002Fskills\u002Fdx-discover-repos\u002FSKILL.md",[],[160,25,161,96,88,128,136,162,26,163,39,164,86,165,30,166],"discover","dx discover repos","router","directive","simple","block","table",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":174,"publishedAt":44},"01M6H487QA1FDSBT1HTZGW4HAQ","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.","https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-core\u002Fskills\u002Fdx-upgrade\u002FSKILL.md",[173],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[175,25,176,177,178,42,179,180,181,182,35,34,33,183,184,185,186,28,187,188],"upgrade","dx upgrade","project","actions","fix","files","auto","run","list","doctor","manual","missing","plugin","plugins"]