$npx -y skills add pssah4/digital-innovation-agents --skill codingHandoff skill and bug-capture entry point: loads plan-context.md and all design artifacts, performs a critical review against the real codebase, and ensures continuous writeback to the artifacts during and after implementation. Also the entry point when a bug is reported outside
| 1 | # Coding -- Review, Handoff & Living Documents |
| 2 | |
| 3 | This skill has two entry conditions: |
| 4 | |
| 5 | 1. **Implementation entry** (the typical case): a FEATURE / IMP / ADR / |
| 6 | FIX is ready to be built. The full review-implement-writeback flow |
| 7 | below applies. |
| 8 | 2. **Bug-capture entry** (no implementation required): the user |
| 9 | reports a bug outside of an active implementation run. The skill |
| 10 | captures the FIX artefact (BACKLOG row + FIX detail file + branch) |
| 11 | and lets the user decide whether to implement now or later. See |
| 12 | "Bug-capture entry point" in MANDATORY Phase 0 below. |
| 13 | |
| 14 | The triggers in the description ("implement", "code", "build feature") |
| 15 | cover case 1. Phrases like "Bug X", "Fix gefunden", "es gibt einen |
| 16 | Fehler in FEAT-..." cover case 2. |
| 17 | |
| 18 | ## MANDATORY Pre-Phase 0: Branch and item check |
| 19 | |
| 20 | Coding implements a specific FEAT / FIX / IMP from the backlog. |
| 21 | Run the team-workflow check (full rules: |
| 22 | `skills/project-conventions/references/team-workflow.md`): |
| 23 | |
| 24 | 1. Identify the active item. For mid-cycle FIX or IMP discovered |
| 25 | during coding, write the BACKLOG row first. |
| 26 | 2. Verify the branch matches `feature/<item-id-lower>-<slug>` (or |
| 27 | `fix/...` / `chore/...`). On a wrong branch, AskUserQuestion to |
| 28 | switch. |
| 29 | 3. Skill-triggered GitHub integration: |
| 30 | |
| 31 | ``` |
| 32 | python3 tools/github-integration/flow.py create-issue --item <ID> |
| 33 | python3 tools/github-integration/flow.py open-draft-pr --item <ID> |
| 34 | ``` |
| 35 | |
| 36 | 4. At Handoff Ritual end, tag the phase: |
| 37 | |
| 38 | ``` |
| 39 | python3 tools/github-integration/flow.py tag-phase --item <ID> --phase code |
| 40 | ``` |
| 41 | |
| 42 | 5. Write `.git/dia-active-skill` so subsequent invocations stay silent. |
| 43 | |
| 44 | ## MANDATORY Phase 0: Artifact triage |
| 45 | |
| 46 | Before any code, doc, or spec change, the skill determines which |
| 47 | artifact category the work falls into: |
| 48 | |
| 49 | 1. **New FEATURE** (user-facing capability that did not exist before). |
| 50 | 2. **IMPROVEMENT (IMP)** on an existing feature (refactor, performance, |
| 51 | doc drift, tests, config). |
| 52 | 3. **FIX** for a bug or drift on an existing feature. |
| 53 | 4. **ADR** when the work is an architecture decision. |
| 54 | |
| 55 | **Rule:** if the assignment cannot be derived unambiguously from the |
| 56 | user prompt, the skill asks one short question before anything else |
| 57 | (in the user's working language; the English wording below is a |
| 58 | template): |
| 59 | |
| 60 | > "Is this a new feature, an improvement on an existing feature, or |
| 61 | > a fix for a bug? If feature or IMP/FIX: which feature and which |
| 62 | > epic?" |
| 63 | |
| 64 | No code or spec change without this assignment. FIX and IMP require |
| 65 | `feature:` and `epic:` in the frontmatter. Details on the decision |
| 66 | tree and exceptions live in |
| 67 | `skills/project-conventions/references/graph-invariants.md` |
| 68 | (section "Artifact triage at entry point"). |
| 69 | |
| 70 | ### Bug-capture entry point (no implementation required) |
| 71 | |
| 72 | `/coding` is also the entry point when the user reports a bug |
| 73 | **outside** of an active implementation run ("ich habe einen Bug in |
| 74 | Feature X gefunden", "Login bricht ab"). The skill MUST be able to |
| 75 | capture the bug without forcing the user into an immediate fix. Flow: |
| 76 | |
| 77 | 1. Run the same Phase 0 triage. The user's prompt usually maps to FIX. |
| 78 | 2. Identify the affected `FEAT-{ee}-{ff}` (ask if unclear). |
| 79 | 3. Write the BACKLOG row first (status `Ready`, phase `Building`, |
| 80 | priority from the user, Source `BUG`). |
| 81 | 4. Create the detail file at |
| 82 | `_devprocess/requirements/fixes/FIX-{ee}-{ff}-{nn}-{slug}.md` from |
| 83 | `templates/FIX-TEMPLATE.md`. Fill Symptom and what is currently |
| 84 | known about the cause; leave Fix and Regression test empty. |
| 85 | 5. Run the phase-end commit (per `team-workflow.md`) with message |
| 86 | `chore(fix): FIX-{ee}-{ff}-{nn} bug captured`. The commit creates |
| 87 | the `fix/<id-lower>-<slug>` branch via the commit-boundary check. |
| 88 | 6. Ask the user: "Bug erfasst. Soll ich jetzt den Fix implementieren |
| 89 | (`/coding` Phase 1+ auf diesem Branch), oder reicht die Erfassung |
| 90 | fuer jetzt?" |
| 91 | |
| 92 | If the user picks "nur erfassen", the skill ends after the commit |
| 93 | and the bug waits in the backlog as a regular FIX item. The next |
| 94 | `/coding` invocation on that FIX-ID resumes from Phase 1. |
| 95 | |
| 96 | The capture |