@tea-agent/loop-agent 0.12.0 → 0.13.0-beta.0

package/skills/frontend-implementation/references/node-contracts.md

@@ -1,32 +1,76 @@
-# Frontend Node Contracts
-
-## `frontend-contract-pi`
-
-- Read task source, constraints, `task.json`, and explicit references; do not edit.
-- Define scope, non-goals, routes/components, runtime, user flows, acceptance criteria, states, risks, and verification expectations.
-- Preserve requirement IDs and language; never turn an implementation guess into a requirement.
-- For every standard UI state, specify behavior or mark it not applicable with a reason.
-- Output: `Scope`, `Non-goals`, `Acceptance Criteria`, `UI States`, `Target Runtime Environment`, `Risks`, `Verification Expectations`.
-
-## `frontend-scout-pi`
-
-- Inspect routes, pages, components, styles/tokens, state/data flow, API/mocks, scripts, tests, and reusable assets; do not edit.
-- Separate confirmed facts, inferred conventions, and missing information.
-- Attempt knowledge-base first. If absent, failed, or unmatched, recursively inspect `<repoRoot>/openSpec/**` before other repo conventions.
-- Record source as `knowledge-base`, `openSpec fallback`, `repository fallback`, or `unavailable`, with query/search terms and matched paths.
-- Output: `Frontend Stack`, `Routes`, `Components`, `Styling System`, `Existing Design Conventions`, `State / Data Flow`, `Test Entry Points`, `Reuse Opportunities`, `Risks`.
-
-## `frontend-plan-pi`
-
-- Map every acceptance criterion to ordered implementation and verification steps.
-- Name target files and reasons; keep them within allowed paths and expected `writeSet`.
-- Define states, component/styling reuse, interaction behavior, dependency policy, and exact static/behavior commands.
-- Knowledge-base failure is not approval: apply relevant `openSpec/` matches as current-project rules. Request clarification only when neither source resolves required compliance or they conflict materially.
-- Output: `Implementation Steps`, `Target Files`, `UI State Handling`, `Styling / Component Strategy`, `Interaction Notes`, `Dependency Policy`, `Verification Plan`, `Residual Risks`.
-
-## `frontend-implement-pi`
-
-- Run only after design gate pass and implement only the approved plan inside `writeSet`.
-- Re-read current files; stop instead of crossing forbidden paths or guessing a blocking decision.
-- Reuse confirmed project primitives and update tests. Do not claim knowledge-base or downstream verification without evidence.
-- Output: `Changed Files`, `Implemented Behavior`, `UI States Covered`, `Styling / Component Notes`, `Verification Attempted`, `Residual Risks`.
+# Frontend Node Contracts
+
+All pre-write nodes are read-only. Preserve IDs, source labels, commands, language,
+and required headings.
+
+## `frontend-contract-pi`
+
+Read all inputs and define `Scope`, `Non-goals`, `Acceptance Criteria`, `UI States`,
+`Target Runtime Environment`, `Risks`, and `Verification Expectations`. Never turn a
+guess into a requirement.
+
+## `frontend-scout-pi`
+
+Inspect routes, components, styles/tokens, data/API/Mock seams, scripts, tests, and
+assets. Separate fact, inference, and gap. Query the knowledge base; otherwise search
+and read `<repoRoot>/openSpec/**` before repository fallback. Output `Frontend Stack`,
+`Routes`, `Components`, `Styling System`, `Existing Design Conventions`, `State / Data
+Flow`, `Test Entry Points`, `Reuse Opportunities`, and `Risks`.
+
+## `frontend-mock-assess-pi` and contract gate
+
+Consume contract, scout, generation-time capability seed, and frozen verification
+entrypoints. First non-empty line:
+
+`MOCK_STRATEGY: native|browser-intercept|request-adapter|not-needed|blocked`
+
+Prefer a proven native service. Use browser interception only with an existing
+browser/e2e harness, or a request adapter/DI seam for reversible local preview.
+`not-needed` requires positive no-remote/stable-real-backend evidence and applicable
+behavior verification; it is invalid when `frontendMock.policy=required` resolved to
+a required decision. Select `blocked` for missing/conflicting contracts, unsafe or
+unauthorized paths/dependencies, unread/conflicting specs, production-default-on
+behavior, or frozen entrypoints that cannot verify the selected mechanism.
+
+Output `Mock Decision`, `API Contract Evidence`, `Specification Evidence`, `Service
+Evidence`, `Backend Readiness`, `Selection Evidence`, `Endpoint / Fixture Matrix`,
+`Activation`, `Target Files`, `Production Safety`, `Verification Plan`, `Real
+Integration Gap`, and `Blocking Issues`. Trace methods, paths, fields, statuses, UI
+states, fixtures, and consumers to API/schema evidence. Never invent fields, store
+secrets/real user data, comment real requests, import test mocks from production, or
+claim Mock evidence is real integration.
+
+`frontend-mock-contract-gate-shell` accepts only allowed non-blocked strategy lines
+using `first-non-empty`; it never authorizes writes. A generation-time unsafe or
+incomplete explicitly-required contract produces contract/scout/assessment/gate only,
+with no writer.
+
+## `frontend-plan-pi` and design loop
+
+Plan directly consumes contract, scout, assessment, and gate. Map criteria to
+ordered steps, in-bound files, UI states, interactions, reuse, dependencies,
+activation/rollback, fixed verification entrypoints, and the real-integration gap.
+Output `Implementation Steps`, `Target Files`, `UI State Handling`, `Styling /
+Component Strategy`, `Interaction Notes`, `Mock / API Strategy`, `Dependency Policy`,
+`Verification Plan`, `Real Integration Gap`, and `Residual Risks`.
+
+The first design gate accepts `VERDICT: pass` or `VERDICT: request-revision` for
+read-only revision. On pass, `frontend-plan-revision-pi` outputs
+`PASS_NO_REVISION_NEEDED`; otherwise it returns a complete corrected plan without
+manufacturing evidence. Final design review directly rechecks the original plan,
+first findings, revision, assessment, and all Mock safety boundaries. Only the final
+`VERDICT: pass` gate authorizes writes; failure routes to replan/rerun, not dev-fix.
+
+## `frontend-implement-pi`
+
+This is the sole exclusive writer. Consume the approved plan, final review/gate, and
+assessment. Implement only inside `writeSet`; keep the real request default and Mock
+activation reversible, dev/test-only, and production-off. Native handler/fixture,
+browser interception, or request adapter changes stay atomic with their UI consumer
+and tests. Stop on forbidden paths or guesses. Output `Changed Files`, `Implemented
+Behavior`, `UI States Covered`, `Styling / Component Notes`, `Verification Attempted`,
+and `Residual Risks`.
+
+When trusted Mock-specific commands were frozen at generation, a read-only
+`frontend-mock-verify-shell` runs after the writer. Static and behavior verification
+always run; behavior must prove page consumption, not merely handler unit tests.

package/skills/frontend-review/SKILL.md

@@ -1,53 +1,59 @@
----
-name: frontend-review
-description: Use to review completed frontend code and verification before closeout.
-references:
-  - path: references/review-findings.md
-    required: true
----
-
-# Frontend Review
-
-Use for `frontend-review-pi`; read the findings guide first. Required inputs are
-original task/reference material, derived contract/constraints, approved plan and
-design verdict, implementation summary, actual diff, and shell evidence. Missing
-actual diff or required evidence forces revision; never infer it from a summary.
-
-## Verdict Contract
-
-The first non-empty line must be exactly `VERDICT: pass` or
-`VERDICT: request-revision`. Any Critical/Important finding, failed or missing
-required check, forbidden write, or unmet acceptance criterion forces revision.
-
-## Review Scope
-
-- Compare original intent, derived artifacts, approved plan, actual diff, and evidence; report lost or altered requirements.
-- Inspect every changed file against allowed, forbidden, and approved write scope.
-- Map criteria to behavior, applicable UI states, tests, and shell evidence.
-- Review state/data flow, validation, async/error behavior, components/design, responsive behavior, accessibility, dependencies, maintenance, and regression risk when applicable.
-- Component/design claims require traceable knowledge-base evidence or, after connection/query failure or no match, relevant `<repoRoot>/openSpec/**` evidence. The connector format is TODO; never claim a query or fallback search without evidence.
-- Treat shell exit status as authoritative. Do not edit files.
-
-## Evidence And Output
-
-Findings cite a tight file location, exact command/result, or named DAG artifact.
-Separate confirmed defects, missing evidence, and residual risks.
-
-```markdown
-VERDICT: request-revision
-
-## Findings
-- [Important] `path:line` — issue, impact, and required correction.
-
-## Verification Assessment
-- ...
-
-## UX Assessment
-- ...
-
-## Residual Risks
-- ...
-```
-
-A pass requires no Critical/Important findings and all required shell checks passed.
-Still report knowledge-source status and optional browser/manual gaps.
+---
+name: frontend-review
+description: Use to review completed frontend code and verification before closeout.
+references:
+  - path: references/review-findings.md
+    required: true
+    maxChars: 2800
+---
+
+# Frontend Review
+
+Use for `frontend-review-pi`; read the findings guide first. Required inputs are
+original task/reference material, contract/constraints, Mock assessment, original and
+revised/confirmed plan, final design verdict, implementation summary, actual diff,
+and static/behavior/optional Mock shell evidence. Missing actual diff or required
+evidence forces revision; never infer it from a summary.
+
+## Verdict Contract
+
+The first non-empty line must be exactly `VERDICT: pass` or
+`VERDICT: request-revision`. Any Critical/Important finding, failed or missing
+required check, forbidden write, or unmet acceptance criterion forces revision.
+
+## Review Scope
+
+- Compare intent, contract, plan, diff, and evidence; report altered requirements.
+- Inspect every changed file against allowed, forbidden, and approved write scope.
+- Map criteria to behavior, applicable UI states, tests, and shell evidence.
+- Review state/data flow, validation, async/error behavior, components/design, responsive behavior, accessibility, dependencies, maintenance, and regression risk when applicable.
+- Inspect static, behavior, and available Mock-specific artifacts directly. For Mock
+  strategies, compare the endpoint matrix, handler/fixture/adapter and consumer diff;
+  require the real request as default, contract-aligned fixtures, production isolation,
+  and no false real-integration claim. `not-needed` needs applicable real/no-remote evidence.
+- Component/design claims require traceable knowledge-base evidence or, after connection/query failure or no match, relevant `<repoRoot>/openSpec/**` evidence. The connector format is TODO; never claim a query or fallback search without evidence. Execute explicit `grep`/`find` to locate spec files and `read` to load them before referencing their rules. Only successful `read` tool calls are observable as "已读取规范文件" in the spec-evidence inspector.
+- Treat shell exit status as authoritative. Do not edit files.
+
+## Evidence And Output
+
+Findings cite a tight file location, exact command/result, or named DAG artifact.
+Separate confirmed defects, missing evidence, and residual risks.
+
+```markdown
+VERDICT: request-revision
+
+## Findings
+- [Important] `path:line` — issue, impact, and required correction.
+
+## Verification Assessment
+- ...
+
+## UX Assessment
+- ...
+
+## Residual Risks
+- ...
+```
+
+A pass requires no Critical/Important findings and all required shell checks passed.
+Still report knowledge-source status and optional browser/manual gaps.

package/skills/frontend-review/references/review-findings.md

@@ -1,42 +1,47 @@
-# Frontend Review Findings Guide
-
-## Severity
-
-- **Critical**: blocks primary flow, corrupts data, violates security/privacy, writes forbidden paths, or bypasses required verification.
-- **Important**: acceptance/state/validation gap, material convention drift, missing behavior tests, unauthorized dependency, or failed/missing required verification.
-- **Minor**: non-blocking maintainability, copy, layout, or cleanup issue.
-
-## Evidence
-
-- Cite tight file locations, exact commands/results, or named DAG artifacts.
-- Never invent evidence; name the missing check. An implementation summary is not the actual diff.
-- Failed required static/behavior verification is at least Important unless proven unrelated.
-- A knowledge-base claim records connector/query, source ID/version, and retrieval time. If absent, failed, or unmatched, review evidence must show `<repoRoot>/openSpec/**` search terms and matched paths/headings; label `openSpec fallback`, `repository fallback`, or `unavailable` accurately.
-
-## Review Sequence
-
-1. Establish changed-file inventory and write boundaries.
-2. Compare original requirement with derived contract/constraints.
-3. Map each criterion to code, states, tests, and evidence.
-4. Inspect interactions, state/data/API behavior, failure paths, and regression risk.
-5. Check component/design evidence, responsive/accessibility behavior, dependencies, and maintenance fit when applicable.
-6. Classify findings and derive the verdict mechanically.
-
-Skipping the required `openSpec/` search after knowledge-base failure is Important
-when component/design compliance affects acceptance or implementation choices.
-
-Use one issue per finding:
-
-```text
-- [Critical|Important|Minor] path:line — Problem; impact; required correction; evidence.
-```
-
-Avoid vague advice. When no source location exists, cite the command or artifact.
-
-## Pass Rules
-
-- No Critical or Important findings remain.
-- Required static and behavior nodes ran and passed.
-- Changed files are authorized.
-- Criteria and applicable states have implementation and evidence.
-- Optional unavailable knowledge-base, browser, visual, or manual checks remain explicit risks.
+# Frontend Review Findings Guide
+
+## Severity
+
+- **Critical**: blocks primary flow, corrupts data, violates security/privacy, writes forbidden paths, or bypasses required verification.
+- **Important**: acceptance/state/validation gap, material convention drift, missing behavior tests, unauthorized dependency, unsafe mock activation/import, mock-contract drift, misleading real-integration claim, or failed/missing required verification.
+- **Minor**: non-blocking maintainability, copy, layout, or cleanup issue.
+
+## Evidence
+
+- Cite tight file locations, exact commands/results, or named DAG artifacts.
+- Never invent evidence; name the missing check. An implementation summary is not the actual diff.
+- Failed required static/behavior verification is at least Important unless proven unrelated.
+- A knowledge-base claim records connector/query, source ID/version, and retrieval time. If absent, failed, or unmatched, review evidence must show `<repoRoot>/openSpec/**` search terms and matched paths/headings; label `openSpec fallback`, `repository fallback`, or `unavailable` accurately.
+
+## Review Sequence
+
+1. Establish changed-file inventory and write boundaries.
+2. Compare original requirement with derived contract/constraints.
+3. Map each criterion to code, states, tests, and evidence.
+4. Inspect interactions, state/data/API behavior, failure paths, and regression risk.
+5. Check mock selection, contract-to-fixture mapping, activation/default path,
+   handler/fixture/adapter and consumer diff, optional Mock-specific verification,
+   production imports, evidence scope, and the documented real-integration gap.
+6. Check component/design evidence, responsive/accessibility behavior, dependencies, and maintenance fit when applicable.
+7. Classify findings and derive the verdict mechanically.
+
+Skipping the required `openSpec/` search after knowledge-base failure is Important
+when component/design compliance affects acceptance or implementation choices.
+
+Use one issue per finding:
+
+```text
+- [Critical|Important|Minor] path:line — Problem; impact; required correction; evidence.
+```
+
+Avoid vague advice. When no source location exists, cite the command or artifact.
+
+## Pass Rules
+
+- No Critical or Important findings remain.
+- Required static and behavior nodes ran and passed.
+- Changed files are authorized.
+- Criteria and applicable states have implementation and evidence.
+- Required Mock-backed behavior passed; any generated Mock-specific verification also
+  passed; Mock is not enabled by default in production.
+- Optional unavailable knowledge-base, browser, visual, or manual checks remain explicit risks.

package/skills/frontend-verification/SKILL.md

@@ -1,40 +1,53 @@
----
-name: frontend-verification
-description: Use to assess frontend evidence and produce closeout.
-references:
-  - path: references/verification-checklist.md
-    required: true
----
-
-# Frontend Verification
-
-Use for `frontend-closeout-pi`. Shell nodes execute commands; this read-only skill
-assesses their evidence. Read the checklist first.
-
-Required inputs: criteria, implementation summary/change inventory, static and
-behavior shell commands/source/status/artifacts, review verdict/findings, and any
-required browser, visual, manual, or knowledge-base validation.
-
-## Evidence Rules
-
-- Static evidence covers type/lint/build/schema checks; behavior evidence covers tests or interaction checks that actually exercise the flow.
-- Shell exit status is authoritative. Classify checks as `passed`, `failed`, `not-run`, `blocked`, or `unavailable`; only passed satisfies a required check.
-- Never use static success as behavior proof, or tests as visual/browser proof they did not exercise.
-- Unavailable commands remain gaps, not weaker success claims.
-- Resolve component/design evidence as knowledge base first, then `<repoRoot>/openSpec/**` when setup/query fails or has no match. Mark `openSpec fallback` as the active project specification source; do not report it as missing merely because the connector format is TODO.
-
-## Method And Output
-
-Inventory required checks, map each to fresh evidence, classify gaps, confirm review
-pass, and state only proven user-visible changes.
-
-Return Markdown headings:
-
-- `Changes`: changed behavior and areas.
-- `Verification Evidence`: table of check, command/source, status, and artifact/result.
-- `Review Result`: exact review verdict and findings.
-- `Known Risks`: missing optional checks and environment caveats.
-- `Follow-up`: concrete work or `None`.
-
-Do not edit files. Do not claim complete when review is not pass or a required check
-is failed, not-run, blocked, unavailable, stale, or contradicted.
+---
+name: frontend-verification
+description: Use to assess frontend evidence and produce closeout.
+references:
+  - path: references/verification-checklist.md
+    required: true
+    maxChars: 2800
+---
+
+# Frontend Verification
+
+Use for `frontend-closeout-pi`. Shell nodes execute commands; this read-only skill
+assesses their evidence. Read the checklist first.
+
+Inputs: criteria, change inventory, shell commands/status/artifacts, review
+verdict/findings, and required browser, visual, manual, or knowledge evidence.
+
+## Evidence Rules
+
+- Static evidence covers type/lint/build/schema; behavior evidence must exercise the flow.
+- Shell exit status is authoritative. Classify as `passed`, `failed`, `not-run`,
+  `blocked`, or `unavailable`; only passed satisfies a required check.
+- Never use static success as behavior proof, or tests as visual/browser proof they did not exercise.
+- Mock-backed behavior proves frontend rendering and state transitions only. It never
+  proves backend readiness, transport compatibility, or real API integration.
+- Unavailable commands remain gaps.
+- Resolve design evidence via knowledge base, then `<repoRoot>/openSpec/**` after
+  failure/no match. Its connector format remains TODO; never invent it. An applied
+  `openSpec fallback` is available project evidence.
+- Separate Mock service/handler checks from page consumption and record the
+  dev/test-only boundary; handler tests alone do not prove page use.
+
+## Method And Output
+
+Map required checks to fresh evidence, classify gaps, confirm review pass, and state
+only proven changes.
+
+Return Markdown headings:
+
+- `Changes`: changed behavior and areas.
+- `Mock Decision`, `Mock Files`, `Mock Verification`, `Production Boundary`: status is `passed`, `failed`, `not-required`, `blocked`, or `unavailable`.
+- `Verification Evidence`: table of check, command/source, status, and artifact/result.
+- `Review Result`: exact review verdict and findings.
+- `Known Risks`: missing optional checks and environment caveats.
+- `Follow-up`: concrete work or `None`.
+
+When the backend remains unavailable but required mock-backed checks pass, state
+`Frontend status: mock-validated` and `Real integration: pending`. Use a completed
+`<task-id>-real-api-integration-verify` task before changing the latter to complete;
+the follow-up is explicit, not auto-created or auto-executed.
+
+Do not edit files. Do not claim complete when review is not pass or a required check
+is failed, not-run, blocked, unavailable, stale, or contradicted.

package/skills/frontend-verification/references/verification-checklist.md

@@ -1,56 +1,68 @@
-# Frontend Verification Checklist
-
-## Static And Behavior Evidence
-
-- Type/compile, lint/format, build, and schema/client checks ran when required.
-- Generated output was authorized.
-- Unit/component/integration tests cover changed logic and flows; regressions pass.
-- Browser/e2e/manual evidence exists when explicitly required.
-- API/mock behavior and applicable loading, empty, error, success, disabled, permission, retry, and boundary states have evidence.
-
-## Design And Component Evidence
-
-- Claims cite traceable knowledge-base retrieval or relevant `<repoRoot>/openSpec/**` fallback evidence.
-- Retrieval includes connector/query, collection/document ID, version when available, and time.
-- When connector setup/query fails or has no match, evidence shows recursive `openSpec/` search terms, inspected paths, matched headings/lines, and applied rules.
-- Relevant `openSpec/` matches become the current-project specification and satisfy source availability; only the knowledge-base connection remains unavailable.
-- Missing both sources blocks explicit compliance or an unresolved required design decision.
-
-## Status
-
-- `passed`: fresh successful evidence matches current implementation.
-- `failed`: check ran and failed.
-- `not-run`: no fresh attempt exists.
-- `blocked`: a prerequisite prevented execution.
-- `unavailable`: tool, environment, connector, or source was absent.
-
-Only passed satisfies a required check. Other optional statuses remain disclosed risks.
-
-## Closeout Checks
-
-- List exact commands, source, exit status, and archived output/artifact when available.
-- Map every criterion to evidence or a named gap.
-- Record review verdict before completion.
-- Do not conflate static, behavior, browser/visual/manual, or knowledge-base proof.
-
-```markdown
-## Changes
-- ...
-
-## Verification Evidence
-| Check | Command or source | Status | Evidence |
-|---|---|---|---|
-| ... | ... | passed | ... |
-
-## Review Result
-- Verdict: `VERDICT: pass`
-
-## Known Risks
-- ...
-
-## Follow-up
-- None.
-```
-
-If review is not pass or a required check is not passed, describe the task as
-incomplete and list concrete follow-up.
+# Frontend Verification Checklist
+
+## Static And Behavior Evidence
+
+- Type/compile, lint/format, build, and schema/client checks ran when required.
+- Generated output was authorized.
+- Tests cover changed logic/flows and regressions.
+- Browser/e2e/manual evidence exists when explicitly required.
+- Selected-strategy behavior and applicable loading, empty, error, success, disabled,
+  permission, retry, and boundary states have evidence from fixed DAG entrypoints.
+- When generated, Mock-specific verification checks service/handler/schema/fixtures;
+  behavior evidence separately proves page consumption.
+- For Mock strategies, activation is explicit/non-production and a production/default-
+  real-path build with Mock off confirms the real request remains default.
+- `not-needed` has positive readiness/no-remote evidence plus applicable real or
+  no-remote behavior evidence. Mock-backed evidence remains frontend-only and never
+  satisfies real API integration.
+
+## Design And Component Evidence
+
+- Claims cite knowledge-base retrieval or `<repoRoot>/openSpec/**` fallback.
+- Evidence records query/source/version/time or fallback search terms, paths, headings, and applied rules.
+- Relevant `openSpec/` matches become the current-project specification and satisfy source availability; only the knowledge-base connection remains unavailable.
+- Missing both sources blocks explicit compliance or an unresolved required design decision.
+
+## Status
+
+- `passed`: fresh successful evidence matches current implementation.
+- `failed`: check ran and failed.
+- `not-run`: no fresh attempt exists.
+- `blocked`: a prerequisite prevented execution.
+- `unavailable`: tool, environment, connector, or source was absent.
+
+Only passed satisfies a required check. Other optional statuses remain disclosed risks.
+
+## Closeout Checks
+
+- List exact commands, source, exit status, and archived output/artifact when available.
+- Map every criterion to evidence or a named gap.
+- Record review verdict before completion.
+- Do not conflate static, behavior, browser/visual/manual, or knowledge-base proof.
+- If only mock evidence exists, report `Frontend status: mock-validated` and
+  `Real integration: pending`, with the actual API verification as follow-up.
+
+```markdown
+## Changes
+- ...
+
+## Verification Evidence
+| Check | Command or source | Status | Evidence |
+|---|---|---|---|
+| ... | ... | passed | ... |
+
+## Mock Decision / Mock Files / Mock Verification / Production Boundary
+- Status: `passed | failed | not-required | blocked | unavailable`
+
+## Review Result
+- Verdict: `VERDICT: pass`
+
+## Known Risks
+- ...
+
+## Follow-up
+- None.
+```
+
+If review is not pass or a required check is not passed, describe the task as
+incomplete and list concrete follow-up.

package/skills/grill-me/SKILL.md

@@ -1,10 +1,10 @@
----
-name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
----
-
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.