Apply only upon an explicit invocation concerning existing rules or skills, or a clear audit request. Do not apply automatically to general cleanup or implementation requests. Implicit mode is report-only. ownership evidence나 apply approval을 물을 때 host별 native structured question surface를 우선 사용합니다 (Claude Code: AskUserQuestion; Codex: request_user_input; Hermes: clarify). unavailable하면 같은 결정을 plain chat으로 fallback하고 승인 범위를 넘겨 쓰지 않습니다.

Include every field below in the receipt. This is not a separate lifecycle output, but the single evidence record used for and approval decisions.

Scope: <exact repository/user skill scope>
Target paths: <exact paths | none>
Evidence refs: <path:line or unavailable>
Proposal IDs: <GR-## list | none>
Apply authority: report-only | literal --apply | current-turn approval
Audited: <covered paths/categories>
Unaudited: <excluded or incomplete paths/categories>
Verification: <check results or unavailable>
Drift rule: <scope/evidence/target change => Partial/Blocked>

Investigate only the repository or user skill areas explicitly stated or implied by the request. Use the actual host-native skill paths from discovery. Do not create missing files or investigate, migrate, or create repository/user rule state or legacy/global TigerKit state.

Evaluate repository/user skills as independently normative instruction/workflow units, not as whole files. Use only when an exact native skill target exists, and use when independent outcomes are mixed in one artifact. Use only when removing duplication/ambiguity without changing ownership, kind, scope, or meaning. Otherwise, use . If path or ownership evidence is missing or conflicting, treat only that area as .

Determine ownership from confirmed paths and link targets, package-manager installation locations, updater/version artifacts, and verifiable author history. Names and conventions are not evidence. Always treat candidates confirmed as vendor-managed as ; report only quality findings and do not create proposals or edits. If ownership is uncertain, stop before proposing edits and ask whether it is user-managed or externally installed.

Classification alone does not grant modification authority. Even after approval, directly own only meaning-preserving , mechanical with an exact target, unreferenced , and frontmatter/link . Leave semantic , , workflow , and semantic skill rewrites only as exact proposals. These proposals may be handed off to , but this skill does not invoke it. Keep vendor-managed candidates report-only in every apply mode.

Do not invent knowledge or substitute for skill learning.

Continue excluding exclusions declared in the active conversation from subsequent grooming runs in that conversation. Continue excluding exclusions recorded in a governing repository/user rule or another requested durable source across sessions. Do not create hidden global state or store exclusions in .

Evidence records the actual path/content for each area. If required evidence is missing, treat that area as . If any area is blocked, overall completion cannot be claimed; use .

Assign , , ... once, in initial identification order, to each independently normative instruction/workflow. Output one table first.

<short name>

<classification>

<target>

<evidence refs>

Reuse the same IDs for applied changes and verification. Add only when there are evidence gaps, ownership conflicts, unresolved scope, or failed verification. Add and only after mutation. Show findings in two to seven rows. If there are eight or more, show the top five to seven and group the rest by audited target path. Do not create artifact/lifecycle actions solely for output. This is a budget, not a quota.

Record the overall disposition in , but do not repeat the table or append metadata. If there are no items, output one row. Use for vendor rows.