Install
$ agentstack add skill-zhongmaomao-grill-with-tree-grill-with-tree ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Grill with Tree
Turn ambiguity into explicit, evidence-backed decisions and then into an implementation-ready brief.
Keep this workflow read-only with respect to implementation. Inspect source material freely, and write only decision-state or brief documents unless the user separately authorizes implementation.
Core rules
- Organize the interview by decisions, not implementation tasks.
- Inspect code, documentation, history, configuration, and other available evidence before asking anything locally discoverable.
- Ask only material questions. Different answers must change observable behavior, an interface or architecture contract, risk, reversibility, compatibility, rollout, or delivery scope.
- Ask exactly one unresolved question at a time. If the user answers several decisions voluntarily, record all of them.
- Include a recommended answer, the reason, and the important tradeoff with every question.
- Distinguish known facts, assumptions, recommendations, and user decisions.
- Add child nodes only when an answer exposes a new material choice. Use cross-links instead of duplicating a decision shared by several branches.
- Reopen earlier nodes when new evidence or a later answer invalidates them.
- Never confuse a ready plan with authorization to implement it.
Question format
Use stable node IDs such as D1, D1.1, and D2.
Decision D:
Why this matters:
Recommendation:
Options:
A.
B.
C.
After the answer, update the affected branch. Show the changed branch and the next open node; show the full tree only when it materially helps or the user asks.
Use these node states:
open: requires a decisiondecided: explicitly settledinferred: settled from evidence; identify the evidencedeferred: intentionally postponed with an owner or triggerblocked: cannot be resolved without missing authority or information
Workflow
- Inspect the available sources and summarize the goal, affected surface, known facts, constraints, and non-goals.
- Seed the smallest useful set of root decisions and show the initial tree.
- Walk the highest-impact unresolved branch. Prefer prerequisite decisions before dependent ones.
- After every answer, audit consequences across the relevant dimensions:
- observable behavior and failure paths;
- lifecycle, state ownership, and data flow;
- interfaces and cross-system contracts;
- compatibility, migration, security, privacy, and operations;
- rollout, recovery, and verification.
- Challenge contradictions, optimistic assumptions, missing failure modes, and decisions that move complexity elsewhere.
- Before closing, map every requirement to a resolved decision, test the combined design with counterexamples, and list every remaining assumption.
- Read
assets/decision-tree-brief.mdand use it to produce the final brief. Omit sections that are genuinely irrelevant; do not leave silent gaps. - Derive implementation tasks only after the decisions are settled.
Completion gate
Do not mark the brief ready for implementation until:
- the desired outcome and measurable success criteria are explicit;
- scope, non-goals, and constraints are explicit;
- every material behavior or contract is resolved or visibly deferred;
- ownership, failure handling, compatibility, rollout, and recovery are covered when relevant;
- acceptance criteria and verification are actionable;
- remaining risks and open items have an owner, trigger, or default;
- the execution graph respects real dependencies and shared-write boundaries.
Task decomposition
Keep coupled changes together. Do not target an arbitrary task count.
For every task, record:
- goal and deliverable;
- dependencies and parallel-safe peers;
- exclusive write ownership;
- settled contracts it must preserve;
- forbidden scope;
- acceptance criteria;
- tests or other verification.
Reserve shared-file changes, cross-task integration, and final validation for one explicit owner.
Multi-agent handoff
When the execution graph contains genuinely independent tasks, end with a ready-to-copy handoff:
Use $multi-agent to implement this brief. Treat the Locked Contracts as fixed.
Follow the task dependencies and exclusive write ownership below. Return any
behavior-changing conflict for user resolution before continuing.
If the host exposes skills as slash commands, /multi-agent may be the equivalent invocation.
Do not invoke implementation automatically unless the user has explicitly asked to proceed.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: zhongmaomao
- Source: zhongmaomao/grill-with-tree
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.