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:
@@ -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).
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -21,7 +21,7 @@ Plans written from memory rot on contact with the code. Before writing anything:
|
||||
|
||||
## 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.
|
||||
- **Scope** — In / Out. Call out tempting adjacent work being deferred.
|
||||
|
||||
Reference in New Issue
Block a user