[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H47M1WDYGQ7AVWCYT389SQ":3,"skill-same:01M6H47M1WDYGQ7AVWCYT389SQ":68},{"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":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6H47M1WDYGQ7AVWCYT389SQ","dx-step-fix",null,"Diagnose and fix a blocked step — compile error, test failure, review rejection — directly or by adding corrective steps to implement.md. Use when \u002Fdx-step fails.","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-fix\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"dx step fix","dx","fix","test","id","implement","use","compile","diagnose","sonnet","edit","write","read","work","review","search","error","2026-11-10 10:12:30",false,"---\nname: dx-step-fix\ndescription: \"Diagnose and fix a blocked step — compile error, test failure, review rejection — directly or by adding corrective steps to implement.md. Use when \u002Fdx-step fails.\"\nargument-hint: \"[Work Item ID or slug (optional — uses most recent if omitted)]\"\nallowed-tools: [\"read\", \"edit\", \"search\", \"write\", \"agent\"]\nmodel: sonnet\ncontext: fork\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-fix 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-fix (you are a fork or that subagent), continue below.\n\nYou diagnose and fix issues that blocked a plan step — compilation errors, test failures, or review feedback. You try a direct fix first. If that fails, you escalate to creating corrective steps in implement.md for the step machinery to execute.\n\nYou run forked (`context: fork`): coordinators (`dx-step-all`, `dx-bug-fix`, `dx-agent-all`) read only your final `## Return` block, so every terminal node below ends with one (see **Return** at the end for the verdict mapping). You fix **one** step. Never invoke `Skill(dx-step-fix)`, `\u002Fdx-step` or `\u002Fdx-step-all` yourself. The coordinator owns the loop.\n\nUse ultrathink for this skill — debugging requires deep reasoning about root causes.\n\n## Flow\n\n```dot\ndigraph step_fix {\n    \"Read blocked step from implement.md\" [shape=box];\n    \"Classify error\" [shape=diamond];\n    \"PERMANENT: Mark blocked, report\" [shape=doublecircle];\n    \"TRANSIENT: Suggest retry\" [shape=doublecircle];\n    \"Gather error context\" [shape=box];\n    \"Diagnose root cause\" [shape=box];\n    \"Load conventions\" [shape=box];\n    \"Apply fix\" [shape=box];\n    \"Re-verify (build\u002Ftest)\" [shape=box];\n    \"Fix worked?\" [shape=diamond];\n    \"Mark step done + report\" [shape=doublecircle];\n    \"Fix failed — escalate to heal?\" [shape=diamond];\n    \"Determine failure type\" [shape=diamond];\n    \"Analyze blocked step with different approach\" [shape=box];\n    \"Group review issues by file cluster\" [shape=box];\n    \"Create corrective steps in implement.md\" [shape=box];\n    \"Corrective steps viable?\" [shape=diamond];\n    \"Return: healed (new steps)\" [shape=doublecircle];\n    \"Return: unrecoverable\" [shape=doublecircle];\n\n    \"Read blocked step from implement.md\" -> \"Classify error\";\n    \"Classify error\" -> \"PERMANENT: Mark blocked, report\" [label=\"PERMANENT\"];\n    \"Classify error\" -> \"TRANSIENT: Suggest retry\" [label=\"TRANSIENT\"];\n    \"Classify error\" -> \"Gather error context\" [label=\"VALIDATION\"];\n    \"Gather error context\" -> \"Diagnose root cause\";\n    \"Diagnose root cause\" -> \"Load conventions\";\n    \"Load conventions\" -> \"Apply fix\";\n    \"Apply fix\" -> \"Re-verify (build\u002Ftest)\";\n    \"Re-verify (build\u002Ftest)\" -> \"Fix worked?\";\n    \"Fix worked?\" -> \"Mark step done + report\" [label=\"yes\"];\n    \"Fix worked?\" -> \"Fix failed — escalate to heal?\" [label=\"no\"];\n    \"Fix failed — escalate to heal?\" -> \"Return: unrecoverable\" [label=\"no (environment\u002Fconfig)\"];\n    \"Fix failed — escalate to heal?\" -> \"Determine failure type\" [label=\"yes\"];\n    \"Determine failure type\" -> \"Analyze blocked step with different approach\" [label=\"step-blocked\"];\n    \"Determine failure type\" -> \"Group review issues by file cluster\" [label=\"review-failed\"];\n    \"Analyze blocked step with different approach\" -> \"Corrective steps viable?\";\n    \"Group review issues by file cluster\" -> \"Create corrective steps in implement.md\";\n    \"Create corrective steps in implement.md\" -> \"Corrective steps viable?\";\n    \"Corrective steps viable?\" -> \"Return: healed (new steps)\" [label=\"yes\"];\n    \"Corrective steps viable?\" -> \"Return: unrecoverable\" [label=\"no\"];\n}\n```\n\n## Node Details\n\n### Read blocked step from implement.md\n\n```bash\nSPEC_DIR=$(bash .ai\u002Flib\u002Fdx-common.sh find-spec-dir $ARGUMENTS)\n```\n\nRead `implement.md` from `$SPEC_DIR`. Find the step that needs fixing:\n- First `**Status:** blocked` step, OR\n- First `**Status:** in-progress` step (interrupted), OR\n- Last `**Status:** done` step if the issue is from post-step testing\u002Freview\n\n### Classify error\n\nBefore attempting any fix, classify the error using `..\u002F..\u002Fshared\u002Ferror-handling.md`:\n- If **PERMANENT** → go to \"PERMANENT: Mark blocked, report\"\n- If **TRANSIENT** → go to \"TRANSIENT: Suggest retry\"\n- If **VALIDATION** → proceed to \"Gather error context\"\n\n### PERMANENT: Mark blocked, report\n\nDo not attempt fix. Print: \"PERMANENT error: [category]. Manual intervention required: [suggestion].\" Then end with `## Return` — `verdict: fail`, `next_action: stop — unrecoverable`.\n\n### TRANSIENT: Suggest retry\n\nSuggest retry, not code fix. Print: \"TRANSIENT error: [category]. Re-run the step.\" Then end with `## Return` — `verdict: fail`, `next_action: retry step \u003CN>`.\n\n### Gather error context\n\nRead ALL available error information:\n- Compilation errors from the build output\n- Test failure output (assertion messages, stack traces)\n- Review feedback (specific issues listed)\n\nAlso read:\n- The step's **What** instructions (what was intended)\n- The step's **Files** list\n- The actual current state of those files\n\n### Diagnose root cause\n\nUse extended thinking to analyze:\n1. What was the step trying to do?\n2. What went wrong?\n3. Is the error in the code written for this step, or in the plan itself?\n4. What's the minimal fix?\n\n#### Debugging Methodology\n\nIf `superpowers:systematic-debugging` is available, invoke it to structure the diagnosis.\n\n**Fallback (if superpowers not installed):** Follow this 4-phase approach:\n1. **Gather evidence:** Read errors completely, reproduce consistently, check recent changes, trace data flow at component boundaries.\n2. **Find references:** Locate working similar code, compare line-by-line, identify what differs.\n3. **Test hypothesis:** Form a single hypothesis in writing, test minimally (1 variable at a time).\n4. **Fix once:** Create failing test, implement single fix, verify. If 3+ fixes fail — stop and question architecture, not symptoms.\n\n### Load conventions\n\nBefore applying any fix, read the coding standards for the file types being modified:\n\n1. Check `.claude\u002Frules\u002F` — read rules matching the file types (e.g., `fe-javascript.md` for `.js`, `fe-styles.md` for `.scss`, `accessibility.md` for a11y fixes)\n2. If `.github\u002Finstructions\u002F` exists, read the relevant instruction file for deeper framework patterns (e.g., `fe.javascript.instructions.md` for `.js`, `fe.css-styles.md` for `.scss`)\n3. If the fix involves AEM frontend components and `shared\u002Faem-dom-rules.md` exists (from the dx-aem plugin), read it for DOM traversal constraints — especially for modals, overlays, focus traps, and inert management\n\nThese conventions constrain how the fix should be written. A fix that solves the error but violates project conventions is not acceptable.\n\n### Apply fix\n\nImplement the fix:\n- If it's a code error → fix the code following the conventions loaded in the previous step\n- If it's a plan error (wrong file path, wrong property name) → fix the code to match reality AND note the plan deviation\n- If it's an environment issue (missing dependency, wrong config) → report and suggest manual resolution\n\n### Re-verify (build\u002Ftest)\n\nRun the same verification that failed. Read the project's build\u002Ftest commands from `.ai\u002Fconfig.yaml` if needed.\n\n### Fix worked?\n\nDid the re-verification pass? Check exit code and output for success\u002Ffailure indicators.\n\n### Mark step done + report\n\nUpdate the step's status to `done` in implement.md and print the summary:\n\n```markdown\n## Fix Result: Step \u003CN>\n\n**Issue:** \u003Cone-line description of the problem>\n**Root cause:** \u003Cone-line diagnosis>\n**Fix applied:** \u003Cone-line description of what was changed>\n**Verification:** PASSED\n```\n\nThen end with `## Return` — `verdict: pass`, `next_action: continue`.\n\n### Fix failed — escalate to heal?\n\nThe direct fix didn't work. Decide whether to escalate to heal (creating corrective steps):\n\n- **yes** → The issue is fixable by a different code approach. Proceed to \"Determine failure type\".\n- **no** → The issue is NOT fixable by code changes (missing dependency, environment issue, infrastructure problem). Go to \"Return: unrecoverable\".\n\nFirst, update the step's status to `blocked` with a diagnosis in implement.md:\n```\n**Blocked:** \u003Cdiagnosis of what went wrong and why the fix didn't work>\n```\n\n### Determine failure type\n\nDetect the failure type from context:\n\n- **step-blocked** → The step has `**Status:** blocked` with a `**Blocked:**` diagnosis note (compilation error, test failure, or step execution issue). Go to \"Analyze blocked step with different approach\".\n- **review-failed** → The failure came from review feedback (review cycle failure with Critical\u002FImportant issues). Go to \"Group review issues by file cluster\".\n\n### Analyze blocked step with different approach\n\nThe direct fix failed. Now analyze with a fundamentally different approach.\n\n1. Re-read the `**Blocked:**` note — this explains what was tried and why it failed\n2. Re-read the step's `**What**` instructions and `**Files**` list\n3. Re-read the actual current state of those files\n\nUse extended thinking to find a DIFFERENT approach:\n\n1. **What was attempted?** — What did the direct fix try to do?\n2. **Why did it fail?** — Was the fix wrong? Was the diagnosis wrong? Is there a deeper issue?\n3. **What's different now?** — What approach would succeed where the previous one failed?\n4. **Is it fixable by code changes?** — Or is it an environment\u002Fconfig\u002Fdependency issue?\n\nAppend ONE corrective step immediately after the blocked step in implement.md:\n\n```markdown\n### Step \u003CN>h: Heal — \u003Cdescriptive title>\n**Status:** pending\n**Files:** \u003Cfiles that need changes>\n**What:**\n\u003CSpecific, different fix approach. Reference the failed attempt and explain why this approach is different.>\n**Why:** Auto-generated by step-fix heal. Previous fix attempt failed because: \u003Creason from blocked note>.\n**Test:** \u003Cverification command>\n```\n\n**Numbering:** Use `\u003Coriginal-step-number>h` (e.g., Step `3h` heals Step 3). If a second healing is needed, use `\u003Coriginal-step-number>h2`.\n\n### Group review issues by file cluster\n\nThe failure came from review feedback after fix cycles failed.\n\n1. Read the review failure output (passed as context by the caller)\n2. Parse each remaining Critical and Important issue — file, line, description\n3. Read the affected files to understand the current state\n\nUse extended thinking to diagnose:\n\n1. **What was attempted?** — What did the review fix cycles try to do?\n2. **Why did it fail?** — Were the fixes wrong? Is there a deeper issue?\n3. **What's different now?** — What approach would succeed where previous attempts failed?\n4. **Is it fixable by code changes?** — Or is it an environment\u002Fconfig\u002Fdependency issue?\n\n### Create corrective steps in implement.md\n\nGroup related issues by file. Create one corrective step per file or per related cluster:\n\n```markdown\n### Step R\u003CN>: Review fix — \u003Cfile or issue cluster>\n**Status:** pending\n**Files:** \u003Caffected files>\n**What:**\n\u003CSpecific fix instructions for each issue in this cluster. Include file:line references from the review.>\n**Why:** Auto-generated by step-fix heal from review cycle failure. Issues: \u003Ccount> Critical, \u003Ccount> Important.\n**Test:** \u003Cverification command>\n```\n\n**Numbering:** Use `R1`, `R2`, `R3`, etc. for review-fix steps. If a second healing cycle is needed, use `R1b`, `R2b`, etc.\n\n### Corrective steps viable?\n\nEvaluate whether the corrective steps can realistically fix the problem:\n\n- **yes** → The issue is fixable by code changes and the corrective steps use a different approach than the failed attempt. Go to \"Return: healed (new steps)\".\n- **no** → The issue is NOT fixable by code changes (missing dependency, environment issue, architectural flaw requiring plan revision). Go to \"Return: unrecoverable\".\n\n### Return: healed (new steps)\n\nCorrective steps have been appended to implement.md. Print summary:\n\n```markdown\n## Heal Result\n\n**Failure type:** Step blocked \u002F Review failed\n**Root cause:** \u003Cone-line diagnosis>\n**Corrective steps created:** \u003CN>\n**Steps:** \u003Clist of step numbers and titles>\n**Approach:** \u003Chow this differs from the failed attempt>\n```\n\nThen end with `## Return` — `verdict: warn`, `next_action: run corrective steps \u003Clist>`. This is the `healed` result: corrective steps created in implement.md, ready for step to execute.\n\n### Return: unrecoverable\n\nThe issue cannot be auto-fixed. Print summary:\n\n```markdown\n## Fix Result: Step \u003CN>\n\n**Issue:** \u003Cone-line description of the problem>\n**Root cause:** \u003Cone-line diagnosis>\n**Verdict:** Unrecoverable — \u003Creason>\n**Recommendation:** \u003Cwhat the human should investigate>\n```\n\nThen end with `## Return` — `verdict: fail`, `next_action: stop — unrecoverable`. Do NOT create corrective steps. The pipeline stops here.\n\n## Success Criteria\n\n- [ ] Error is resolved — re-verification passes (build\u002Ftest\u002Flint exits 0), OR\n- [ ] Corrective steps created in implement.md with `pending` status (healed), OR\n- [ ] Issue correctly identified as unrecoverable with clear reason\n- [ ] Step status updated in `implement.md`\n- [ ] Fix\u002Fdiagnosis is minimal — only addresses the diagnosed root cause\n- [ ] Root cause diagnosis references actual error output, not speculation\n\n## Examples\n\n### Fix a compilation error\n```\n\u002Fdx-step-fix 2435084\n```\nFinds the blocked step, reads the error (e.g., missing import), applies the fix, re-runs compilation. If it passes, marks the step `done`.\n\n### Fix fails, escalates to heal\n```\n\u002Fdx-step-fix 2435084\n```\nDirect fix attempt fails. Analyzes the failure with a different approach, creates Step `3h` with new instructions. Returns `healed`.\n\n### Heal review failures\n```\n\u002Fdx-step-fix 2435084\n```\nReview found 3 Critical issues after fix cycles failed. Creates Steps `R1` and `R2` (grouped by file) with specific fix instructions. Returns `healed`.\n\n### Unrecoverable issue\n```\n\u002Fdx-step-fix 2435084\n```\nThe failure requires a missing Maven dependency that isn't in the project. Returns `unrecoverable` with recommendation for human intervention.\n\n## Troubleshooting\n\n### Fix changes the feature's behavior\n**Cause:** The root cause is in the plan, not the code — wrong property name, wrong file path, etc.\n**Fix:** The skill fixes code to match reality and notes the plan deviation. Review `implement.md` to correct future steps.\n\n### \"Environment issue — suggest manual resolution\"\n**Cause:** Missing dependency, wrong config, or AEM not running.\n**Fix:** Address the environment issue manually (e.g., install dependency, start AEM), then re-run `\u002Fdx-step-fix`.\n\n### Corrective step also fails\n**Cause:** The healing approach was insufficient, or the root cause is deeper.\n**Fix:** The orchestrator (`dx-step-all`) allows 2 healing cycles per step. If both fail, it stops for human intervention.\n\n### \"The original plan was wrong\"\n**Cause:** The step instructions reference wrong files or wrong API.\n**Fix:** step-fix heals code, not plans. If the plan is fundamentally wrong, it returns `unrecoverable`. Edit `implement.md` manually.\n\n## Rationalizations to Reject\n\n| Thought | Reality |\n|---------|---------|\n| \"The same fix might work if we retry\" | The direct fix already tried. Heal must try a DIFFERENT approach. |\n| \"I'll create many small steps to be thorough\" | Fewer steps = less overhead. Group by file. |\n| \"This is too complex to auto-heal\" | Analyze deeper. If truly unrecoverable, say so explicitly. |\n| \"The original plan was wrong\" | You fix code, not plans. If the plan is flawed, return unrecoverable. |\n\n## Rules\n\n- **One fix attempt, then heal** — try ONE direct fix, re-verify. If still broken, escalate to heal (create corrective steps). Don't loop on direct fixes.\n- **Minimal fix** — fix the immediate issue, don't refactor surrounding code\n- **Read before fixing** — understand the full context before changing anything\n- **Preserve plan intent** — the fix should accomplish what the step intended, not change direction\n- **Update implement.md** — always update the status, whether fixed, healed, or unrecoverable\n- **Be honest about uncertainty** — if you can't determine the root cause, say so\n- **Different approach required** — corrective steps MUST try a different strategy than the failed fix\n- **Include test commands** — every corrective step must have a verification command\n- **Heal creates steps, not code** — the heal escalation only creates steps in implement.md; let step do the actual coding\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`. Coordinators branch on `verdict` first, then on `next_action`:\n\n| Outcome | `verdict` | `next_action` |\n|---|---|---|\n| Fixed — re-verification passed, step `done` | `pass` | `continue` |\n| Healed — corrective steps appended | `warn` | `run corrective steps \u003Clist>` |\n| TRANSIENT — not a code problem | `fail` | `retry step \u003CN>` |\n| PERMANENT \u002F unrecoverable | `fail` | `stop — unrecoverable` |\n\nExample:\n\n```markdown\n## Return\nverdict: warn\nsummary: Step 3 heal — direct fix failed on missing HeroProps export; created corrective step 3h.\nartifacts:\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fimplement.md\nnext_action: run corrective steps 3h\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-fix 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-fix (you are a fork or that subagent), continue below.\n\nYou diagnose and fix issues that blocked a plan step — compilation errors, test failures, or review feedback. You try a direct fix first. If that fails, you escalate to creating corrective steps in implement.md for the step machinery to execute.\n\nYou run forked (`context: fork`): coordinators (`dx-step-all`, `dx-bug-fix`, `dx-agent-all`) read only your final `## Return` block, so every terminal node below ends with one (see **Return** at the end for the verdict mapping). You fix **one** step. Never invoke `Skill(dx-step-fix)`, `\u002Fdx-step` or `\u002Fdx-step-all` yourself. The coordinator owns the loop.\n\nUse ultrathink for this skill — debugging requires deep reasoning about root causes.\n\n## Flow\n\n```dot\ndigraph step_fix {\n    \"Read blocked step from implement.md\" [shape=box];\n    \"Classify error\" [shape=diamond];\n    \"PERMANENT: Mark blocked, report\" [shape=doublecircle];\n    \"TRANSIENT: Suggest retry\" [shape=doublecircle];\n    \"Gather error context\" [shape=box];\n    \"Diagnose root cause\" [shape=box];\n    \"Load conventions\" [shape=box];\n    \"Apply fix\" [shape=box];\n    \"Re-verify (build\u002Ftest)\" [shape=box];\n    \"Fix worked?\" [shape=diamond];\n    \"Mark step done + report\" [shape=doublecircle];\n    \"Fix failed — escalate to heal?\" [shape=diamond];\n    \"Determine failure type\" [shape=diamond];\n    \"Analyze blocked step with different approach\" [shape=box];\n    \"Group review issues by file cluster\" [shape=box];\n    \"Create corrective steps in implement.md\" [shape=box];\n    \"Corrective steps viable?\" [shape=diamond];\n    \"Return: healed (new steps)\" [shape=doublecircle];\n    \"Return: unrecoverable\" [shape=doublecircle];\n\n    \"Read blocked step from implement.md\" -> \"Classify error\";\n    \"Classify error\" -> \"PERMANENT: Mark blocked, report\" [label=\"PERMANENT\"];\n    \"Classify error\" -> \"TRANSIENT: Suggest retry\" [label=\"TRANSIENT\"];\n    \"Classify error\" -> \"Gather error context\" [label=\"VALIDATION\"];\n    \"Gather error context\" -> \"Diagnose root cause\";\n    \"Diagnose root cause\" -> \"Load conventions\";\n    \"Load conventions\" -> \"Apply fix\";\n    \"Apply fix\" -> \"Re-verify (build\u002Ftest)\";\n    \"Re-verify (build\u002Ftest)\" -> \"Fix worked?\";\n    \"Fix worked?\" -> \"Mark step done + report\" [label=\"yes\"];\n    \"Fix worked?\" -> \"Fix failed — escalate to heal?\" [label=\"no\"];\n    \"Fix failed — escalate to heal?\" -> \"Return: unrecoverable\" [label=\"no (environment\u002Fconfig)\"];\n    \"Fix failed — escalate to heal?\" -> \"Determine failure type\" [label=\"yes\"];\n    \"Determine failure type\" -> \"Analyze blocked step with different approach\" [label=\"step-blocked\"];\n    \"Determine failure type\" -> \"Group review issues by file cluster\" [label=\"review-failed\"];\n    \"Analyze blocked step with different approach\" -> \"Corrective steps viable?\";\n    \"Group review issues by file cluster\" -> \"Create corrective steps in implement.md\";\n    \"Create corrective steps in implement.md\" -> \"Corrective steps viable?\";\n    \"Corrective steps viable?\" -> \"Return: healed (new steps)\" [label=\"yes\"];\n    \"Corrective steps viable?\" -> \"Return: unrecoverable\" [label=\"no\"];\n}\n```\n\n## Node Details\n\n### Read blocked step from implement.md\n\n```bash\nSPEC_DIR=$(bash .ai\u002Flib\u002Fdx-common.sh find-spec-dir $ARGUMENTS)\n```\n\nRead `implement.md` from `$SPEC_DIR`. Find the step that needs fixing:\n- First `**Status:** blocked` step, OR\n- First `**Status:** in-progress` step (interrupted), OR\n- Last `**Status:** done` step if the issue is from post-step testing\u002Freview\n\n### Classify error\n\nBefore attempting any fix, classify the error using `..\u002F..\u002Fshared\u002Ferror-handling.md`:\n- If **PERMANENT** → go to \"PERMANENT: Mark blocked, report\"\n- If **TRANSIENT** → go to \"TRANSIENT: Suggest retry\"\n- If **VALIDATION** → proceed to \"Gather error context\"\n\n### PERMANENT: Mark blocked, report\n\nDo not attempt fix. Print: \"PERMANENT error: [category]. Manual intervention required: [suggestion].\" Then end with `## Return` — `verdict: fail`, `next_action: stop — unrecoverable`.\n\n### TRANSIENT: Suggest retry\n\nSuggest retry, not code fix. Print: \"TRANSIENT error: [category]. Re-run the step.\" Then end with `## Return` — `verdict: fail`, `next_action: retry step \u003CN>`.\n\n### Gather error context\n\nRead ALL available error information:\n- Compilation errors from the build output\n- Test failure output (assertion messages, stack traces)\n- Review feedback (specific issues listed)\n\nAlso read:\n- The step's **What** instructions (what was intended)\n- The step's **Files** list\n- The actual current state of those files\n\n### Diagnose root cause\n\nUse extended thinking to analyze:\n1. What was the step trying to do?\n2. What went wrong?\n3. Is the error in the code written for this step, or in the plan itself?\n4. What's the minimal fix?\n\n#### Debugging Methodology\n\nIf `superpowers:systematic-debugging` is available, invoke it to structure the diagnosis.\n\n**Fallback (if superpowers not installed):** Follow this 4-phase approach:\n1. **Gather evidence:** Read errors completely, reproduce consistently, check recent changes, trace data flow at component boundaries.\n2. **Find references:** Locate working similar code, compare line-by-line, identify what differs.\n3. **Test hypothesis:** Form a single hypothesis in writing, test minimally (1 variable at a time).\n4. **Fix once:** Create failing test, implement single fix, verify. If 3+ fixes fail — stop and question architecture, not symptoms.\n\n### Load conventions\n\nBefore applying any fix, read the coding standards for the file types being modified:\n\n1. Check `.claude\u002Frules\u002F` — read rules matching the file types (e.g., `fe-javascript.md` for `.js`, `fe-styles.md` for `.scss`, `accessibility.md` for a11y fixes)\n2. If `.github\u002Finstructions\u002F` exists, read the relevant instruction file for deeper framework patterns (e.g., `fe.javascript.instructions.md` for `.js`, `fe.css-styles.md` for `.scss`)\n3. If the fix involves AEM frontend components and `shared\u002Faem-dom-rules.md` exists (from the dx-aem plugin), read it for DOM traversal constraints — especially for modals, overlays, focus traps, and inert management\n\nThese conventions constrain how the fix should be written. A fix that solves the error but violates project conventions is not acceptable.\n\n### Apply fix\n\nImplement the fix:\n- If it's a code error → fix the code following the conventions loaded in the previous step\n- If it's a plan error (wrong file path, wrong property name) → fix the code to match reality AND note the plan deviation\n- If it's an environment issue (missing dependency, wrong config) → report and suggest manual resolution\n\n### Re-verify (build\u002Ftest)\n\nRun the same verification that failed. Read the project's build\u002Ftest commands from `.ai\u002Fconfig.yaml` if needed.\n\n### Fix worked?\n\nDid the re-verification pass? Check exit code and output for success\u002Ffailure indicators.\n\n### Mark step done + report\n\nUpdate the step's status to `done` in implement.md and print the summary:\n\n```markdown\n## Fix Result: Step \u003CN>\n\n**Issue:** \u003Cone-line description of the problem>\n**Root cause:** \u003Cone-line diagnosis>\n**Fix applied:** \u003Cone-line description of what was changed>\n**Verification:** PASSED\n```\n\nThen end with `## Return` — `verdict: pass`, `next_action: continue`.\n\n### Fix failed — escalate to heal?\n\nThe direct fix didn't work. Decide whether to escalate to heal (creating corrective steps):\n\n- **yes** → The issue is fixable by a different code approach. Proceed to \"Determine failure type\".\n- **no** → The issue is NOT fixable by code changes (missing dependency, environment issue, infrastructure problem). Go to \"Return: unrecoverable\".\n\nFirst, update the step's status to `blocked` with a diagnosis in implement.md:\n```\n**Blocked:** \u003Cdiagnosis of what went wrong and why the fix didn't work>\n```\n\n### Determine failure type\n\nDetect the failure type from context:\n\n- **step-blocked** → The step has `**Status:** blocked` with a `**Blocked:**` diagnosis note (compilation error, test failure, or step execution issue). Go to \"Analyze blocked step with different approach\".\n- **review-failed** → The failure came from review feedback (review cycle failure with Critical\u002FImportant issues). Go to \"Group review issues by file cluster\".\n\n### Analyze blocked step with different approach\n\nThe direct fix failed. Now analyze with a fundamentally different approach.\n\n1. Re-read the `**Blocked:**` note — this explains what was tried and why it failed\n2. Re-read the step's `**What**` instructions and `**Files**` list\n3. Re-read the actual current state of those files\n\nUse extended thinking to find a DIFFERENT approach:\n\n1. **What was attempted?** — What did the direct fix try to do?\n2. **Why did it fail?** — Was the fix wrong? Was the diagnosis wrong? Is there a deeper issue?\n3. **What's different now?** — What approach would succeed where the previous one failed?\n4. **Is it fixable by code changes?** — Or is it an environment\u002Fconfig\u002Fdependency issue?\n\nAppend ONE corrective step immediately after the blocked step in implement.md:\n\n```markdown\n### Step \u003CN>h: Heal — \u003Cdescriptive title>\n**Status:** pending\n**Files:** \u003Cfiles that need changes>\n**What:**\n\u003CSpecific, different fix approach. Reference the failed attempt and explain why this approach is different.>\n**Why:** Auto-generated by step-fix heal. Previous fix attempt failed because: \u003Creason from blocked note>.\n**Test:** \u003Cverification command>\n```\n\n**Numbering:** Use `\u003Coriginal-step-number>h` (e.g., Step `3h` heals Step 3). If a second healing is needed, use `\u003Coriginal-step-number>h2`.\n\n### Group review issues by file cluster\n\nThe failure came from review feedback after fix cycles failed.\n\n1. Read the review failure output (passed as context by the caller)\n2. Parse each remaining Critical and Important issue — file, line, description\n3. Read the affected files to understand the current state\n\nUse extended thinking to diagnose:\n\n1. **What was attempted?** — What did the review fix cycles try to do?\n2. **Why did it fail?** — Were the fixes wrong? Is there a deeper issue?\n3. **What's different now?** — What approach would succeed where previous attempts failed?\n4. **Is it fixable by code changes?** — Or is it an environment\u002Fconfig\u002Fdependency issue?\n\n### Create corrective steps in implement.md\n\nGroup related issues by file. Create one corrective step per file or per related cluster:\n\n```markdown\n### Step R\u003CN>: Review fix — \u003Cfile or issue cluster>\n**Status:** pending\n**Files:** \u003Caffected files>\n**What:**\n\u003CSpecific fix instructions for each issue in this cluster. Include file:line references from the review.>\n**Why:** Auto-generated by step-fix heal from review cycle failure. Issues: \u003Ccount> Critical, \u003Ccount> Important.\n**Test:** \u003Cverification command>\n```\n\n**Numbering:** Use `R1`, `R2`, `R3`, etc. for review-fix steps. If a second healing cycle is needed, use `R1b`, `R2b`, etc.\n\n### Corrective steps viable?\n\nEvaluate whether the corrective steps can realistically fix the problem:\n\n- **yes** → The issue is fixable by code changes and the corrective steps use a different approach than the failed attempt. Go to \"Return: healed (new steps)\".\n- **no** → The issue is NOT fixable by code changes (missing dependency, environment issue, architectural flaw requiring plan revision). Go to \"Return: unrecoverable\".\n\n### Return: healed (new steps)\n\nCorrective steps have been appended to implement.md. Print summary:\n\n```markdown\n## Heal Result\n\n**Failure type:** Step blocked \u002F Review failed\n**Root cause:** \u003Cone-line diagnosis>\n**Corrective steps created:** \u003CN>\n**Steps:** \u003Clist of step numbers and titles>\n**Approach:** \u003Chow this differs from the failed attempt>\n```\n\nThen end with `## Return` — `verdict: warn`, `next_action: run corrective steps \u003Clist>`. This is the `healed` result: corrective steps created in implement.md, ready for step to execute.\n\n### Return: unrecoverable\n\nThe issue cannot be auto-fixed. Print summary:\n\n```markdown\n## Fix Result: Step \u003CN>\n\n**Issue:** \u003Cone-line description of the problem>\n**Root cause:** \u003Cone-line diagnosis>\n**Verdict:** Unrecoverable — \u003Creason>\n**Recommendation:** \u003Cwhat the human should investigate>\n```\n\nThen end with `## Return` — `verdict: fail`, `next_action: stop — unrecoverable`. Do NOT create corrective steps. The pipeline stops here.\n\n## Success Criteria\n\n- [ ] Error is resolved — re-verification passes (build\u002Ftest\u002Flint exits 0), OR\n- [ ] Corrective steps created in implement.md with `pending` status (healed), OR\n- [ ] Issue correctly identified as unrecoverable with clear reason\n- [ ] Step status updated in `implement.md`\n- [ ] Fix\u002Fdiagnosis is minimal — only addresses the diagnosed root cause\n- [ ] Root cause diagnosis references actual error output, not speculation\n\n## Examples\n\n### Fix a compilation error\n```\n\u002Fdx-step-fix 2435084\n```\nFinds the blocked step, reads the error (e.g., missing import), applies the fix, re-runs compilation. If it passes, marks the step `done`.\n\n### Fix fails, escalates to heal\n```\n\u002Fdx-step-fix 2435084\n```\nDirect fix attempt fails. Analyzes the failure with a different approach, creates Step `3h` with new instructions. Returns `healed`.\n\n### Heal review failures\n```\n\u002Fdx-step-fix 2435084\n```\nReview found 3 Critical issues after fix cycles failed. Creates Steps `R1` and `R2` (grouped by file) with specific fix instructions. Returns `healed`.\n\n### Unrecoverable issue\n```\n\u002Fdx-step-fix 2435084\n```\nThe failure requires a missing Maven dependency that isn't in the project. Returns `unrecoverable` with recommendation for human intervention.\n\n## Troubleshooting\n\n### Fix changes the feature's behavior\n**Cause:** The root cause is in the plan, not the code — wrong property name, wrong file path, etc.\n**Fix:** The skill fixes code to match reality and notes the plan deviation. Review `implement.md` to correct future steps.\n\n### \"Environment issue — suggest manual resolution\"\n**Cause:** Missing dependency, wrong config, or AEM not running.\n**Fix:** Address the environment issue manually (e.g., install dependency, start AEM), then re-run `\u002Fdx-step-fix`.\n\n### Corrective step also fails\n**Cause:** The healing approach was insufficient, or the root cause is deeper.\n**Fix:** The orchestrator (`dx-step-all`) allows 2 healing cycles per step. If both fail, it stops for human intervention.\n\n### \"The original plan was wrong\"\n**Cause:** The step instructions reference wrong files or wrong API.\n**Fix:** step-fix heals code, not plans. If the plan is fundamentally wrong, it returns `unrecoverable`. Edit `implement.md` manually.\n\n## Rationalizations to Reject\n\n| Thought | Reality |\n|---------|---------|\n| \"The same fix might work if we retry\" | The direct fix already tried. Heal must try a DIFFERENT approach. |\n| \"I'll create many small steps to be thorough\" | Fewer steps = less overhead. Group by file. |\n| \"This is too complex to auto-heal\" | Analyze deeper. If truly unrecoverable, say so explicitly. |\n| \"The original plan was wrong\" | You fix code, not plans. If the plan is flawed, return unrecoverable. |\n\n## Rules\n\n- **One fix attempt, then heal** — try ONE direct fix, re-verify. If still broken, escalate to heal (create corrective steps). Don't loop on direct fixes.\n- **Minimal fix** — fix the immediate issue, don't refactor surrounding code\n- **Read before fixing** — understand the full context before changing anything\n- **Preserve plan intent** — the fix should accomplish what the step intended, not change direction\n- **Update implement.md** — always update the status, whether fixed, healed, or unrecoverable\n- **Be honest about uncertainty** — if you can't determine the root cause, say so\n- **Different approach required** — corrective steps MUST try a different strategy than the failed fix\n- **Include test commands** — every corrective step must have a verification command\n- **Heal creates steps, not code** — the heal escalation only creates steps in implement.md; let step do the actual coding\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`. Coordinators branch on `verdict` first, then on `next_action`:\n\n| Outcome | `verdict` | `next_action` |\n|---|---|---|\n| Fixed — re-verification passed, step `done` | `pass` | `continue` |\n| Healed — corrective steps appended | `warn` | `run corrective steps \u003Clist>` |\n| TRANSIENT — not a code problem | `fail` | `retry step \u003CN>` |\n| PERMANENT \u002F unrecoverable | `fail` | `stop — unrecoverable` |\n\nExample:\n\n```markdown\n## Return\nverdict: warn\nsummary: Step 3 heal — direct fix failed on missing HeroProps export; created corrective step 3h.\nartifacts:\n  - .ai\u002Fspecs\u002F2490722-microsite\u002Fimplement.md\nnext_action: run corrective steps 3h\n```\n",{"name":5,"model":28,"context":41,"description":7,"allowed-tools":42,"argument-hint":44},"fork",[31,29,34,30,43],"agent","[Work Item ID or slug (optional — uses most recent if omitted)]","main","5c642842a92100dc7561ae0682a152a74846e186","plugins\u002Fdx-core\u002Fskills\u002Fdx-step-fix",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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add easingthemes\u002Fdx-aem-flow --skill dx-step-fix",{"tool":60,"command":61},"bunx","bunx skills add easingthemes\u002Fdx-aem-flow --skill dx-step-fix",{"tool":63,"command":64},"pnpm","pnpm dlx skills add easingthemes\u002Fdx-aem-flow --skill dx-step-fix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Feasingthemes\u002Fdx-aem-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fdx-core\u002Fskills\u002Fdx-step-fix\u002FSKILL.md",true,[],[69,90,111,134,150,164],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":36},"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",[],[20,76,77,78,79,80,81,82,83,84,25,85,86,23,87,31,30,88,89],"dx hub status","hub","status","hub status","which","show","for","ticket","clean","done","Bash","dispatch","repos","grep",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":36},"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",[],[97,98,20,99,77,100,101,102,103,104,105,106,107,108,86,109,110,31,30,29],"init","hub init","dx hub init","SET","time","mode","default","up","repo setup","orchestration","configure","multi-repo","cli","directory",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":36},"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",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,123,87,77,124,82,125,126,127,83,128,129,25,130,86,131,132,133,23,32],"dx hub dispatch","ado","repo","work on","session","open","MCP","URL","vscode","code","across",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":36},"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",[],[20,141,77,142,81,143,125,144,145,146,147,25,107,86,148,31,149,30,29,88],"dx hub config","config","view","manage","trigger","true","adjust","terminal","settings",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":36},"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",[],[157,20,158,88,80,125,133,159,23,160,32,161,77,162,28,163],"discover","dx discover repos","router","directive","simple","block","table",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":36},"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",[170],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[172,20,173,174,175,34,21,176,177,178,31,30,29,179,180,181,182,25,183,184],"upgrade","dx upgrade","project","actions","files","auto","run","list","doctor","manual","missing","plugin","plugins"]