Council Review

Phase 0: Stack Detection (DO NOT SKIP)

This suffixless skill is a router — its job is to detect the workspace stack and dispatch to the matching variant. Run this phase BEFORE the council customisation and Phase 1 below. The dispatch path is non-negotiable; if detection fails, refuse loudly. Do NOT silently fall back to either stack.

Marker checklist (filesystem-only, no network)

Inspect the workspace cwd (the directory the skill was invoked from) plus each depth-1 subdirectory (monorepo support — webapp/package.json, advisor_bot/requirements.txt, etc.). Apply these rules in order. Marker names are the canonical identifiers — keep them verbatim in any refusal output.

Specificity invariant: depth-1 subdir scan widens where markers are looked for, NOT what counts as a marker. web/package.json:name=aura-companion is still matched ONLY by literal name === "aura-companion"; aiogram is still matched ONLY by literal substring / ^aiogram\b line. Directory naming (bot/, webapp/) is NEVER a stack signal on its own.

1. web/package.json:name=aura-companion — Read web/package.json (or <subdir>/package.json at depth 1). If it exists, parses as JSON, and its name field equals "aura-companion", the Aura stack matches.
2. web/package.json:dependencies.hono — Same file. If dependencies.hono key is present, the Aura stack matches.
3. web/server/ws-bridge.ts — If this exact file exists on disk (or <subdir>/server/ws-bridge.ts at depth 1), the Aura stack matches.
4. pyproject.toml:aiogram — Read pyproject.toml (or <subdir>/pyproject.toml at depth 1). If it exists and contains the literal substring aiogram, the Python stack matches.
5. requirements.txt:^aiogram + bot/ — At workspace root: requires BOTH bot/ directory AND requirements.txt with a line matching ^aiogram\b. At a depth-1 subdir: only requires <subdir>/requirements.txt with ^aiogram\b — the subdir owning its own requirements.txt replaces the bot/ co-requirement.
6. .council-stack-override — If this file exists, trim its content and treat the value as the explicit stack choice. The closed allow-list is exactly aura or python. Anything else (empty, whitespace, Aura, both) → refuse with the override-malformed headline; never silently fall back.

Dispatch rules

• .council-stack-override contains aura AND auto-detection found no opposing-only signal → execute the Aura variant of this skill (/council-review-aura). Override takes precedence; auto-detection markers still surface in the enumeration but do not change the verdict.
• .council-stack-override contains python AND auto-detection found no opposing-only signal → continue with the Python council body below.
• .council-stack-override asserts one stack but auto-detection found ONLY the opposing-stack markers → REFUSE with the override-conflict headline (ask-first). Do NOT silently honour the override against contradictory evidence.
• No override + Aura marker matched + no Python marker matched → execute /council-review-aura.
• No override + Python marker matched + no Aura marker matched → continue with the Python council body below.
• Both Aura and Python markers matched → REFUSE with the ambiguous headline (see refusal templates below).
• Neither matched → REFUSE with the unknown headline.

Refusal templates (pick the headline that matches the failure class)

Always emit the full refusal in plain text. Hard rules:

• Never silently fall back to one of the two stacks on detection failure.
• Never echo raw file content — only filename + parse-status annotation.
• Never use first-person pronouns, apologies, or hedges.
• Keep the refusal compact (target ≤ 18 lines).

Headlines (use the exact wording — these are mirrored by the in-repo verifier web/scripts/detect-stack.ts):

• Unknown stack: Stack detection: no recognised stack markers at workspace root.
• Ambiguous: Stack detection: both Aura and Python markers present.
• Override malformed: Stack detection: .council-stack-override is malformed.
• Override conflict: Stack detection: .council-stack-override conflicts with auto-detected markers.

Refusal body structure for every class:

<Headline>

Checked for:
  - web/package.json:name=aura-companion
  - web/package.json:dependencies.hono
  - web/server/ws-bridge.ts
  - pyproject.toml:aiogram
  - requirements.txt:^aiogram + bot/
  - .council-stack-override

Found at workspace root:
  - <list filenames you actually saw via `ls` — no file content>
  (or "  (no recognised stack markers)" if the workspace is empty of markers)

To override, run:
  /council-review-aura      # if this workspace is the Aura companion
  /council-review            # if this workspace is the Python bot (suffixless variant)

After Phase 0 selects a path: if dispatching to the Aura variant, invoke it and stop. If staying in the Python body, proceed to the council customisation and Phase 1 below. If refusing, emit the refusal block exactly as shown and stop.

Phase 8: Emit Council Checkpoint (auto)

Purpose. When this skill runs inside an Aura Companion Council pair, this phase tells the observer half "the orchestrator just finished reviewing — here is the review file, cross-check it." The observer wakes within ~1 second of the checkpoint POST and emits its independent review to <workspace>/.council/reviews/council-review-<provider>-observer.md. Without this step the council loop never closes — the observer remains in "Awaiting first checkpoint" forever.

The value: the orchestrator-run council review and the observer-run independent review come from different model contexts. Disagreement between them is itself signal.

Council pairing is a property of the SESSION, not of the workspace stack. A Python workspace paired in the Aura Companion UI has an observer that needs waking exactly like an Aura workspace does. Do not skip this phase on the grounds that this is not an Aura project.

Skip this phase entirely if any of these are true:

• http://localhost:3456/api/sessions does not respond (you are not inside the Aura Companion UI).
• No session in the response matches the current workspace + orchestrator role.
• The POST .../council/checkpoint returns 409 — that response IS the silent-skip signal.

Steps

1. Probe the API. Run curl -fsS http://localhost:3456/api/sessions. Non-zero exit or empty → skip the entire phase.

2. Discover the orchestrator session id. Filter the response array for the entry matching ALL of:

   • state == "connected"
   • cwd == <current workspace cwd> (the cwd you reviewed under)
   • sessionGroupRole == "orchestrator"
   • newest createdAt if more than one match

   Zero matches → silent skip. One match → capture sessionId (= ORCH_SID) and sessionGroupId (= GROUP_ID).

3. Compute next sequence. List <workspace>/.council/checkpoints/*.json. Read each file's sequence field. next_sequence = max(...) + 1, or 0 if the directory is empty or absent.

4. Build CheckpointPayload.

   {
     "schema_version": 1,
     "checkpoint_id": "council-review-<seq>-<8-hex-random>",
     "phase": "council-review",
     "sequence": <next_sequence>,
     "session_group_id": "<GROUP_ID>",
     "emitted_at": "<UTC ISO 8601 T-form, no fractional seconds>",
     "artifact_paths": [".council/review-output/<TIMESTAMP>/FINAL-REVIEW.md"]
   }
   

   artifact_paths should be the single FINAL-REVIEW.md path from Phase 5, workspace-relative. The observer's job here is meta-review — does the orchestrator's review hold up?

5. POST. Use the Bash tool:

   curl -fsS -X POST \
     "http://localhost:3456/api/sessions/$ORCH_SID/council/checkpoint" \
     -H "Content-Type: application/json" \
     -d "$PAYLOAD"
   

   Expected 200 with {"ok": true, "written": "...", ...}.

6. On non-200:

   • 409 ("Session is not part of an active council group"): silent skip, not an error.
   • 400 / 403 / 500: surface the raw response body to the user, do not retry.

7. Do not wait for the observer's review. The 200 response IS the success signal for this phase; the observer's review lands asynchronously in the Aura UI's ObserverPanel.