grill-and-share

name	grill-and-share
description	Use when the user wants to stress-test and document a plan for demo purposes - asks up to 3 focused questions, then produces an HTML planning document and a Markdown summary, and optionally posts both to the originating GitHub issue as a comment. Trigger phrases: grill and share, stress-test this plan, review and publish plan, grill my plan.

Grill and Share

You are running a focused demo-planning review. The goal is: ask a few sharp questions, reach a clear shared understanding, then produce polished HTML and Markdown planning documents and (if a GitHub issue is available) post them as a comment.

Step 1 — Gather the Input

Check what the user has provided. Accept any of the following as input:

• A pasted plan or description in the conversation
• A GitHub issue number or URL (e.g. #42 or https://github.com/owner/repo/issues/42)
• A reference to an existing plan document

If a GitHub issue number/URL was given, fetch its body now:

gh issue view <number> --json title,body --jq '"# " + .title + "\n\n" + .body'

Use the fetched content as the plan to review. If no input is provided at all, ask the user for one before continuing.

Step 2 — Ask Up to 3 Questions

Identify the three most important gaps or risks in the plan. Ask them one at a time using ask_followup_question, waiting for each answer before continuing. Do not exceed three questions total.

For each question:

• Provide your recommended answer as the first suggestion
• Keep it tight and decision-forcing — no open-ended "tell me more" questions
• If the answer can be determined by exploring the codebase, do that instead of asking

After all questions are answered, summarise the updated understanding in one short paragraph (2–4 sentences). Show it to the user and confirm they are happy before proceeding.

Step 3 — Produce the Documents

3a — HTML Planning Document

Use create_html_artifact to produce a self-contained HTML one-pager. Structure it as:

• Title — the plan name
• Status badge — e.g. "Draft · Reviewed"
• Summary — the 2–4 sentence synthesis from Step 2
• Key Decisions — a table with columns: Decision | Choice | Rationale (one row per question answered)
• Open Items — any risks or follow-ups surfaced during the review (bullet list)
• Next Steps — ordered list of concrete actions

Follow the standard artifact design rules (single column, ≤760 px, system font, no animations, no external assets).

3b — Markdown Document

Use write_file to save a Markdown version on the project root:

Where <plan-slug> is a kebab-case slug of the plan title (e.g. checkout-flow-plan.md).

If the user provided a markdown file, don't overwrite it. Create a new version with a scripted title in the same location.

Structure the Markdown identically to the HTML: title, summary, key decisions table, open items, next steps.

Step 4 — Confirm Before Posting

Show the user the HTML artifact (already visible) and tell them the Markdown file path. Ask:

"Are you happy with this? I can post it as a comment to the GitHub issue if you have one."

Use ask_followup_question with options:

• "Yes — post to GitHub issue #N" (fill in the issue number if already known)
• "Yes — post to GitHub, let me give you the issue number"
• "No — keep the documents but don't post"

If the user declines, stop here.

Step 5 — Post to GitHub Issue

If the user confirms, post the Markdown content as a comment on the issue:

gh issue comment <number> --body-file <path-to-markdown-file>

If the issue number is not yet known, prompt for it first. After posting, confirm with the issue URL:

gh issue view <number> --json url --jq '.url'

Tell the user the comment was posted and show the issue link.

Constraints

• Maximum 3 questions in Step 2 — no more, even if there are more gaps.
• Never post to GitHub without explicit user confirmation in Step 4.
• If gh is not installed or not authenticated, skip Step 5 and tell the user why.
• Keep the tone direct and decision-focused — this is a demo tool, not a deep-dive research session.