Start only through , , or explicit skill selection by the host. Do not implement the current task. Prepare repository evidence and user decisions as one executable . Once the interview starts, continue it naturally in the same conversation without requiring the skill to be invoked again after every answer.

Keep conversation natural and state strict. Do not dump internal scores, stages, or classifications into the default view. Do not ask again about confirmed information. Explain important judgments with the plan and rationale so the user can revise them during the conversation. 사용자 소유의 질문·선택·승인이 필요하면 host별 native structured question surface를 우선 사용합니다 (Claude Code: AskUserQuestion; Codex: request_user_input; Hermes: clarify). unavailable하면 같은 결정을 plain chat으로 fallback하고 secret을 넘기거나 parent-owned 결정을 다시 묻지 않습니다. Do not modify source, tests, configuration, Git, or remote state.

Read the task source, repository instructions, relevant code, tests, verification commands, and current branch/HEAD as needed. Before creating anything new, look for existing , , , , , , , screen patterns, and repository conventions. Do not invent unsupported facts. When possible, connect important repository claims to , command output, or current state.

Ask the user directly only about:

If the source already determines the outcome, do not turn it into another choice question. Ask only the single highest-impact decision at a time. First briefly explain the current understanding, recommendation, and rationale.

Internally evaluate these six dimensions.

Use only . means no evidence, means partial clues, means material gaps, means executable, and means sufficiently closed.

ambiguity = 1 - (
  goal*0.20 + context*0.20 + scope*0.15 +
  decisions*0.15 + acceptance*0.15 + verification*0.15
)

Do not end the interview until all of the following are satisfied.

ambiguity <= 0.20
every dimension >= 0.75
material blockers == 0
unresolved material conflicts == 0

User approval cannot bypass this gate. Show a concise diagnosis only when the user asks about the score or why questions continue.

Evaluate these five dimensions individually; do not offset weaknesses by averaging.

Use the same score units and these Korean statuses for every dimension.

준비됨 | 보완 필요 | 개선 한계 | 예외 승인 | 해당 없음

means . requires a reason. For any deficient dimension, first investigate further → improve the approach → reassess. Only if it still cannot be improved, explain , including the gap, reason, and mitigation, then obtain user exception approval. Do not raise the original score after exception approval.

If there are ACs, close the following strategy before the .

Default to . Do not store usernames, passwords, , OTP, , or secrets in the or chat; handle them only as ephemeral runtime input. If a development server is required, plan for to own startup, readiness checks, and cleanup.

Use only at the repository root as the current task context. The final must let a lower-level executor in a new session, without the original conversation, begin the correct work from only the instruction “진행해”.

Preserve all required meaning self-containedly.

Do not include the full conversation, / progress state, provider model selectors, model IDs, reasoning intensity, receipts, or secrets. Execution recommendations should remain advice at the level of “독립 작업 가능”, “중간급 권장”, or “더 강한 최종 검토 권장”. The current / determines the actual execution form, but AC and Verification are binding contracts.

Treat the following as a hard stop: do not write or begin implementation until every condition below is true.

During the interview, the remains . Change it to only after all of the following are satisfied and the user approves the final natural-language summary.

Understanding Gate pass
Engineering Gate pass or valid user waiver
no material blocker
user final approval
seed write + reread + self-contained check

Do not alter a Ready for implementation convenience. If new evidence during execution or verification materially breaks the goal, scope, decisions, AC, or required verification, re-enter , update only the affected parts, and obtain renewed approval. Suggest recurring repository pitfalls only as candidates for improvement in repository-native owners such as tests, types, schemas, policies, or code invariants; do not promote them automatically. Recurring failures in TigerKit skills are candidates for /; do not create a separate permanent pitfall collection.

완료 시 경로와 핵심 합의·검증·실행 추천을 짧게 알려주고 구현을 자동 시작하지 않습니다.