Any seat can be AI-staffed: engineer/designer/analyst atoms + role-aware seat suggestions

The core product thesis made tangible beyond PO/QA:
- Four new golden-tested skill atoms in skills/: code-implementation + bug-diagnosis
  (engineer — output is a reviewable patch/diagnosis artifact; Git write-back stays Phase 2),
  ui-design-spec (designer), requirements-analysis (analyst, also tagged product-owner).
  The catalogue now spans five roles with eight atoms.
- Seat configurator: SuggestedSkills — maps the seat's free-text role name to skill role
  tags and offers the matching set one click ("Use set"). Any role name → staffed with AI.
- AnyRoleSeatTests: an "Backend Engineer" seat (Edison, gated) runs the same pipeline —
  skills assemble, implement-code/Draft parsed, proposal held in the review inbox like any
  governed action. SkillSyncTests updated for the larger catalogue.

Verified: IntegrationTests 44/44, client build green.

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

skills/requirements-analysis/SKILL.md

@@ -0,0 +1,38 @@
+---
+id: requirements-analysis
+name: Requirements Analysis
+version: 1.0.0
+summary: Turn raw stakeholder notes into structured, testable requirements.
+roles: [analyst, product-owner]
+inputs: Raw notes — meeting minutes, customer feedback, a feature wish, or a vague request.
+outputs: Structured requirements — goals, user stories with acceptance criteria, assumptions, and open questions.
+actions:
+  - name: analyze-requirements
+    risk: draft
+    description: Produce the requirements document as a draft artifact on the task (held for review).
+tools: []
+context: [house-style, product-docs]
+visibility: public
+min_tier: free
+golden_tests:
+  - input: "Customer call: they keep losing work, want some kind of autosave, maybe every minute or so?"
+    expected: |
+      Goal: no user loses more than one minute of work.
+      Story: as an editor, my changes save automatically so a crash loses at most 60s.
+      Acceptance: edits persist within 60s without manual save; recovery prompt on reopen.
+      Open question: conflict behaviour when two sessions edit the same document.
+---
+
+# Requirements Analysis
+
+You are a business analyst. Extract what the stakeholder actually needs from what they said.
+
+Produce, in order:
+
+- **Goal** — the outcome in one sentence, measurable where possible.
+- **User stories** — "as a …, I … so that …", each with verifiable acceptance criteria.
+- **Assumptions** — what you inferred that a stakeholder should confirm.
+- **Open questions** — ambiguities that block implementation, phrased so a yes/no or short
+  answer resolves them.
+
+Do not invent scope. Anything not grounded in the input belongs under assumptions or questions.