feat(skills): добавлен скилл brainstorm-with-docs (v1)

- Зачем:
  - нужен ручной скилл для брейнсторма и дизайна, который удерживает
    словарь смыслов (CONTEXT.md) и лёгкие ADR, активно прожаривает план
    и не сваливается в реализацию.
- Что:
  - SKILL.md: процесс (контекст → классификация → декомпозиция →
    грилл → синтез опций → подтверждение → артефакт), единый HARD-GATE
    «исследуй, но не меняй состояние» с поправкой на auto mode.
  - artifacts/: шаблоны spec, research-note, adr, runbook, prd, context
    (по файлу на тип для progressive disclosure).
  - README.md с MIT-атрибуцией grill-with-docs (Pocock) и brainstorming
    (obra/superpowers); шов для будущей фазы дивергенции в шаге 5.
  - frontmatter переносим: Claude читает все поля, Codex — name+description.
- Проверка:
  - python3 yaml-парс frontmatter; markdown-ссылки на artifacts/ резолвятся.

agents/.agents/skills/brainstorm-with-docs/artifacts/adr.md

@@ -0,0 +1,40 @@
+# ADR — Architectural Decision Record
+
+ADRs live in `docs/adr/` with sequential numbering: `0001-slug.md`,
+`0002-slug.md`, etc. Create `docs/adr/` lazily — only when the first ADR is
+needed. To number a new one, scan `docs/adr/` for the highest number and add one.
+
+## When to offer an ADR
+
+Offer one only when **all three** are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful.
+2. **Surprising without context** — a future reader will look at the code and
+   wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and one
+   was picked for specific reasons.
+
+If any of the three is missing, skip it. Easy to reverse → you'll just reverse
+it. Not surprising → nobody will wonder. No real alternative → nothing to record
+beyond "we did the obvious thing". Do not create an ADR for every small choice.
+
+## Template
+
+```markdown
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what we decided, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is recording *that* a
+decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Add these only when they earn their place (most ADRs won't need them):
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by
+  ADR-NNNN`) — useful when decisions get revisited.
+- **Considered options** — only when the rejected alternatives are worth
+  remembering (otherwise someone re-proposes them in six months).
+- **Consequences** — only when non-obvious downstream effects need calling out.

agents/.agents/skills/brainstorm-with-docs/artifacts/context.md

@@ -0,0 +1,53 @@
+# CONTEXT.md — Shared Project Language
+
+`CONTEXT.md` is a **glossary and nothing else**. It exists so that the user, the
+code, and future agents use the same words for the same concepts. It is totally
+devoid of implementation details, decisions, plans, or work logs.
+
+A single `CONTEXT.md` lives at the repo root. If a `CONTEXT-MAP.md` exists at the
+root, the repo has multiple contexts — read it to find which `CONTEXT.md` the
+current topic belongs to. (Multi-context handling is deliberately light in v1.)
+
+Create the file lazily — only when the first term is actually worth recording.
+
+## Structure
+
+```markdown
+# {Context Name}
+
+{One or two sentences: what this context is and why it exists.}
+
+## Language
+
+**Order**:
+A customer's request to purchase one or more items.
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organisation that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When several words mean the same thing, pick the best one
+  and list the rest under `_Avoid_`.
+- **Keep definitions tight.** One or two sentences. Define what it *is*, not what
+  it *does*.
+- **Only project-specific terms.** General programming concepts (timeouts, retry,
+  cache) don't belong, even if the project uses them heavily. Ask: is this unique
+  to this project's domain, or generic? Only the former belongs.
+- **Group under subheadings** when natural clusters emerge; a flat list is fine
+  otherwise.
+
+## What does NOT go in CONTEXT.md
+
+- implementation details
+- specs, decisions, or rejected alternatives → spec / ADR
+- operational procedures → runbook
+- validation rules for the current work → spec
+- work logs, temporary notes, speculative ideas

agents/.agents/skills/brainstorm-with-docs/artifacts/prd.md

@@ -0,0 +1,38 @@
+# PRD — Product Requirements Document
+
+Use **only** for product-facing work with user-visible behaviour. For internal
+engineering, infra, or architecture work use `artifacts/spec.md` instead — don't
+force everything into a PRD.
+
+## Template
+
+```markdown
+# Title
+
+## Problem statement
+
+## Users
+
+## Goals
+
+## Non-goals
+
+## User stories
+
+## Requirements
+
+## Out of scope
+
+## Success criteria
+
+## Open questions
+```
+
+## Notes
+
+- A PRD describes *what* and *why* from the user's point of view, not *how*. The
+  engineering "how" belongs in a spec.
+- **Non-goals** and **Out of scope** are deliberately separate: non-goals are
+  things we chose not to optimise for; out of scope is work explicitly deferred.
+- **Success criteria** must be observable — how will we know the behaviour is
+  right once shipped?

agents/.agents/skills/brainstorm-with-docs/artifacts/research-note.md

@@ -0,0 +1,38 @@
+# Research Note
+
+Use when the work is exploratory and the final answer is not yet known. The
+output is *findings and a direction*, not a committed design.
+
+When the question is resolved, the research note often graduates into a spec
+(`artifacts/spec.md`) or an ADR (`artifacts/adr.md`).
+
+## Template
+
+```markdown
+# Title
+
+## Question
+
+## Context
+
+## Known facts
+
+## Assumptions
+
+## Options / hypotheses
+
+## Findings
+
+## Recommendation
+
+## Remaining unknowns
+
+## Next checks
+```
+
+## Notes
+
+- Keep **Known facts** and **Assumptions** strictly separate. Conflating them is
+  how a guess hardens into an unexamined "fact".
+- **Remaining unknowns** and **Next checks** are what make a research note
+  useful to the next agent — they say where to dig next.

agents/.agents/skills/brainstorm-with-docs/artifacts/runbook.md

@@ -0,0 +1,37 @@
+# Runbook
+
+Use for operational procedures: diagnostics, verification, recovery, deployment,
+or routine maintenance. A runbook is for *doing*, so optimise for someone
+following it under pressure — concrete commands, expected output, clear failure
+branches.
+
+## Template
+
+```markdown
+# Title
+
+## Purpose
+
+## When to use
+
+## Preconditions
+
+## Procedure
+
+## Verification
+
+## Rollback / recovery
+
+## Known failure modes
+
+## Notes
+```
+
+## Notes
+
+- **Procedure** steps should be copy-pasteable where possible, with the expected
+  result after each consequential step.
+- **Verification** is how the operator confirms success — not "it should work"
+  but "run X, expect Y".
+- **Rollback / recovery** and **Known failure modes** are what separate a
+  runbook from a tutorial. If you can't say how to undo it, say that explicitly.

agents/.agents/skills/brainstorm-with-docs/artifacts/spec.md

@@ -0,0 +1,56 @@
+# Solution Design / Spec
+
+Use for engineering, architecture, DevOps, integration, migration, or any
+non-product feature work where a direction has been chosen but not yet built.
+
+Use the smallest version that preserves the useful thinking. Drop sections that
+add nothing for this particular problem — an empty section is noise.
+
+## Template
+
+```markdown
+# Title
+
+## Problem
+
+## Context
+
+## Goals
+
+## Non-goals
+
+## Current state
+
+## Options considered
+
+## Recommended approach
+
+## Rationale
+
+## Decisions and rejected alternatives
+
+## Risks and mitigations
+
+## Validation
+
+## Documentation impact
+
+## Open questions
+```
+
+## Notes on key sections
+
+**Decisions and rejected alternatives** is the highest-value section. Capture:
+
+- accepted decisions and the reason behind each
+- rejected alternatives and *why* they were rejected
+- subtle constraints and important defaults
+- sequencing decisions
+- assumptions future agents must not silently re-derive
+
+Do not turn this section into an ADR dump. Promote a decision to its own ADR
+(`artifacts/adr.md`) only when it is durable, surprising, and the result of a
+real trade-off.
+
+**Validation** describes how we will know the implementation is correct — tests,
+checks, acceptance criteria. It belongs here, not in `CONTEXT.md`.