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>
This commit is contained in:
2026-08-24 15:12:37 -06:00
co-authored by Sisyphus
parent 45333db5c2
commit f8cab9b439
4 changed files with 15 additions and 6 deletions
+6 -2
View File
@@ -5,7 +5,7 @@ description: |
spawns one Sisyphus per task on a single run branch, verifies each with an adversarial 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 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. 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 agent_session: temp
auto_continue: true auto_continue: true
max_auto_continues: 100 max_auto_continues: 100
@@ -27,6 +27,7 @@ summarization_threshold: 100000
skills_enabled: true skills_enabled: true
enabled_skills: enabled_skills:
- design-session - design-session
- grilling
- task-tracking - task-tracking
- plan-authoring - plan-authoring
- delegation-protocol - delegation-protocol
@@ -126,7 +127,10 @@ instructions: |
### Phase B — Design decomposition ### 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, `{{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 Open questions, and a **Task breakdown** where **each task is sized to ~1 engineer-day** (decompose
anything bigger NOW). anything bigger NOW).
@@ -1,6 +1,6 @@
name: architecture-reviewer 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. 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 agent_session: temp
auto_continue: true auto_continue: true
@@ -19,6 +19,7 @@ skills_enabled: true
enabled_skills: enabled_skills:
- codebase-design - codebase-design
- delegation-protocol - delegation-protocol
- grilling
- parallel-research - parallel-research
variables: variables:
@@ -120,6 +121,9 @@ instructions: |
1. **Frame the problem space**: the constraints any new interface must satisfy, the dependencies 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 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. 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 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 pattern (different constraint each: minimal interface / maximal flexibility / optimise the
common caller). For a candidate worth the budget, spawn `oracle` to independently design or common caller). For a candidate worth the budget, spawn `oracle` to independently design or
+3 -2
View File
@@ -1,6 +1,6 @@
name: sisyphus name: sisyphus
description: OpenCode-style orchestrator - classifies intent, delegates to specialists, tracks progress with todos, enforces OMO-grade verification discipline 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 agent_session: temp
auto_continue: true auto_continue: true
@@ -29,6 +29,7 @@ enabled_skills:
- code-review - code-review
- comment-discipline - comment-discipline
- diagnosing-bugs - diagnosing-bugs
- grilling
- git-master - git-master
- frontend-ui-ux - frontend-ui-ux
- delegation-protocol - delegation-protocol
@@ -430,7 +431,7 @@ instructions: |
### Authoring lifecycle (no code changes) ### 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. 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`. 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. 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.
+1 -1
View File
@@ -21,7 +21,7 @@ Plans written from memory rot on contact with the code. Before writing anything:
## Step 2 — The proposal ## Step 2 — The proposal
Produce a structured proposal (iterate with the user when interactive; in autonomous runs, resolve what the doc + code answer and flag the rest as open questions): Produce a structured proposal (iterate with the user when interactive — load the `grilling` skill and work the open decisions as frontier rounds, each question carrying a recommended answer; in autonomous runs, resolve what the doc + code answer and flag the rest as open questions):
- **Problem** — one paragraph; state assumptions explicitly. - **Problem** — one paragraph; state assumptions explicitly.
- **Scope** — In / Out. Call out tempting adjacent work being deferred. - **Scope** — In / Out. Call out tempting adjacent work being deferred.