lenneTech · kaihaase · Aug 10, 2026 · Aug 10, 2026
diff --git a/plugins/lt-dev/commands/dev-submit.md b/plugins/lt-dev/commands/dev-submit.md
@@ -31,6 +31,7 @@ disable-model-invocation: false
 | `/lt-dev:ticket-cycle` | Full pick → implement → merge orchestrator (use this instead when no human reviewer is needed before merge) |
 | `/lt-dev:resolve-ticket` | Full ticket resolution (implementation + tests + review) |
 | `/lt-dev:review` | Code review before submitting |
+| [`writing-qa-test-instructions`](${CLAUDE_PLUGIN_ROOT}/skills/writing-qa-test-instructions/SKILL.md) skill | Testability classification + German QA test instructions for the Linear comment (STEP 3) |
 
 ---
 
@@ -121,25 +122,44 @@ Store the MR/PR URL as `REQUEST_URL`.
 
 1. **Retrieve Issue:** Fetch Linear issue **#ISSUE_ID** via MCP (title, description).
 2. **Analyze Changes:** Use the commit list and diff stat from Step 2.
-3. **Generate Comment** in **German** for non-developers:
+3. **Generate Comment** in **German** for non-developers, following [`writing-qa-test-instructions`](${CLAUDE_PLUGIN_ROOT}/skills/writing-qa-test-instructions/SKILL.md) — it owns the testability classification, the step format, the deployed-URL resolution, and the rule that the comment names **roles, never passwords**.
+
+Classify first (skill Part 1): can a non-developer exercise this change through the running application? The answer picks the shape.
+
+**Testable:**
 
 ```
 ## Umsetzung
 
-[1-3 sentences: What was implemented/fixed, described in user-facing terms. No technical jargon.]
+[1-3 Sätze in Nutzersprache: was war das Problem, was ist jetzt anders. Kein Jargon.]
 
 ## Testanleitung
 
-[Step-by-step testing instructions:]
-1. [First step - e.g., "Seite X aufrufen"]
-2. [Action to perform]
-3. [Expected result to verify]
+Umgebung: <Dev-URL>
+Rollen:   <benötigte Rollen>
+Zugang:   Zugangsdaten für die genannten Rollen bitte beim Team erfragen —
+          dieser Kommentar enthält bewusst keine Passwörter.
+
+1. Als <Rolle> anmelden → [<Seite>](<URL>) → <genaue Aktion>
+   → erwartet: <Ergebnis> → prüft: <warum>
+2. …
 
 ## Review
 
 MR/PR: REQUEST_URL
 ```
 
+**Not testable** — same block, with the Testanleitung section replaced by:
+
+```
+## Testanleitung
+
+Nicht manuell testbar: <Grund in einem Satz>.
+Abgesichert über: <Unit-/API-/E2E-Tests, grüne CI-Pipeline>.
+```
+
+The change is not merged yet on this path, so the instructions describe what the reviewer (and later the tester) verifies once it lands.
+
 4. **User Approval** via `AskUserQuestion`:
    - Show the generated comment
    - Option 1: "Posten" → Post as-is

diff --git a/plugins/lt-dev/commands/git/ship.md b/plugins/lt-dev/commands/git/ship.md
@@ -39,6 +39,7 @@ This command is the **closing bookend** to `/lt-dev:take-ticket`. It does **not*
 | `/lt-dev:git:create-request` | Standalone MR/PR creation (used internally by Phase 6) |
 | `/lt-dev:dev-submit` | MR/PR + Linear comment + Linear status → "Dev Review" (no merge, no pipeline wait) |
 | [`managing-agent-memory`](../../skills/managing-agent-memory/SKILL.md) skill | Agent-memory commit policy + pre-commit curation (STEP 2) |
+| [`writing-qa-test-instructions`](../../skills/writing-qa-test-instructions/SKILL.md) skill | Testability classification + German QA test instructions for the Linear comment (STEP 10c) |
 
 **Difference vs. `/lt-dev:dev-submit`:** `dev-submit` hands off to a human reviewer. `ship` lands the branch into dev autonomously after CI is green.
 
@@ -476,18 +477,27 @@ Store as `ISSUE_ID`.
 
 ### 10c. Generate & Post Comment
 
-Generate a **German** comment for non-developers, using commits + diff stat from STEP 6:
+Generate a **German** comment for non-developers, using commits + diff stat from STEP 6. Follow [`writing-qa-test-instructions`](${CLAUDE_PLUGIN_ROOT}/skills/writing-qa-test-instructions/SKILL.md) — it owns the testability classification, the step format, the deployed-URL resolution, and the rule that the comment names **roles, never passwords**.
+
+Classify first (skill Part 1): can a non-developer exercise this change through the running application on the dev deployment? The answer picks the shape.
+
+**Testable:**
 
 ```
 ## Umsetzung
 
-[1-3 sentences: What was implemented/fixed, in user-facing terms. No technical jargon.]
+[1-3 Sätze in Nutzersprache: was war das Problem, was ist jetzt anders. Kein Jargon.]
 
 ## Testanleitung
 
-1. [First step — e.g., "Seite X aufrufen"]
-2. [Action to perform]
-3. [Expected result to verify]
+Umgebung: <Dev-URL>
+Rollen:   <benötigte Rollen>
+Zugang:   Zugangsdaten für die genannten Rollen bitte beim Team erfragen —
+          dieser Kommentar enthält bewusst keine Passwörter.
+
+1. Als <Rolle> anmelden → [<Seite>](<URL>) → <genaue Aktion>
+   → erwartet: <Ergebnis> → prüft: <warum>
+2. …
 
 ## Status
 
@@ -496,6 +506,17 @@ In `<BASE_BRANCH>` gemerged (Squash). Wird beim nächsten Deployment auf dev ver
 MR/PR: <REQUEST_URL>
 ```
 
+**Not testable** — same block, with the Testanleitung section replaced by:
+
+```
+## Testanleitung
+
+Nicht manuell testbar: <Grund in einem Satz>.
+Abgesichert über: <Unit-/API-/E2E-Tests, grüne CI-Pipeline>.
+```
+
+This comment is what a later `/lt-dev:ticket-cycle` run reads back at its STEP 4b.3c before moving the ticket into "QA Testing" — so it is the QA handover, not a courtesy note.
+
 Then ask the user via `AskUserQuestion`:
 - Show the generated comment.
 - Options:

diff --git a/plugins/lt-dev/commands/take-ticket.md b/plugins/lt-dev/commands/take-ticket.md
@@ -236,7 +236,7 @@ Persist collected sources in a working note (in-context). Do **not** write a mar
 
 1. **Re-read the ticket's CURRENT status first — do not trust the value STEP 1 resolved.** Minutes can pass between picking and starting (context gathering, user questions), and the user runs several sessions in parallel. Re-fetch the issue and check:
    - Status still `Open` (or `Fix Needed` / whatever the pool admitted it under) **and** assignee still empty or the current user → proceed.
-   - Status already `In Progress` / `Dev Review` / `PO Review` / `Blocked`, **or** assigned to someone else → **stop and ask the user.** Another session is on it; taking it now produces two branches for one ticket. Do not "just continue because we already started".
+   - Status already `In Progress` / `Dev Review` / `QA Testing` / `Blocked`, **or** assigned to someone else → **stop and ask the user.** Another session is on it; taking it now produces two branches for one ticket. Do not "just continue because we already started".
    - Before asking, gather the facts the user needs to decide: `git worktree list` (every parallel checkout + its branch), `git ls-remote --heads origin | grep <ticket-number>` (pushed branches), and how many commits each branch carries. Present those, then let the user decide who continues — never decide it yourself.
 2. Resolve current Linear user via `mcp__plugin_lt-dev_linear__get_user` (the authenticated viewer — no ID needed).
 3. Find the team's "In Progress" state ID from `STATE_IDS`. Match case-insensitively against: `In Progress`, `Started`, `Doing`. If none match, ask the user which state to use.