feat: run design interviews as grilling frontier rounds across the planning agents

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

assets/agents/architect/config.yaml

@@ -5,7 +5,7 @@ description: |
   spawns one Sisyphus per task on a single run branch, verifies each with an adversarial
   plan-conformance check, and finishes with ONE draft PR (CI checks watched to green) plus tracked
   follow-up tasks. Task state lives on disk in a plans directory, so runs survive context compression.
-version: 2.0.0
+version: 2.1.0
 agent_session: temp
 auto_continue: true
 max_auto_continues: 100
@@ -27,6 +27,7 @@ summarization_threshold: 100000
 skills_enabled: true
 enabled_skills:
   - design-session
+  - grilling
   - task-tracking
   - plan-authoring
   - delegation-protocol
@@ -126,7 +127,10 @@ instructions: |
 
   ### Phase B — Design decomposition
 
-  Load and follow the `design-session` skill against the design doc. This produces
+  Load and follow the `design-session` skill against the design doc. When running
+  interactively, also load `grilling` and put the open design decisions to the user as
+  frontier rounds (numbered questions, each with a recommended answer) instead of ad-hoc
+  one-at-a-time questions. This produces
   `{{plans_dir}}/PLAN-<slug>.md` with Problem, Scope, Approach, Alternatives, Constraints/risks,
   Open questions, and a **Task breakdown** where **each task is sized to ~1 engineer-day** (decompose
   anything bigger NOW).

assets/agents/architecture-reviewer/config.yaml

@@ -1,6 +1,6 @@
 name: architecture-reviewer
 description: On-demand architecture improvement scout - scans a codebase for deepening opportunities (shallow modules, leaked seams, missing locality) weighted by git-history hot spots, presents candidates as a visual report, then refines the chosen candidate into a concrete interface proposal via design-it-twice. Proposes, never implements. NOT a completion gate - invoke it when you want the codebase made deeper, more testable, and easier to navigate.
-version: 1.0.0
+version: 1.1.0
 
 agent_session: temp
 auto_continue: true
@@ -19,6 +19,7 @@ skills_enabled: true
 enabled_skills:
   - codebase-design
   - delegation-protocol
+  - grilling
   - parallel-research
 
 variables:
@@ -120,6 +121,9 @@ instructions: |
   1. **Frame the problem space**: the constraints any new interface must satisfy, the dependencies
      and their category (in-process / local-substitutable / remote-but-owned / true external, per
      the skill), and a rough illustrative sketch to make the constraints concrete. Show the user.
+     When the candidate carries open decisions (what sits behind the seam, which callers to
+     optimise for, what tests must survive), load `grilling` and walk them as frontier rounds —
+     recommended answer per question, facts fetched by you, decisions made by the user.
   2. **Design it twice**: produce 2-3 radically different interface designs per the skill's
      pattern (different constraint each: minimal interface / maximal flexibility / optimise the
      common caller). For a candidate worth the budget, spawn `oracle` to independently design or

assets/agents/sisyphus/config.yaml

@@ -1,6 +1,6 @@
 name: sisyphus
 description: OpenCode-style orchestrator - classifies intent, delegates to specialists, tracks progress with todos, enforces OMO-grade verification discipline
-version: 3.6.0
+version: 3.7.0
 
 agent_session: temp
 auto_continue: true
@@ -29,6 +29,7 @@ enabled_skills:
   - code-review
   - comment-discipline
   - diagnosing-bugs
+  - grilling
   - git-master
   - frontend-ui-ux
   - delegation-protocol
@@ -430,7 +431,7 @@ instructions: |
 
   ### Authoring lifecycle (no code changes)
 
-  1. Discuss the problem; converge on a solution WITH the user before any plan is written.
+  1. Discuss the problem; converge on a solution WITH the user before any plan is written. Load `grilling` and work the design as frontier rounds: every currently-answerable question in one numbered round, each with your recommended answer; fetch facts yourself (explore/librarian), put only decisions to the user; done when the frontier is empty and the user confirms.
   2. Load `plan-authoring`. Explore first (fan out `explore` agents) — plans must be grounded in real code, with snippets pasted into each step's Context.
   3. Write the high-level plan, then one step plan per step, following the schema and layout from `plan-authoring`.
   4. **Plan review gate (MANDATORY before any execution):** spawn `oracle` to review the plans. Nudge it: "Load `plan-review` and `plan-authoring`, review `plans/`, return the PLAN_REVIEW verdict." REJECT → fix the complaints, re-submit. Do not start execution on an unreviewed or rejected plan.