# Grill The Task

> Grill a product task (GitHub issue) into implementable work.

- Skill: `blockscout/grill-the-task` (Agent Skill)
- Install (CLI): `npx skillmds@latest add blockscout/grill-the-task`
- Raw SKILL.md: https://api.skillmd.com/api/skills/blockscout/grill-the-task/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: blockscout (https://skillmd.com/u/blockscout)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/blockscout/grill-the-task

---


# Grill the task

Product task issues arrive thin — a title and a couple of links. This skill closes the gap: research
everything researchable, then grill the developer about everything that is a *decision*, tracking what they
can't answer as open questions for the responsible people. Input is a GitHub issue URL.


## Step 1 — Research

Always investigate the question against **primary sources** — official docs, source code, specs, first-party APIs — 
not a secondary write-up of them. **Never ask the developer something that can be looked up** — but do ask,
immediately, when something **blocks the research itself**: the issue has no mockup link, it's unclear which
instance an endpoint is deployed on (staging or production?), a linked doc is inaccessible, a named resource
can't be found in the codebase. Ask to unblock the lookup rather than guessing or silently skipping a source.
Gather, in roughly this order:

1. **The issue** — `gh issue view <n> --repo blockscout/frontend --comments` (needs `gh`; follow the
   `check-github-cli` skill if unsure). Read every linked resource that is accessible: other issues, docs
   pages, Notion pages (via the Notion MCP tools, if connected).
2. **The codebase** — what already exists: similar pages/features to mirror, relevant `service:name`
   resources, feature configs, terms from `.agents/GLOSSARY.md`.
3. **The API** — for every endpoint the issue names, fetch a real sample response (the `resolve-api-url`
   skill resolves instance URLs; then `curl`). Note pagination/sorting/filtering params and whether the API
   is production-deployed or staging-only.
4. **Figma mockups** — via the Figma MCP tools, **enumerate-only**: list screens/frames, their elements,
   columns, states, and record a node link per screen. Do **not** extract visual/styling details — appearance
   stays with the mockups and the `[human]` style leaves (see `.agents/delegation.md`). If the Figma
   MCP is not connected, have the developer describe the mockups instead.

Then run two mechanical cross-checks; every mismatch becomes an open question for the backend owner or PM:

- **Mockup ↔ API sufficiency** — for each element/column a mockup displays, confirm the sample API response
  actually contains that data (e.g. the mockup shows a `receiver` column but the list item model has no
  receiver hash → open question).
- **Field propagation** — when the task adds a new field to an existing model, enumerate **every** UI surface
  that displays that piece of information and verify each backing resource carries the new field — including
  proxy paths (e.g. BENS microservice data proxied through the core API, search results carrying the same info).

Research is complete when every linked source is read or flagged inaccessible, every named endpoint has a
real sample response, and both cross-checks have run with each mismatch recorded as an open question.

## Step 2 — The interview

**Invoke the `grilling` skill** and run the interview under its discipline. Skip anything the research already answered.

**Start by picking the task's contacts**: for each relevant team in `.agents/TEAM.md`, ask which member
owns this task, recommending the member marked ✓ in that team's Default column — and record that ✓ member
whenever the developer has no task-specific pick. These go into the spec header, and Step 3 routes each open
question to the contact that owns it. Don't ask what can be inferred: when the issue's author maps to a
roster member of the relevant team (match the GitHub handle in `.agents/TEAM.md`), record them as that
team's contact without asking — the PM slot in particular is usually just the task's author. When the
developer doesn't know an answer, don't press — record the question with the owning contact and move on.

Cover these domains, each only where the task actually reaches it — a one-line bug fix touches almost none
of them, and marching through all six regardless is how a five-minute task turns into a twenty-minute one:

1. **Goal & users** — what problem, for whom.
2. **Env gating** — does the feature sit behind a new `NEXT_PUBLIC_*` env var or not. (Just the decision —
   the mechanics belong to the `add-env-var` skill at implementation time.)
3. **Data & API** — anything Step 1 left open: readiness of staging-only endpoints, missing params, and
   **which upcoming backend release ships the required API changes** (so the frontend release notes can
   reference it) — usually a question for the backend owner.
4. **UI inventory** — routes, navigation entry points (where do users find this?), cross-links to existing
   entity pages. Behavioral states and mobile behavior are standard — don't ask.
5. **Analytics & links** — custom Mixpanel events **only** if there's a new interactive element worth
   tracking (page views are auto-wired); UTM query params on any hardcoded links to Blockscout or partner
   products.

Testing is **not** an interview domain — the capability boundary in `.agents/delegation.md` settles it.
Neither is human verification: which acceptance criteria are `(human)` follows the standing rule in "The
ticket model" in `.agents/tasks/concepts.md`. Only ask when one sits genuinely on the line.

The interview is complete when every domain the task reaches is covered or explicitly skipped as
research-answered, the contacts are settled, and every unanswered question has an owner.

## Step 3 — Send open questions

Route every question the session couldn't answer to the person who owns it.

1. Group them by owner.
2. Pick each group's destination. Ask whether the task has a **dedicated Slack channel** only when the task
   is large enough to warrant a spec — big features often get one, and it changes the routing; otherwise
   assume there is none.
   - Task has a **dedicated feature channel** → **all** questions go there, API ones included.
   - Otherwise, **product questions go to the frontend channel** (see `.agents/TEAM.md`) — never a DM — so
     colleagues from other teams (QA in particular) build the same understanding of the feature.
   - Other questions (API, design) default to a DM with the owner.
   - When posting to a channel, **always mention the addressee** — `<@member ID>` from `.agents/TEAM.md`
     (people missing from the roster: resolve by name via `slack_search_users` and suggest adding them).
3. Draft one message per owner: brief task context (issue link), the questions, and why they block progress.
   Write all Slack messages in **Russian** — the team's internal language (the spec itself stays in English).
4. **Show every draft (with its destination) to the user and wait for explicit approval** — never send
   unreviewed *new* outreach. (In-thread follow-ups on a thread already approved here are exempt — see
   "Watch for replies" below.)
5. Send (`slack_send_message`), then keep each thread's permalink for the question's `questions.md` entry.

If the Slack MCP tools are unavailable, record the questions with owners anyway and tell the user to route
them manually.

Outreach is complete when every question has a recorded permalink — or an explicit note that the developer
routes it manually.

### Watch for replies and drive each question to settled

Once the questions are sent, don't hand the reply round-trip back to the developer to poll. Launch the
**`slack-watch`** skill with one `CHANNEL:THREAD_TS` argument per `pending` question thread (the channel
id and parent `ts` from each `slack_send_message` you just sent). That skill owns how to start, stop, and
relaunch on Claude Code vs Cursor — follow it. Adding or resolving a question later means stopping the
watcher and relaunching with the new thread list; questions move at human pace, so the restart is free.
If the tokens aren't set up, `slack-watch` guides the developer through it; until then, the developer
polls manually as before.

On each `NEW …` notification, read the reply with `slack_read_thread` on that `thread_ts`, then for the
question that thread belongs to:

- **Assess** the reply against the question's `Resolved when:` criterion — session-held here, since this
  runs before `to-spec`; it only becomes a `questions.md` line once `to-spec` writes one (lifecycle step 2).
- **Insufficient** → send a clarifying **follow-up to the colleague directly, in the same thread, without
  developer approval** — this is continuing a conversation the developer already opened. Cap: **3**
  consecutive follow-ups per question, then escalate. Opening a *new* thread or contacting a *new* person
  stays approval-gated (Step 3 rules unchanged).
- **Sufficient** → **propose in the session chat**: the answer arrived, the proposed resolution, and the
  edits it implies. **Edit no file.** Apply only after the developer accepts in-session. Where the answer
  lands depends on how far the task has come: once `to-spec` has run, fold it into `questions.md` (the
  fold-in is `.agents/tasks/README.md` step 4) — so `implement-ticket`'s question gate never releases work
  a human hasn't read; before that (still grilling, or a small task that never gets a spec), hold it in
  session to inform the forthcoming spec or to unblock the in-session implementation.
- **Escalate** (one line: which task/question and why it's stuck) when the answer needs *frontend*
  knowledge only the developer has, the 3-follow-up cap is hit, or the colleague goes silent.
  Claude Code: `PushNotification` with that line. Cursor: the same line in this session chat — Cursor has
  no OS nudge.

Every message posted to a colleague carries a disclosure — they must be able to tell they're in a
technical back-and-forth with an agent. Prefer the Slack connector's own attribution if it appends one;
otherwise append `— via @Honk 🪿`. All follow-ups stay in **Russian**, like the original outreach.

## Step 4 — Size and hand off

Decide, by a rough sizing judgment, whether the task needs a spec — one session of work or not. No formal
breakdown is needed for this call ("Not every task needs a spec" in `.agents/tasks/README.md`).

- **Small task** — implement it in this same session, then hand off to the `create-pr` skill. If a `pending` question blocks the work, wait for the
  reply and pick the implementation back up here.
- **Larger task** — suggest proceeding with the `to-spec` skill **in this same session**.