tk-grill-me

Decision check

Explicit /tk-grill-me or $tk-grill-me invocation, exact active tk-drive decision handoff, or in the same conversation this skill's pending question Use it for a user answer to. Do not auto-activate for general ambiguity, artifact existence, general follow-up progress, or unrelated answers.

Owns one evidence-first decision procedure. Standalone execution and active-drive callers share the procedure, safety boundaries, and completion criteria, and differ only in result routing.

Contract

Never confirm a user decision without an explicit answer. Silence, mere progress, factual grounds, or similar past answers are not consent.

The invocation mode controls how it is presented:

standalone: Display one pending question or the final decision result to the user.
active drive: Return the same decision state internally so that tk-drive directly continues with the next applicable procedure. Terminal result, receipt, Pass, or do not render the interruption surface specified by the caller.

It is read-only. It never writes sources, Drive R/AC, units, ADRs, or commits, and tk-drive, never invokes new workers or adjacent workflow owners.

Procedure

입력 읽기: Bind task identity, caller mode, source, current evidence, confirmed decisions, unresolved user-owned decisions, and pending question.
사실 조사: The source location is specified verified | inferred | unavailable generate the fact.
명시 제약 선별: If the source or requirements statement directly specifies the result without conflict, record it as Constraintrather than promoting it to a user choice. If the result is merely inferred or conflicts with another source, do not apply this exception.
공백 식별: Scope, Constraints, Outputs, Verification throughout compare facts and decisions.
순위 지정: The blockerthat blocks safe progress, scope or irreversible impact, verification blocker, downstream rework, in that order, select the unresolved decision with the greatest impact.
ask: 🙋 grill-me · 응답 필요 After outputting, exactly one Question, 👍 Recommendation, Evidence in that order and pending stop at.
반영: Preserve the explicit answer as a matching Decision, Constraint, Out of scope, Output, or Verification entry.
반복 또는 종료: Do not repeat questions already answered. Once all four axes are settled, present one agreed goal statement for explicit approval.
확정: Only after explicitly approving that statement, confirmed return.

In the question turn of standalone execution, below packetdisplay only to the user. Label as boldand place a blank line between each item. Evidence uses one bullet per fact, and each bullet에 source와 verified | inferred | unavailable are written together. If there is no evidence, unavailable state the fact as a single bullet. In an active drive, this packetis not displayed and the same status is returned directly to the caller.

🙋 grill-me · 응답 필요

**Question**
<정확히 하나의 user-owned decision>

**👍 Recommendation**
<safe default 또는 none>

**Evidence**
- <fact> (`verified | inferred | unavailable`, <source>)
- <fact> (`verified | inferred | unavailable`, <source>)

**Native status**: pending

Ambiguity Ledger

The ledger is maintained only within the conversation:

Scope: included and excluded actions;
Constraints: technical, operational, or business constraints, or explicitly none;
Outputs: required actions, deliverables, outcomes;
Verification: acceptance criteria and completion evidence.

Separate unresolved items, confirmed decisions, and unverified assumptions. The ledger is not a per-turn dump template. A Question turn includes only newly created or changed evidence, the selected unresolved item, and one question.

Facts and user judgment

Auto-confirm only current facts backed by exact repository or runtime evidence; cite the source.
If a code pattern conclusion requires judgment, inferred mark it as such.
Before asking a question that mixes facts and choices, investigate the current facts first.
If a source or requirements statement directly specifies the outcome and does not conflict, record it as confirmed Constraintand do not ask again. Side effects derived from that outcome are left in Assumptions or Remaining risks.
If a question or option depends on domain term(예: dvh, svhwith 0 repository usage cases, before presenting the options, explain the user-visible outcome difference in 1 to 3 lines and mark the usage evidence as verified | inferred | unavailable. Place this explanation inside Evidence and do not create arbitrary elaboration outside the packet.
Always ask about goals, scope, priorities, business rules, success criteria, and new behavior.
If the necessary evidence is inaccessible, return Unverifiable . Exception: when an independent decision is still safe.
If confirmed sources conflict, preserve both and ask one decision question; do not silently choose.

Answer preservation and closure

Preserve the meaning of free-form answers. Leave unstated content as an assumption. Request clarification only when a summary changes meaning, conflicts with confirmed evidence, or creates material ambiguity.

done and model confidence alone do not close the ledger. Verify all four axes, and in an unresolved state, ask the next highest-impact question and require explicit approval of the final agreed goal statement.

For independently executed confirmed results, use only a nonempty ## Decisions, ## Assumptions, ## Remaining risks . Do not attach phase/status sources. For one decision, use one to three lines; for complex sets, use two to seven readable rows or bullets. If there are eight or more, keep only the top five to seven along with the owning source or spec reference.

Prohibitions / Anti-patterns

Do not split the same decision procedure into different skills.
Do not decide on behalf of the user or bundle independent decisions together.
Do not modify artifacts or invoke downstream phase owners.
Do not let active-drive routing result in a receipt or terminal interruption.