# Duc01226 Easyplatform Fix Issue > > **[IMPORTANT]** Use `TaskCreate` to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip. - Skill: `tomevault-io/duc01226-easyplatform-fix-issue` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/duc01226-easyplatform-fix-issue` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/duc01226-easyplatform-fix-issue/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/duc01226-easyplatform-fix-issue --- > **[IMPORTANT]** Use `TaskCreate` to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip. > **Understand Code First** — HARD-GATE: Do NOT write, plan, or fix until you READ existing code. > > 1. Search 3+ similar patterns (`grep`/`glob`) — cite `file:line` evidence > 2. Read existing files in target area — understand structure, base classes, conventions > 3. Run `python .claude/scripts/code_graph trace --direction both --json` when `.code-graph/graph.db` exists > 4. Map dependencies via `connections` or `callers_of` — know what depends on your target > 5. Write investigation to `.ai/workspace/analysis/` for non-trivial tasks (3+ files) > 6. Re-read analysis file before implementing — never work from memory alone > 7. NEVER invent new patterns when existing ones work — match exactly or document deviation > > **BLOCKED until:** `- [ ]` Read target files `- [ ]` Grep 3+ patterns `- [ ]` Graph trace (if graph.db exists) `- [ ]` Assumptions verified with evidence > **Evidence-Based Reasoning** — Speculation is FORBIDDEN. Every claim needs proof. > > 1. Cite `file:line`, grep results, or framework docs for EVERY claim > 2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend > 3. Cross-service validation required for architectural changes > 4. "I don't have enough evidence" is valid and expected output > > **BLOCKED until:** `- [ ]` Evidence file path (`file:line`) `- [ ]` Grep search performed `- [ ]` 3+ similar patterns found `- [ ]` Confidence level stated > > **Forbidden without proof:** "obviously", "I think", "should be", "probably", "this is because" > **If incomplete →** output: `"Insufficient evidence. Verified: [...]. Not verified: [...]."` - `docs/project-reference/domain-entities-reference.md` — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models) (content auto-injected by hook — check for [Injected: ...] header before reading) > **Estimation** — Modified Fibonacci: 1(trivial) → 2(small) → 3(medium) → 5(large) → 8(very large) → 13(epic, SHOULD split) → 21(MUST ATTENTION split). Output `story_points` and `complexity` in plan frontmatter. Complexity auto-derived: 1-2=Low, 3-5=Medium, 8=High, 13+=Critical. > **Skill Variant:** Variant of `/fix` — debug and fix GitHub issues with systematic investigation. ## Quick Summary **Goal:** Investigate and fix bugs reported as GitHub issues with full traceability. **Workflow:** 1. **Fetch** — Read GitHub issue details (title, description, reproduction steps) 2. **Reproduce** — Trace the reported behavior in code 3. **Fix** — Apply fix with root cause evidence **Key Rules:** - Debug Mindset: every claim needs `file:line` evidence - Link fix back to the GitHub issue for traceability - Verify fix addresses the specific reproduction steps from the issue > **Root Cause Debugging** — Systematic approach, never guess-and-check. > > 1. **Reproduce** — Confirm the issue exists with evidence (error message, stack trace, screenshot) > 2. **Isolate** — Narrow to specific file/function/line using binary search + graph trace > 3. **Trace** — Follow data flow from input to failure point. Read actual code, don't infer. > 4. **Hypothesize** — Form theory with confidence %. State what evidence supports/contradicts it > 5. **Verify** — Test hypothesis with targeted grep/read. One variable at a time. > 6. **Fix** — Address root cause, not symptoms. Verify fix doesn't break callers via graph `connections` > > **NEVER:** Guess without evidence. Fix symptoms instead of cause. Skip reproduction step. $ARGUMENTS ## Debug Mindset (NON-NEGOTIABLE) **Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).** - Do NOT assume the first hypothesis is correct — verify with actual code traces - Every root cause claim must include `file:line` evidence - If you cannot prove a root cause with a code trace, state "hypothesis, not confirmed" - Question assumptions: "Is this really the cause?" → trace the actual execution path - Challenge completeness: "Are there other contributing factors?" → check related code paths - No "should fix it" without proof — verify the fix addresses the traced root cause ## ⚠️ MANDATORY: Confidence & Evidence Gate **MANDATORY IMPORTANT MUST ATTENTION** declare `Confidence: X%` with evidence list + `file:line` proof for EVERY claim. **95%+** recommend freely | **80-94%** with caveats | **60-79%** list unknowns | **<60% STOP — gather more evidence.** > **⚠️ Validate Before Fix (NON-NEGOTIABLE):** After root cause analysis, MUST ATTENTION present findings + proposed fix to user via `AskUserQuestion` and get explicit approval BEFORE any code changes. No silent fixes. Activate `debug-investigate` skill and follow its workflow. **IMPORTANT**: Always use external memory at `.ai/workspace/analysis/issue-[number].analysis.md` for structured analysis. **Re-read ENTIRE analysis file before proposing any fix** — this prevents knowledge loss. **🛑 Present root cause + proposed fix → `AskUserQuestion` → wait for user approval before implementing.** See `.claude/docs/AI-DEBUGGING-PROTOCOL.md` for comprehensive guidelines. ## ⚠️ MANDATORY: Post-Fix Verification **After applying the fix, MUST ATTENTION run `/prove-fix`** — build code proof traces per change with confidence scores. Never skip. --- ## Standalone Review Gate (Non-Workflow Only) > **MANDATORY IMPORTANT MUST ATTENTION:** If this skill is called **outside a workflow** (standalone `/fix-issue`), you MUST ATTENTION create a `TaskCreate` todo task for `/review-changes` as the **last task** in your task list. This ensures all changes are reviewed before commit even without a workflow enforcing it. > > If already running inside a workflow (e.g., `bugfix`), skip this — the workflow sequence handles `/review-changes` at the appropriate step. ## Closing Reminders **MANDATORY IMPORTANT MUST ATTENTION** break work into small todo tasks using `TaskCreate` BEFORE starting. **MANDATORY IMPORTANT MUST ATTENTION** validate decisions with user via `AskUserQuestion` — never auto-decide. **MANDATORY IMPORTANT MUST ATTENTION** add a final review todo task to verify work quality. **MANDATORY IMPORTANT MUST ATTENTION** READ the following files before starting: - **MANDATORY IMPORTANT MUST ATTENTION** search 3+ existing patterns and read code BEFORE any modification. Run graph trace when graph.db exists. - **MANDATORY IMPORTANT MUST ATTENTION** cite `file:line` evidence for every claim. Confidence >80% to act, <60% = do NOT recommend. - **MANDATORY IMPORTANT MUST ATTENTION** include `story_points` and `complexity` in plan frontmatter. SP > 8 = split. --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/duc01226) — claim your Tome and manage your conversions.