docs(skills): brainstorm-with-docs — правки по холодному ревью

README перестал объявлять скилл ручным: model-invocation — намеренное
текущее состояние (триггер — форма задачи, не область). Жёсткий гейт
получил исключение для глоссария (спорил с шагом 4) и стал единственным
владельцем запрета на реализацию; дубли правил схлопнуты к владельцам.
Отложенные находки (шов self_review, критерий конца интервью, версионные
пометки в шаблонах) — в Pending decisions ROADMAP.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

agents/.agents/skills/brainstorm-with-docs/SKILL.md

@@ -14,9 +14,11 @@ documentation — not for implementation.
 
 <hard_gate>
 
-Do NOT write code, change configuration or infrastructure, run state-changing
-commands, refactor, run migrations, deploy, or invoke any implementation skill
-until the user has approved a design AND explicitly asked to implement.
+Do NOT change the state of any system until the user has approved a design AND
+explicitly asked to implement: no code, config, or infrastructure changes; no
+state-changing commands, refactors, data writes, migrations, or deployments; no
+invoking an implementation skill; no outward-facing actions other than
+read-only lookups.
 
 Approval of a design direction is NOT approval to implement. The deliverable of
 this skill is shared understanding and a recommended direction; the document is
@@ -25,10 +27,9 @@ are done, and how to stop, is in `<stop_condition>`.)
 
 The skill may freely investigate — read project files, run read-only inspection
 commands, and look up external documentation — and may create or update
-documentation files once the user agrees on the direction. It must NOT change the
-state of any system: no code, config, or infrastructure changes; no data writes
-or migrations; no deployments; and no outward-facing actions other than read-only
-lookups.
+documentation files once the user agrees on the direction. One documentation
+move fires earlier: a NEW glossary term is captured in `CONTEXT.md` inline
+during the interview (additive; step 4 owns the rule).
 
 If you are unsure whether a command has side effects — especially when querying a
 live or production system — state what you intend to run and why, and get a yes,
@@ -72,7 +73,6 @@ If invoked with arguments, treat `$ARGUMENTS` as the initial problem statement.
   of the fan live in step 5.
 * Be direct. Give a real recommendation; don't hide behind "it depends" when the
   context supports a call.
-* Explicitly state what should NOT be done now.
 * Minimum-sufficient artifact: the smallest form that *fully* preserves the
   understanding — and no smaller. Sized to the understanding, not "as small as
   possible": a large understanding earns a fuller document, a small one a paragraph.
@@ -228,8 +228,8 @@ vocabulary.
 ## 7. Write the artifact
 
 Once the user agrees, create or update the artifact, following the format in the
-matching `artifacts/*.md` file. Choose the minimum-sufficient form — the smallest
-that fully preserves the understanding, and no smaller.
+matching `artifacts/*.md` file, sized by the minimum-sufficient rule from
+`<core_rules>`.
 
 Where it goes: follow the repo's existing documentation layout if there is one.
 Otherwise use the conventional homes — `CONTEXT.md` at the repo root, ADRs in
@@ -276,9 +276,8 @@ interview.
 <stop_condition>
 
 You are done once the understanding is shared and minimally recorded — not when
-an artifact has been produced. Then STOP. Do not start coding, change
-infrastructure, alter configuration, or run state-changing commands unless the
-user explicitly asks. Offer a small set of next actions, such as:
+an artifact has been produced. Then STOP — the `<hard_gate>` holds until the
+user explicitly asks to implement. Offer a small set of next actions, such as:
 
 * refine the spec
 * create or update an ADR