ワンクリックでManusで任意のスキルを実行

spec-grill

スター1

フォーク0

更新日2026年6月6日 12:04

Interview the user relentlessly about every aspect of a plan, walking down each branch of the design tree and resolving dependencies between decisions one-by-one until a shared understanding is reached. Use when pressure-testing a plan, design, or feature idea before implementation, or before running spec-create. Trigger for "grill me", "interview me about this plan", "poke holes in my design", "challenge my assumptions", "stress-test this approach". NOT for writing code or implementing tasks (use spec-impl).

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

jrollin

jrollin/claudio

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Grill Me

Interview the user relentlessly about every aspect of their plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

How It Works

When this skill is invoked, switch into interviewer mode:

Read the plan — understand what the user has described so far.
Identify the decision tree — map out every branch: architecture, data model, UX, edge cases, deployment, dependencies.
Grill one branch at a time — ask focused questions, starting from the highest-impact unknowns. Don't move on until the branch is resolved.
Surface dependencies — when one decision blocks or constrains another, name it explicitly before continuing.
Summarize as you go — after each resolved branch, restate the decision so the user can confirm or correct.
Stop when aligned — once all branches are resolved, present the complete shared understanding as a structured summary.

Rules

Never assume. If something is ambiguous, ask.
One topic at a time. Don't bundle unrelated questions.
Push back. If a decision seems risky or contradictory, say so.
No implementation. This skill is for planning only. Don't write code.
Be direct. Skip pleasantries. Get to the point.
Track progress. Keep a mental map of resolved vs. open branches so the user knows how much is left.

このリポジトリの他の Skills

同じリポジトリ

onboarding

jrollin/claudio

Onboard a developer to an unfamiliar repository, big-picture first. Produces a Purpose/Context section (what the repo is and why it exists), a Big Picture built with C4 diagrams (L1 System Context, L2 Container, optional L3 Component) plus event-reaction flow diagrams for async triggers (stream/queue/schedule/object-event), a Navigating-the-Code section (conventions, lean directory map, testing strategy), a Running-It-Locally checklist with the fast pre-PR loop, a Deploying-It section (deployment model, function/trigger inventory, managed-service graph, envs/secrets, CI/CD), and a Security Posture map — every claim cited to exact files, diagrams before code. Use for "onboard me", "help me understand this repo", "give me an overview", "explain this codebase's architecture", "what architecture pattern does this use", "how is this repo structured", "how do I run this locally", "what's the testing strategy here", "how is this service deployed", "how does CI/CD work here", or "what's the security posture". Read-on

2026-07-161

rust-hexagonal-impl

jrollin/claudio

Orchestrate implementation of one hexagonal Rust slice by dispatching agents in the correct order — build the domain core (model + use case + ports) first, then fan out the driven and driving adapters in parallel, then wire bootstrap serially. Use when you want to implement a ports-and-adapters slice with parallel adapter work that does not interfere. Trigger for "implement this slice hexagonally", "build the domain then the adapters in parallel", "scaffold a ports-and-adapters feature end to end". For the layering RULES themselves use rust-hexagonal; this skill is the DISPATCH recipe.

2026-06-251

doc-diataxis

jrollin/claudio

Structure and write user documentation with the Diátaxis framework (Tutorials, How-to guides, Reference, Explanation). Use when documenting content for users, designing the architecture of a docs set, or deciding what kind of doc a piece of content should be. Trigger for: "document this for users", "write a tutorial", "write a how-to guide", "structure our docs", "organize the documentation", "what kind of doc is this", "how should I document X", "audit our docs", "are these docs in the right place". NOT for: API rule extraction from code (use spec-extract), feature specs (use spec-create), or onboarding a developer to a repo (use onboarding).

2026-06-251

rust-hexagonal

jrollin/claudio

Design or review Rust services using hexagonal (ports and adapters) architecture with idiomatic ownership, errors, and testing. Use when structuring a Rust project, deciding where a trait or dependency belongs, or auditing layering between domain and infrastructure.

2026-06-191

rust-decompose

jrollin/claudio

Structure Rust code into cohesive modules and functions. Use when writing new Rust feature code, adding a module or a non-trivial function, deciding how to organize a file, splitting a god-file into a directory module, breaking a long function into an orchestrator plus phase functions, keeping an owned resource (transaction, lock, accumulator) from leaking across boundaries, or reviewing module/function structure. Apply while writing, not only when refactoring. Architecture-agnostic — any Rust code, hexagonal or not.

2026-06-181

tdd

jrollin/claudio

Use when implementing ANY feature or bugfix — invoke this skill before writing a single line of production code. Trigger for: test-driven development, red-green-refactor cycle, failing tests first, TDD workflow, test-first programming. Also trigger when the user asks to "implement", "add", "build", "fix a bug", "write a function", or "create" anything that involves production code — even if they don't mention TDD. Even if the task seems too simple to need tests, invoke this skill.

2026-05-111

name

spec-grill

description

Grill Me

Interview the user relentlessly about every aspect of their plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

How It Works

When this skill is invoked, switch into interviewer mode:

Read the plan — understand what the user has described so far.
Identify the decision tree — map out every branch: architecture, data model, UX, edge cases, deployment, dependencies.
Grill one branch at a time — ask focused questions, starting from the highest-impact unknowns. Don't move on until the branch is resolved.
Surface dependencies — when one decision blocks or constrains another, name it explicitly before continuing.
Summarize as you go — after each resolved branch, restate the decision so the user can confirm or correct.
Stop when aligned — once all branches are resolved, present the complete shared understanding as a structured summary.

Rules

Never assume. If something is ambiguous, ask.
One topic at a time. Don't bundle unrelated questions.
Push back. If a decision seems risky or contradictory, say so.
No implementation. This skill is for planning only. Don't write code.
Be direct. Skip pleasantries. Get to the point.
Track progress. Keep a mental map of resolved vs. open branches so the user knows how much is left.