Community写作与编辑github.com

Colaiz1p/grill-agent

A Codex skill for persistent agent–subagent interviews that explore user intent, surface novel solution paths, and keep decisions independently owned by the main agent.

grill-agent 是什么?

grill-agent is a Codex agent skill that a Codex skill for persistent agent–subagent interviews that explore user intent, surface novel solution paths, and keep decisions independently owned by the main agent.

兼容平台~Claude CodeCodex CLI~Cursor
npx skills add Colaiz1p/grill-agent

Installed? Explore more 写作与编辑 skills: steipete/notion, affaan-m/seo, affaan-m/brand-voice · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

Grill Agent

This skill owns the complete interview, runtime-review, and lifecycle protocol. Apply it directly; do not invoke another interview skill.

Peer model and context

Before spawning, classify the known task history without opening unrelated stores:

  • For relevant history with no known credential, token, account-state, or unrelated-sensitive content, create the interviewer with spawn_agent and fork_turns="all". Do not pass a model or reasoning_effort override. Record this as full-history peer inheritance, because the fork inherits the parent task's effective configuration and history.
  • When current or earlier history may contain sensitive or irrelevant material, use the smallest safe recent-turn window, or no inherited turns, plus a sanitized seed evidence pack. Pass a model or reasoning override only when the user or a higher-priority rule explicitly requires it and the value is supported by available configuration. Record peer-model parity unverified unless tool-visible evidence establishes parity.

Before any spawn, record the context-safety choice and the best available tool-visible or configuration evidence for the parent task's effective model and reasoning effort. Write Sol xhigh inherited only when that evidence establishes gpt-5.6-sol with xhigh; otherwise record the actual or unknown configuration without presenting configuration evidence as runtime telemetry.

Project reconnaissance

Before the initial frontier, the interviewer independently performs bounded read-only reconnaissance: resolve the working directory, repository root, and active AGENTS.md chain; inspect repository state and diff; trace task-relevant documents, entry points, callers, configuration, tests, validation paths, and cross-module impacts.

Do not treat every nested project or instruction file below the working directory as active context. Search by request relevance instead of scanning the entire workspace. Do not read unrelated credential stores, account state, or secret-bearing files; redact any secret encountered incidentally.

Maintain a compact reconnaissance summary with checked, unresolved, and deliberately out-of-scope. Finish reconnaissance only when each applicable coverage row has evidence or a named gap, relevant execution and validation paths were checked, and discovered cross-module dependencies were included or excluded with a reason.

The interviewer may analyze the task's full impact surface: outcome, contracts, callers, compatibility, authority, failure and recovery, validation, observability, and maintenance cost. Findings do not expand authority; the main agent remains decision owner and executor.

At runtime, perform only delta reconnaissance. Include the trigger, changed facts, affected coverage rows, and reviewed evidence revision; deduplicate the same decision at the same evidence revision.

Coverage interview

Map the work as a design tree. Before asking questions, build a task-specific coverage map with these rows:

  1. outcome and observable success;
  2. current state, evidence, and unknown facts;
  3. constraints, authority, compatibility, and affected boundaries;
  4. material alternatives and tradeoffs;
  5. hidden assumptions, counterexamples, failure modes, and second-order effects;
  6. verification, exit, recovery, or rollback conditions.

Mark every row as exactly one of:

  • covered: resolved from verified evidence or a settled decision;
  • evidence-needed: agent-owned read-only investigation remains;
  • decision-needed: the main agent must decide from the user's stated goals, known preferences, and explicit safe assumptions;
  • not-applicable: irrelevant, with a concise reason;
  • blocked-by-authority: a higher-priority rule requires user authorization that the interview cannot supply.

Set a low, medium, or high depth from irreversibility, ambiguity, blast radius, and novelty. Run a challenge scan at every depth without manufacturing questions; medium and high depth must resolve at least one material hidden assumption, counterexample, failure mode, or second-order effect.

Divergence pass

Before computing the frontier, build an internal path inventory:

  1. Infer the user-visible outcome the requester may actually want. Represent each guess as an intent hypothesis, marked supported or uncertain, with one support and one falsifier. Never present it as verified fact.
  2. Search all four lenses at every decision frontier: user outcome, causal hypothesis, intervention layer, and inversion/no-change/delete. Record an internal reason when a lens is inapplicable or its paths fail the gates; a lens need not produce a candidate.
  3. A materially novel path changes at least one of user outcome, causal hypothesis, intervention layer, or decisive tradeoff and could change scope, repair seam, next action, or verification. Merge wording, technology, and local implementation variants that leave those dimensions unchanged.
  4. Low, medium, and high depth inventory at least one, two, and three credible paths respectively. When fewer paths survive the evidence and novelty gates, record the searched lens and rejection internally instead of inventing a path. Path count is independent of question count.

Keep the path inventory internal. Move only action-changing forks that require a main-agent decision into the frontier, and compress related paths into candidates under the same question. A visible candidate based on inferred intent begins Intent hypothesis — supported: or Intent hypothesis — uncertain:; its evidence/tradeoff states the support and falsifier.

The frontier is every decision whose prerequisites are settled. Ask the whole current frontier in one numbered round; defer decisions that depend on an open prerequisite. Each answer reshapes the tree, so recompute the map and frontier after every round. Finding facts is interviewer work: investigate evidence-needed rows through its own bounded read-only tools and never disguise a lookup as a decision question.

For every decision question, present 2–4 materially distinct, mutually exclusive candidates. Binary decisions show both outcomes; never manufacture synonymous options. Add concise verified evidence or the decisive tradeoff when it helps distinguish the candidates. The interviewer withholds its preference until the main agent submits its independent review.

Use this compact question form:

QUESTION_ROUND

❓ **Q1 — <title>**: <decision question>

- **A.** <candidate>
- **B.** <candidate>
- **C.** <optional materially distinct candidate>

**Evidence / tradeoff:** <concise verified fact or decisive tradeoff, when available>

Response contract

Every interviewer reply begins with exactly one state token on its first non-empty line. This table is the single source of truth for response states:

StateAllowed whenRequired contentMain-agent action
QUESTION_ROUNDInitial decision review, every answer-driven follow-up, and every dispatched runtime decision reviewEvery unlocked decision in one numbered question block; candidates and useful evidence or tradeoffs; no interviewer preferenceSubmit one independent review per question
ANALYSIS_INSUFFICIENTA submitted review is inadequateStable Qn labels and one targeted correction question per missing review element or material counterevidence; no repeated candidatesRevise only the named reviews
AUTHORITY_REQUIREDA specific action requires user authority that is not already presentThe exact action, target, impact, reversibility, and one precise authorization questionAsk the user; never answer on the user's behalf
FRONTIER_CLEARAt least one question-form state was resolved; all coverage is settled; no open fact, decision, authority, or downstream branch remainsClearance and any concise residual risk; no preference-only conclusionPublish any decision record, then execute or resume

Reconnaissance, coverage, challenge, and lifecycle details remain internal working state. They inform the response but never replace the content required by its state.

For a decision frontier, Low depth requires at least one genuine question in the initial QUESTION_ROUND. Medium and high depth require at least two genuine questions from distinct applicable coverage dimensions, normally outcome or scope plus evidence, risk, or verification. Ask every additional unlocked decision in the same round. Never pad a round with synonymous or outcome-irrelevant questions.

Only an authority-only frontier may use AUTHORITY_REQUIRED as its first state. Its authorization question satisfies the initial question-form gate but is not a main-agent decision review. If any evidence or design decision is also open, use QUESTION_ROUND first.

An answer-driven follow-up contains at least one question and asks every newly unlocked or reopened decision without repeating settled questions. A dispatched runtime decision interview contains at least one question and covers every reopened delta decision without repeating settled questions.

Question labels are unique and monotonically increasing across the top-level lifecycle. Continue numbering across initial, answer-driven, and runtime rounds. Reopen an existing decision as Qn.rK, where K is that decision's revision count, instead of assigning a new identity.

FRONTIER_CLEAR is never a valid first accepted response in a lifecycle.

Receiving-side protocol gate

Before consuming an interviewer reply, the main agent validates all of these conditions:

  1. the first non-empty line and payload satisfy one row of the response table;
  2. every QUESTION_ROUND question has a lifecycle-valid label, 2–4 materially different mutually exclusive candidates, useful evidence or tradeoffs when available, and no interviewer preference;
  3. every question round meets its depth-specific minimum and covers the whole current frontier.

When a visible candidate contains inferred user intent, validate its qualitative intent label, support, and falsifier. Reject decorative alternatives that do not meet the material-novelty and action-relevance gates.

A report, conclusion, audit, preference-only response, premature FRONTIER_CLEAR, or malformed state payload is invalid. The main agent pauses substantive work and sends one FORMAT_RETRY to the same canonical interviewer at the same evidence revision, naming only the missing structural requirements. If that retry is still invalid, emit INTERVIEW_UNAVAILABLE and stop; never accept the payload as clear, create a replacement interviewer, or simulate the missing questions.

Independent decision gate

The interviewer exposes and challenges decisions; the main agent decides. For every question in a QUESTION_ROUND, the main agent submits one separately labelled decision review (Q1, Q2, and so on). Each review contains:

  • its own choice among the displayed candidates, or a justified alternative;
  • verified evidence from relevant files, callers, configuration, tests, or other task facts;
  • one credible counterargument, failure mode, or rejected alternative;
  • a concise rationale the main agent derives independently using project evidence;
  • residual uncertainty and the concrete evidence that would change its conclusion.

An answer consisting only of a candidate label, agree, copied interviewer wording, or an ungrounded preference is insufficient even when it selects a defensible candidate.

The interviewer must judge review quality, not agreement, and accepts a well-supported choice that differs from its preference. It states disagreement only when evidence exposes a missing review element or reopens a decision. For a missing, unmatched, incomplete, copied, or materially counterevidence-blind review, return ANALYSIS_INSUFFICIENT, name the question and gap, and keep its downstream branches open. Never append preference-only prose to FRONTIER_CLEAR.

A valid review settles only its labelled question; it does not settle unasked downstream decisions.

After every complete set of valid decision reviews, the same interviewer runs an answer-driven convergence pass before it may return FRONTIER_CLEAR:

  1. Recompute the design tree and frontier from the reviews, then challenge each answer for hidden assumptions, credible counterexamples, boundaries, failure modes, second-order effects, and changed coverage rows.
  2. Run the divergence pass again when an answer changes user intent, a causal premise, a path class, or a material constraint, or when evidence contradicts the current landscape.
  3. Resolve any evidence-needed branch through bounded read-only reconnaissance; do not present a fact lookup as a decision question.
  4. If any downstream or reopened decision remains, return QUESTION_ROUND with every newly unlocked or reopened decision. The main agent answers that round independently, and the same convergence pass runs again.
  5. Return FRONTIER_CLEAR only when this pass leaves no open branch. Valid reviews alone never permit clearance.

The user observes ordinary interviews but does not answer them: the main agent submits every independent review. Explicit authorization boundaries still apply; mark them blocked-by-authority instead of guessing permission.

User-visible decision record

When a decision frontier reaches FRONTIER_CLEAR and before substantive execution resumes, the main agent publishes one incremental record containing every decision question settled since the previous frontier clear:

INTERVIEW_DECISIONS

Q1. <question>
- Main choice: <label><selected option text>
- Evidence: <one concise verifiable fact supporting the main agent's choice>

Use the lifecycle-global labels, including revision labels for reopened decisions. This is a compact audit, not hidden chain-of-thought: omit private reasoning traces and interviewer preferences. The final answer repeats a compact cumulative INTERVIEW_DECISIONS record for every round in the lifecycle so the questions and selected answers remain visible after commentary collapses.

Persistent lifecycle and runtime re-entry

Create exactly one interviewer per top-level user-request lifecycle and retain it until the task completes:

initial_review -> executing/idle <-> runtime_review -> task_complete
initial_review/runtime_review -> authority_wait -> same review

frontier_clear permits execution but does not end the interviewer's lifecycle. A new outcome or separate deliverable after task_complete starts a new lifecycle; a clarification or narrow continuation before completion resumes the same interviewer.

Evaluate the runtime uncertainty gate before a material decision or irreversible boundary, after material new evidence or a failed check, before changing the accepted approach, and before completion. Resume the same interviewer when evidence contradicts a premise; multiple plausible approaches lack an evidence-backed choice; scope, authority, compatibility, data safety, security, or verification changes; or the main agent cannot state one verified reason for its intended choice.

Routine mechanical steps beneath a cleared decision need no review. If work is in flight, pause only at a safe boundary.

On a trigger, use followup_task with a delta evidence pack containing the trigger, changed facts, current candidates, affected coverage rows, actions already taken, and their reversibility. Reopen the changed decision and every downstream branch whose premise changed; preserve unrelated settled branches. Return to the root only when the affected scope cannot be bounded.

When the interviewer returns AUTHORITY_REQUIRED, the main agent pauses every action that depends on that authority and presents the state’s single precise authorization question to the user. The user remains an observer for ordinary interview decisions but is the only source of missing consent. After authorization or refusal, resume the same canonical interviewer with that event as delta evidence; reopen only the authority branch and decisions that depend on it. A refusal closes or replans the branch within existing authority instead of ending the interviewer lifecycle.

Do not dispatch a runtime interview merely to confirm that nothing changed. Route an evidence or decision frontier to QUESTION_ROUND and an authority-only frontier to AUTHORITY_REQUIRED. Keep affected execution paused until every review or authorization is resolved and any cleared decision record is published.

While runtime_review is open, do not recurse or spawn another interviewer. Record later signals as conceptual pending_delta: deduplicate the same decision at the same evidence revision, merge related deltas into the next round, and handle unrelated deltas after the current frontier clears. Return to executing/idle only when the affected frontier and pending_delta are both clear.

Roles and workflow

  • Main agent: sole user-facing agent, respondent, decision owner, editor, and executor. It inspects relevant facts, submits independent decision reviews, and performs work only while no review frontier blocks it.
  • Interviewer: the one subagent marked ROLE: grill-agent-interviewer. It owns independent project reconnaissance, the coverage map, questions, challenge pass, and analysis gate. It never edits, executes the task, performs external actions, or talks to the user.
  • Recursion guard: the interviewer never invokes another interview skill, creates another interviewer, or dispatches subagents. It performs its own bounded read-only reconnaissance.

Proof of delegation

Creation counts only after a collaboration-tool result identifies the canonical interviewer. Store that identity and reuse it for every runtime followup_task. Runtime review counts only after a tool-visible dispatch to that identity and its response; waits, empty receiver lists, self-authored text, and claimed names are not proof.

If creation or follow-up cannot be verified, emit INTERVIEW_UNAVAILABLE and stop before substantive work. Claim an interview, runtime re-entry, analysis result, or decision record only with its tool-visible evidence. A higher-priority emergency safety action may proceed within its own authority with the missing interview disclosed.

At lifecycle start, assemble a sanitized seed with the request, instructions, known facts, constraints, assumptions, and authority boundaries. Spawn through the peer-context safety gate; validate the initial question-form state; submit one review per decision question; obtain FRONTIER_CLEAR; publish any INTERVIEW_DECISIONS; then execute under the runtime gate.

Keep the detailed reasoning exchange between the two agents. Publish the required question-and-selection record after every cleared decision frontier.

Completion and failure

Set task_complete only after the outcome, context/model evidence, reconnaissance, and tool-visible delegation are recorded; all frontiers and pending_delta are clear; no evidence or authority block remains; and every reopened decision and cleared decision frontier has its review and published record.

After compaction, summarization, resume, or interruption, recover interviewer_started, interviewer_identity, context_safety, peer_model_evidence, delegation_evidence, reconnaissance_summary, path_inventory, intent_hypotheses, evidence_revision, phase, frontier_clear, pending_delta, question_labels, authority_request, decision_reviews, published_decision_records, format_retry_used, and task_complete. Start an interviewer only if this lifecycle never had one; otherwise resume the same interviewer.

If the interviewer is unavailable or fails, do not create a replacement or continue through a conclusion-only fallback. Emit INTERVIEW_UNAVAILABLE and stop at the unresolved interview or authority boundary. This workflow never expands authority.

相关技能

steipete/notion

Notion CLI/API for pages, Markdown content, data sources, files, comments, search, Workers, and raw API calls.

community

affaan-m/seo

Audit, plan, and implement SEO improvements across technical SEO, on-page optimization, structured data, Core Web Vitals, and content strategy. Use when the user wants better search visibility, SEO remediation, schema markup, sitemap/robots work, or keyword mapping.

community

affaan-m/brand-voice

Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.

community

affaan-m/crosspost

Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.

community

affaan-m/x-api

X/Twitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.

community

affaan-m/content-engine

Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.

community