docs(skills): replace metaphor labels with plain language

plugins/coding-discipline/skills/brainstorming/SKILL.md

@@ -3,7 +3,7 @@ name: brainstorming
 description: Use before coding when requirements have multiple reasonable interpretations, approaches require tradeoffs, or mistakes would be costly (permissions/payments/data migration/public APIs/data structures/hard-to-revert changes). Clarify requirements and design one question at a time, then get approval before implementation. Do not trigger for a focused small change with a clear goal and approach, or for mechanical edits (copy/constants/config values).
 ---
 
-**Hard gate: write no code until the design is approved.** Once this skill triggers, follow it through—the design may be only a few sentences, but it must be explained and approved first. Deciding midway that it is "actually simple" is not a reason to exit: "simple" often means unstated assumptions.
+**Hard rule: write no code until the design is approved.** Once this skill triggers, follow it through—the design may be only a few sentences, but it must be explained and approved first. Deciding midway that it is "actually simple" is not a reason to exit: "simple" often means unstated assumptions.
 
 ## Excuses that surface when you want to skip design
 | What you tell yourself | Reality |

plugins/coding-discipline/skills/git-flow/SKILL.md

@@ -26,5 +26,5 @@ description: Use when creating a branch, using worktrees for parallel work, comm
 ## Wrap-up
 - **Verify that all tests pass before wrapping up** (see verify-before-done). A failing branch must not proceed to merge / PR.
 - Offer **explicit choices** instead of asking an open-ended “What next?”: ① merge into the baseline branch ② push and open a PR/MR ③ keep as-is ④ discard.
-- Iron sequence: **merge and verify success → remove the worktree → delete the branch**. A branch still referenced by a worktree cannot be deleted; before running `git worktree remove`, `cd` back to the main repository.
+- Always in this order: **merge and verify success → remove the worktree → delete the branch**. A branch still referenced by a worktree cannot be deleted; before running `git worktree remove`, `cd` back to the main repository.
 - Clean up only worktrees **you created**; do not touch client-created ones. Discarding requires typed confirmation. Do not force-push unless explicitly asked.

plugins/coding-discipline/skills/spec-sync/SKILL.md

@@ -3,7 +3,7 @@ name: spec-sync
 description: Use in cross-session work when user-confirmed outcomes, non-goals, hard constraints, or acceptance criteria have not been written back to the current source of truth (spec), or reality conflicts with it enough that following it would be wrong; also use during wrap-up or handoff when a source of truth should exist but does not. Edit only the affected original wording; do not keep separate old and new versions. Do not trigger for work that can be completed within one session, local implementation details, verification against existing acceptance criteria, locating the source of truth, or ordinary documentation edits.
 ---
 
-Iron rule: **A change confirmed in conversation must not remain only in the conversation.** If user-confirmed intent that affects future collaboration or acceptance is not written back to the source of truth in this session, the next session cannot even see that the user changed their mind—intent that was never persisted cannot be recovered.
+Hard rule: **A change confirmed in conversation must not remain only in the conversation.** If user-confirmed intent that affects future collaboration or acceptance is not written back to the source of truth in this session, the next session cannot even see that the user changed their mind—intent that was never persisted cannot be recovered.
 
 ## The decision test (the only test for whether to sync)
 > If the next session or another agent read only the current source of truth, would it continue toward an outcome the user has rejected, violate a new constraint, or judge completion against stale criteria? If so, the change must be synced.
@@ -27,7 +27,7 @@ The current desired outcome; explicit non-goals; hard constraints; acceptance cr
 - **No write access to the source of truth** (for example, a PRD owned by someone else): do not overstep. State clearly what is stale and who should update it.
 - **The user explicitly refuses write-back**: explain that the next session may read the old target, then comply. An old spec must never be used to block the user's latest instruction.
 
-## Red lines
+## Hard rules
 - Do not write changes to outcomes / non-goals / hard constraints / acceptance criteria into the source of truth until the user has confirmed them.
 - If the implementation is verified but the source of truth is not synced, report those as two separate facts. Do not claim “the source of truth is synced” or “handoff will preserve everything.”
 - Complete the sync **within this session**. Do not expect a later session to recover intent that was never persisted.

plugins/coding-discipline/skills/systematic-debugging/SKILL.md

@@ -3,7 +3,7 @@ name: systematic-debugging
 description: Use before proposing a permanent fix for bugs, test failures, or unexpected behavior with an unknown root cause—mandatory when symptoms are far from the cause, a prior fix failed, or the issue crosses components. Reproduce, trace backward to the root cause, fix once at the source, and add a regression test. Emergency containment must be a reversible temporary mitigation explicitly identified as not a root-cause fix. Do not trigger for obvious errors whose message identifies the cause (syntax/typo/missing import); fix those directly.
 ---
 
-Iron law: **do not package a guess as a permanent fix before locating the root cause.** If the user explicitly needs emergency containment, you may apply a reversible temporary mitigation first, but you must state its risks and that the root cause is not fixed, then continue investigating.
+Hard rule: **do not package a guess as a permanent fix before locating the root cause.** If the user explicitly needs emergency containment, you may apply a reversible temporary mitigation first, but you must state its risks and that the root cause is not fixed, then continue investigating.
 
 ## 1. Reproduce
 - Read the error message and full stack trace carefully—the answer is often there. Do not skip them. Note the line number, file, and error code.

plugins/coding-discipline/skills/tdd/SKILL.md

@@ -3,7 +3,7 @@ name: tdd
 description: Use before implementation when behavior can be verified by automated tests and regression coverage has clear value. For bugs with an unknown root cause, use systematic-debugging first, then return for red-green. Follow red-green-refactor—write a failing test first, add only enough code to pass it, then refactor. Do not trigger for documentation, configuration, copy-only, or styling changes with no testable behavior.
 ---
 
-Iron law: **write no implementation code without a test that failed first.**
+Hard rule: **write no implementation code without a test that failed first.**
 Did you just write the implementation in this turn without delivering it? Remove it and restart from the test—do not keep it as a "reference" or look at it while adding tests.
 **But never delete the user's existing code or someone else's workspace changes**: when working with an existing implementation, add tests that record and protect its current behavior before making the smallest change.
 

plugins/coding-discipline/skills/verify-before-done/SKILL.md

@@ -7,7 +7,7 @@ Hard rule: **Only evidence gathered after the last relevant change to the code,
 - Claiming completion without sufficient evidence = lying; running the full test suite for a typo = waste.
 - You may reuse evidence just gathered, but state when it was gathered and confirm that no code was changed, nothing was pulled, and the environment was not modified afterward. If you cannot say for sure, check again.
 
-## Gate (before any claim of success or completion)
+## Required checks (before any claim of success or completion)
 1. What claim must be proven? What check is just sufficient (command output / diff / artifact inspection…)?
 2. Was the evidence gathered after the last relevant change? Yes—state when. No / uncertain—**check again**.
 3. If you ran a command, read all output, inspect the exit code, and count failures. If you inspected a diff or artifact, state what you checked and the result.
@@ -27,8 +27,8 @@ If a command cannot run (missing environment, broken dependencies, timeout), **v
 | "Tests are green = requirements are met" | Check each requirement explicitly; green tests alone are not enough. |
 | Only part of the suite ran | This does not mean the whole suite passed. |
 
-## Red lines
+## Hard rules
 - Do not substitute "should", "probably", or "looks right" for evidence.
 - Do not celebrate ("Done!" / "Fixed!" / "Perfect!") before obtaining evidence.
-- Before committing, pushing, or opening a PR or MR after an important change, pass the gate above.
+- Before committing, pushing, or opening a PR or MR after an important change, pass the checks above.
 - If this work includes a confirmed change that makes the current source of truth inaccurate, or the work spans sessions but still lacks a source of truth, use spec-sync before claiming it is ready for handoff. If the user explicitly refuses persistence, explain the consequence and follow their latest instruction.