council-review

name: council-review description: >- Run the target-state council review of a banking process — the five other perspective specialists (process, control & compliance, client journey, innovation, IT architecture) challenge the proposed target state from their own lens and write their feedback to the process's targetReview field for the SME to triage. Use this whenever the user wants to review, challenge or sense-check the target state / transformation of a process, run the council on the target, or get a cross-perspective review of the To-Be — collectively or one specialist at a time. Non-interactive: no SME questions, no approval loop; invoked by a button or by free chat.

Council Review

You run the target-state council review: the five perspective specialists who did not author the target — the Process, Control & Compliance, Client Journey, Innovation and IT Architecture specialists — each challenge the proposed target state from their own lens, and you write their feedback to the process's targetReview field for the SME to triage (accept / reject) in the web app.

The target itself is the transformation-agent's work; the council is every other perspective sense-checking it.

This is the cross-perspective review of the transformation — the lint "council" (SKILLS.md §9) pointed specifically at the Target Process area.

Non-interactive. You do not ask the SME questions and you do not run an approval loop. You review, you write the targetReview field, you close out. The SME triages each feedback item in the app's Council Review panel (the Validation section); an accepted item re-opens the implicated transformation-decision there.

Scope — full council or one specialist

The invoking message says either "the full council (all five perspective specialists)" or "with only the <specialist> specialist". Run exactly the specialists named:

What you review

The proposed target of the process:

• the transformation-decision elements (transformation-decisions/),
• the target-state elements (to-be-design/),
• their relations: a decision's resolves (As-Is problems) and realises (target-state themes), a target-state's replaces (As-Is steps).

Read the As-Is freely as context — the process-steps, exceptions, controls, regulations, pain-points, gaps, systems. You are checking the target against the As-Is and against each specialist's domain knowledge.

The session — phases

Phase 0 — Orientation. Identify the process from the slug in the invoking message. Read schema/process-schema.json, then the Target Process area (transformation-decisions/, to-be-design/) and the As-Is. Note which specialists are in scope (Phase scope above).

Phase 1 — Review, specialist by specialist. For each in-scope specialist, put on that lens and challenge the proposed target. A feedback item is a genuine concern that specialist would raise — a control the transformation weakens, a To-Be step that is not operable, a client touchpoint the redesign breaks, a system capability a target-state assumes but does not have. Ground every item in a specific transformation-decision or target-state element. Do not invent praise — only raise concerns; a specialist with no concern raises no item. Route by potential relevance, not only stored relations: the Control specialist reviews every decision, including those with no control named.

For each feedback item capture:

• specialist — the specialist raising it.
• title — a one-line headline of the concern.
• detail — the concern in full: what is wrong, why it matters from this lens, and what the target would need to address it.
• targets — the transformation-decision / target-state ids the concern implicates (these are what re-open on accept).

Phase 2 — Write. Assemble a single JSON object:

{ "ran": ["<each in-scope specialist>"],
  "items": [ { "specialist": "...", "title": "...", "detail": "...",
               "targets": ["TD-…", "TS-…"] }, … ] }

Pass it to the writeTargetReview({ slug, reviewData }) tool. The tool id-stamps the items (R-001…), stamps each triage: pending, and writes the process's targetReview field. It is deterministic — it owns the format; you own the judgement.

Phase 3 — Close out. Summarise: how many items each specialist raised, and tell the SME to triage them in the app — the Council Review panel in the Validation section, where accept / reject is per item and an accepted item re-opens the implicated decision for re-approval. If no specialist raised any concern, still write the file (an empty items list) and say the council found nothing to flag.

Principles

1. Each specialist stays in its lane. The Control specialist does not raise an operability concern; the Process specialist does not raise a regulatory one. One lens per item.
2. Concerns, not praise. The review surfaces what the SME should weigh — an item is a genuine objection, never a compliment.
3. Ground every item. Each item names the specific transformation-decision or target-state it implicates. A concern with no target is not actionable.
4. The SME rules, not you. You raise items; the SME accepts or rejects each in the app. Never set a triage state — every item is written pending.
5. Honest empty. A specialist with nothing to flag raises nothing; a council that finds the target sound writes an empty items list. Do not manufacture findings to look thorough.