tink-harness 1.9.19 → 1.9.21

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "tink",
   "description": "A small harness layer for Claude Code and Codex.",
-  "version": "1.9.19",
+  "version": "1.9.21",
   "author": {
     "name": "dotori"
   }

package/CHANGELOG.md

@@ -6,6 +6,19 @@ All notable changes to Tink are tracked here.
 
 No unreleased changes yet.
 
+## [1.9.21] - 2026-06-11
+
+### Changed
+
+- README repositioned problem-first (EN/KO): the hero now leads with "Stop losing context between Claude Code and Codex runs", followed by Who-this-is-for, a concrete tour of the files Tink leaves behind, and a "Why not just CLAUDE.md / slash commands / skills / MCP?" comparison table. The knitting metaphor moved into the origin-story section, and a small star call-to-action sits under the demo GIF. Added a release-pacing note to VERSIONING.md.
+
+## [1.9.20] - 2026-06-11
+
+### Changed
+
+- `cast` now triages the raw request before touching any `.tink` files and picks one of three lanes: Lane 1 starts clearly simple, safe tasks immediately in the same response (no questions, no run state); Lane 2 announces one obvious harness, creates minimal run state, and starts the first step without an approval round-trip; Lane 3 keeps the full procedure with Stitch and explicit approval. Hard-gate signals always force Lane 3.
+- Long runs always show progress: when a plan has 3+ steps (or 2+ goals), every response ends with a progress block - a 10-cell bar with percent, the current step, and the remaining steps - so the user can plan how far to go today. Applied to the cast command (three copies), the Tink skill, and Codex core rules.
+
 ## [1.9.19] - 2026-06-11
 
 ### Added

package/README.ko.md

@@ -4,16 +4,61 @@
 
 # Tink
 
-Claude Code와 Codex를 위한 작은 하네스 레이어입니다.
+**Claude Code · Codex 작업의 맥락이 더는 사라지지 않게.**
 
-Tink는 지금 작업에 맞는 하네스를 고르고, 실행 상태를 보이게 만들고, 실제 사용 중 생긴 실패와 피드백으로 하네스 세트를 개선합니다.
+Tink는 사소하지 않은 모든 에이전트 작업을 눈에 보이는 파일로 남깁니다 — 작업 계약, 실행 상태, 검증 단계, 그리고 승인해야만 저장되는 재사용 하네스. 서버도, 텔레메트리도, 숨은 상태도 없습니다.
 
-**최신 패키지:** v1.9.19 — 로컬 건강 리포트가 탭형 대시보드로 바뀌었습니다. 3D 하네스 지도, 쉬운 말 건강 요약, Claude Code와 Codex 양쪽 복사-붙여넣기 명령이 포함된 다음 행동 제안을 제공합니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
+<sub>Claude Code와 Codex를 위한 작은 하네스 레이어</sub>
+
+**최신 패키지:** v1.9.21 — 로컬 건강 리포트가 탭형 대시보드로 바뀌었습니다. 3D 하네스 지도, 쉬운 말 건강 요약, Claude Code와 Codex 양쪽 복사-붙여넣기 명령이 포함된 다음 행동 제안을 제공합니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
 
 [English](README.md) · **한국어** · [변경 이력](CHANGELOG.md)
 
 ---
 
+## 누구를 위한 도구인가
+
+이런 순간에 쓰세요:
+
+- Claude Code나 Codex가 작업 사이에 맥락을 자꾸 잃을 때
+- 같은 리뷰 / 리팩터링 / 디버깅 절차를 매번 손으로 반복할 때
+- 숨은 채팅 기억 대신 눈에 보이는 실행 상태를 원할 때
+- 재사용 가능한 에이전트 워크플로를 원하지만, 명시적 승인 후에만 저장되길 원할 때
+
+내 얘기 같다면, 버려도 되는 repo에서 먼저 시도해 보세요:
+
+```bash
+npx tink-harness@latest install
+```
+
+## 실제로 남는 것
+
+사소하지 않은 작업마다 열어보고, diff하고, 커밋할 수 있는 평범한 파일이 남습니다:
+
+```text
+.tink/current/                      # 진행 중인 실행 — 언제든 열람 가능
+  contract.json                     #   작업이 끝났을 때 참이어야 하는 것
+  plan.md                           #   눈에 보이는 계획
+  checks.md                         #   "완료" 선언 전 돌릴 검증
+.tink/runs/
+  2026-06-11-1430-auth-refactor.md  # 끝난 실행의 간결한 기록
+.tink/harnesses/
+  refactor-review.md                # 재사용 작업 방식 — 승인해야 저장
+```
+
+## CLAUDE.md·슬래시 명령·스킬만으로는 왜 부족할까?
+
+| 도구 | 제공하는 것 | Tink가 얹는 것 |
+|---|---|---|
+| CLAUDE.md | 프로젝트 전역 지침 | 작업 단위 계약·실행 상태·검증 |
+| 슬래시 명령 | 재사용 프롬프트 | 하네스 선택, 실행 기록, 진행도 추적 |
+| 스킬 | 재사용 능력 | 사용 생애주기: 건강 점수·정리·개선 신호 |
+| MCP | 외부 컨텍스트·도구 | 로컬, 승인 게이트 워크플로 메모리 |
+
+Tink는 이들을 대체하지 않고 함께 동작합니다.
+
+---
+
 ## 빠른 시작
 
 1분이면 Tink를 직접 써볼 수 있습니다.
@@ -66,6 +111,8 @@ node .tink/tools/render-harness-health-report.mjs
 
 ![Tink 대시보드 데모 — 건강 그룹 클릭, 하네스 카드 탐색, 3D 지도 조작](.github/assets/demo.gif)
 
+<sub>당신의 워크플로와 맞는다면, ⭐ 하나가 다른 개발자들이 찾는 데 도움이 됩니다.</sub>
+
 하네스와 그들이 쓰는 규칙·메모리, 그 연결을 보여주는 인터랙티브 3D 지도 — 무리마다 고유한 색을 갖고, 살아있는 관계 위로 신호가 흐릅니다:
 
 ![Tink 하네스 지도 — 하네스·규칙·메모리·단계를 보여주는 인터랙티브 3D 뷰](.github/assets/dashboard-map.ko.png)

package/README.md

@@ -6,30 +6,73 @@
   <strong>Tink</strong>
 </h1>
 
-<p>A small harness layer for Claude Code and Codex</p>
+<p><strong>Stop losing context between Claude Code and Codex runs.</strong></p>
 
 <p>
-  Tink helps Claude Code or Codex choose the right harness, keep run state visible, and improve the harness set as you work.
+  Tink keeps every non-trivial agent task in visible files - a task contract, run state,
+  verification steps, and reusable harnesses that are saved only after your approval.
+  No server, no telemetry, no hidden state.
 </p>
 
-<p>
-  <em>Tink is <strong>knit</strong> in reverse: untying tangled workflows and knitting better ones back together. It also nods to Tinker Bell, the small helper at your side.</em>
-</p>
+<p><sub>A small harness layer for Claude Code and Codex</sub></p>
 
 <p>
-  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.9.19"><img src="https://img.shields.io/github/v/release/dotoricode/tink-harness?label=release&color=2ea44f" alt="GitHub release"></a>
+  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.9.21"><img src="https://img.shields.io/github/v/release/dotoricode/tink-harness?label=release&color=2ea44f" alt="GitHub release"></a>
   <a href="https://www.npmjs.com/package/tink-harness"><img src="https://img.shields.io/npm/v/tink-harness?label=npm&color=cb3837" alt="npm version"></a>
   <a href="https://github.com/dotoricode/tink-harness/actions/workflows/ci.yml"><img src="https://img.shields.io/github/actions/workflow/status/dotoricode/tink-harness/ci.yml?branch=main&label=ci" alt="CI"></a>
   <a href="https://github.com/dotoricode/tink-harness/blob/main/LICENSE"><img src="https://img.shields.io/github/license/dotoricode/tink-harness" alt="License"></a>
   <a href="https://github.com/dotoricode/tink-harness/stargazers"><img src="https://img.shields.io/github/stars/dotoricode/tink-harness?style=social" alt="GitHub stars"></a>
 </p>
 
-<p><strong>Latest package:</strong> v1.9.19 - The local health report is now a tabbed dashboard with a 3D harness map, plain-language health summaries, and next-action suggestions with copy-paste commands for both Claude Code and Codex. See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
+<p><strong>Latest package:</strong> v1.9.21 - The local health report is now a tabbed dashboard with a 3D harness map, plain-language health summaries, and next-action suggestions with copy-paste commands for both Claude Code and Codex. See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
 
 **English** · [한국어](README.ko.md) · [Changelog](CHANGELOG.md)
 
 ---
 
+## Who this is for
+
+Use Tink when:
+
+- Claude Code or Codex keeps losing task context between runs
+- you repeat the same review / refactor / debug workflow by hand
+- you want visible run state instead of hidden chat memory
+- you want reusable agent workflows - saved only after explicit approval
+
+If that sounds like your day, try it on a throwaway repo first:
+
+```bash
+npx tink-harness@latest install
+```
+
+## What you actually get
+
+Every non-trivial task leaves plain files you can open, diff, and commit:
+
+```text
+.tink/current/                      # the active run - always inspectable
+  contract.json                     #   what must be true when the task is done
+  plan.md                           #   the visible plan
+  checks.md                         #   verification to run before claiming "done"
+.tink/runs/
+  2026-06-11-1430-auth-refactor.md  # compact record of each finished run
+.tink/harnesses/
+  refactor-review.md                # reusable ways of working - approval-gated
+```
+
+## Why not just CLAUDE.md / slash commands / skills?
+
+| Tooling | What it gives you | What Tink adds on top |
+|---|---|---|
+| CLAUDE.md | project-wide instructions | per-task contracts, run state, and verification |
+| Slash commands | reusable prompts | harness selection, run records, progress tracking |
+| Skills | reusable capability | usage lifecycle: health scores, cleanup and improvement signals |
+| MCP | external context and tools | local, approval-gated workflow memory |
+
+Tink composes with all of these - it does not replace them.
+
+---
+
 ## Install & quick start
 
 Try Tink in about a minute.
@@ -82,6 +125,8 @@ node .tink/tools/render-harness-health-report.mjs
 
 ![Tink dashboard demo - clicking a health group, browsing harness cards, and inspecting the 3D map](.github/assets/demo.gif)
 
+<sub>If this matches your workflow, a ⭐ helps others find it.</sub>
+
 An interactive 3D map of your harnesses, the rules and memory they use, and how they connect - each cluster gets its own color, and neural pulses travel along live relationships:
 
 ![Tink harness map - an interactive 3D view of harnesses, rules, memory, and stages](.github/assets/dashboard-map.png)
@@ -96,6 +141,8 @@ No server, no telemetry, no hidden cache - it is a static local page that only p
 
 ## Why I made this
 
+*Tink is <strong>knit</strong> in reverse: untying tangled workflows and knitting better ones back together. It also nods to Tinker Bell, the small helper at your side.*
+
 New coding harnesses show up almost every day. Many of them are genuinely useful.
 
 At first, I tried them one by one and kept the ones that fit me. But the more I mixed them, the more my environment got tangled. Resetting everything again and again was tiring, so I ended up falling back to a skill-based workflow that I could understand and control.

package/VERSIONING.md

@@ -1,6 +1,6 @@
 # Versioning
 
-Current version: `1.9.19`
+Current version: `1.9.21`
 
 Tink follows semver from `1.0.0` onward.
 
@@ -86,3 +86,7 @@ npx tink-harness@latest update
 ```
 
 `update` preserves user-modified files. The `--force` flag is reserved for emergency repair and is not the recommended path.
+
+## Release pacing
+
+Batch small fixes on `main` and aim for at most about one release per day. Rapid version churn reads as instability to first-time visitors; a release should bundle a coherent set of changes with a short, plain note.

package/commands/cast.md

@@ -25,6 +25,7 @@ Tink should:
 Do not stop after saying which harness might fit.
 
 A valid `/tink:cast` response must do one of these:
+- complete a clearly simple, safe task directly through the quick-triage fast path (Lane 1 below) - work starts in the same response,
 - create or update `.tink/current/` and start the harnessed work,
 - ask one blocking question that is required to create `.tink/current/`, or
 - cancel because the user chose not to proceed.
@@ -351,31 +352,65 @@ Approved reusable changes should append one JSON line to `.tink/maintenance/ledg
 { "timestamp": "", "op_id": "op-...", "type": "weave|frog|memory|index-update|harness-create|harness-edit", "files": [], "evidence": [], "approval": "", "result": "applied|rejected|deferred", "rollback": "" }
 ```
 
-## Trivial task check
-Before normal harness classification, check whether the task is trivial. Evaluate in this exact order:
+## Quick triage
+Read the raw request text FIRST and pick a lane before reading any `.tink` files. The goal: simple requests produce visible work in the same response, and the heavy machinery loads only when it pays for itself. Time-to-first-action is part of Tink's quality bar.
 
 **Step 1 — Hard-gate override (runs first, no exceptions):**
-If any of the following is true, the task is NOT trivial:
+If any of the following is true, the task goes to Lane 3:
 - Irreversible or hard-to-reverse action (delete, reset, overwrite uncommitted work)
 - External visibility (publish, deploy, tag, push to remote, open a PR, post to a public system)
 - Sensitive data (secrets, credentials, payments, personal data)
 - The task description mentions any of the above concepts
 
-**Step 2 — Trivial criteria (only evaluated if step 1 finds no hard-gate):**
-A task is trivial only when ALL of the following are true:
-1. Single file target explicitly stated
-2. Goal expressed completely in 1–2 sentences
-3. No external effects (confirmed by step 1)
+**Step 2 — Lane decision (only if step 1 finds no hard-gate):**
 
-**If trivial:**
-- Skip Stitch evaluation
-- Create minimal run state: `steps.json` only
-- Replace the approval question with a single inline confirmation: `진행할까요? (y/n)` or `Proceed? (y/n)`
-- Begin work immediately after confirmation
+**Lane 1 — instant start.** Any of these signals, with no contradicting complexity signal:
+- a question, explanation, or lookup with no file edits
+- one obvious localized change (typo, rename, small fix, a single function or file clear from the request)
+- read-only inspection or diagnostics
+- the goal fits in one sentence with nothing worth a clarifying question
 
-**If not trivial:** proceed to normal classification below.
+Lane 1 behavior:
+- Start the work immediately in this response. No `AskUserQuestion`, no `(y/n)` line, no Stitch, no harness loading, no upfront run state.
+- Open with one short marker line: `⚡ 단순 작업 — 바로 진행합니다` / `⚡ Simple task - starting right away`.
+- If the work changed files, append a compact run record on completion; pure Q&A needs no record.
+- If the task turns out bigger mid-work, stop, say so in one line, and re-enter triage as Lane 2 or 3 with what was learned.
+
+**Lane 2 — light harness.** Small but multi-step work: one obvious harness fits, roughly 2-3 files, no architecture or contract decisions, no ambiguity worth an interview.
+
+Lane 2 behavior:
+- Announce the chosen harness in one line, create minimal run state (`steps.json` plus a short `plan.md`), and execute the first safe step in the same response.
+- Do not ask an approval question for soft-gate work; state the working assumption inline (`범위가 다르면 말씀 주세요` / `Tell me if the scope is different`) and keep moving.
+- Stitch runs silently and surfaces only hard gates.
+
+**Lane 3 — full cast.** Any of: 4+ files or multi-phase work, an ambiguous goal, architecture/schema/public contract decisions, release/publish/deploy, migration, or any hard-gate signal from step 1. Run the full Procedure below, including visible Stitch and explicit approval.
+
+When unsure between lanes, prefer the faster lane for reversible local work and the slower lane the moment external visibility or irreversibility appears.
+
+## Progress display
+When a plan is long, the user must always see how far along the run is - that is what makes real-life planning ("this much is left, I'll stop after step 4 today") possible.
+
+Trigger: `steps.json` has 3 or more steps, or `goals.json` exists with 2 or more goals. Lane 1 tasks never show this.
+
+Rule: while such a run is active, END every assistant response with a progress block - after each completed step, partial result, or blocked report. Update `steps.json` (and `goals.json` when present) first so the bar reflects reality, then render:
+
+```text
+📊 진행도
+전체   ▓▓▓▓▓▓░░░░ 60% · 5단계 중 3단계 완료
+현재   [4/5] 렌더러 수정 — 진행 중
+다음   테스트 추가 → 배포 준비
+```
+
+- The bar is 10 cells: `▓` for the completed share, `░` for the rest, computed from completed steps / total steps.
+- `현재` names the in-progress step with its index and status. `다음` lists up to 3 remaining steps joined by `→`; if more remain, end with `… 외 N개`.
+- When `goals.json` exists, show two bars: `전체` from goals (completed goals / total goals) and `현재 목표` from the active goal's steps.
+- English-config runs use `📊 Progress`, `Overall`, `Now`, `Next`, and `M of N steps done`.
+- On run completion, show the final 100% bar once with `✅` instead of `다음`.
+- Never skip the block because a response feels small; if the response is blocked, the block shows where work stopped.
 
 ## Procedure
+This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip most of it.
+
 1. Build a draft `.tink/current/contract.json` from the request. If `.tink/schemas/contract.schema.json` exists, follow that shape.
 2. Read `.tink/rules/index.json` if present. Use it as a small rule graph to choose candidate harnesses, checks, and opt-in guard candidates from contract facts. Do not read every harness.
    - Load `mandatory` nodes first when their `when` facts match the contract.
@@ -430,7 +465,7 @@ A task is trivial only when ALL of the following are true:
    - run a read-only diagnostic,
    - draft the first artifact,
    - or reproduce the issue.
-21. Keep `steps.json`, `notes.md`, `contract.json`, and `session.json` current as work progresses. When present, keep `goals.json` and `delegation.md` aligned with actual status and evidence.
+21. Keep `steps.json`, `notes.md`, `contract.json`, and `session.json` current as work progresses. When present, keep `goals.json` and `delegation.md` aligned with actual status and evidence. When the Progress display trigger applies, end every response with the progress block.
 22. Before final, run `/tink:verify` behavior for required contract checks or state why verification is blocked.
 23. If the task exposed a repeated mistake or reusable improvement, use the Reusable State Save Gate approval payload below. Save only after separate user approval.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tink-harness",
-  "version": "1.9.19",
+  "version": "1.9.21",
   "description": "Self-growing harnesses for Claude Code and Codex.",
   "license": "MIT",
   "type": "module",

package/skills/tink/SKILL.md

@@ -1,76 +1,76 @@
----
-name: tink
-description: Self-growing harnesses for Claude Code. Use to cast, verify, frog, and weave task harnesses.
----
-
-# Tink
-
-Tink helps Claude cast the smallest useful harness, materialize it as run state, and start the work. It keeps the active harness/tool set small because too many tools can hurt performance, and it can suggest small habit-aware calibrations from observed signals.
-
-## Core philosophy
-Tink is one self-growing skill, not a pile of commands and not a skill recommendation list.
-
-It should:
-1. understand the task,
-2. write a small task contract,
-3. choose the smallest effective harness/tool set,
-4. replace heavy harnesses when the current stage or token budget makes them harmful,
-5. build or synthesize a narrow harness when none fits,
-6. apply it only after approval,
-7. create `.tink/current/` run state before deeper work,
-8. execute the first safe step after approval,
-9. verify the promised checks,
-10. avoid repeating the same mistake,
-11. remember reusable lessons only after approval,
-12. keep the harness set small by purging or honing it over time.
-
-## Command surface
-Use only these commands:
-
-- `/tink:setup`: configure language, scope, git tracking, and hook policy.
-- `/tink:cast`: main path. Choose/build/synthesize a harness, run Stitch, create run state, start work, and propose reusable learning.
-- `/tink:verify`: run the checks promised in `.tink/current/contract.json` and record evidence.
-- `/tink:list`: inspect harnesses and lightweight usage signals.
-- `/tink:frog`: propose unused or redundant harness removal. Never delete without approval.
-- `/tink:weave`: improve active harnesses based on real use, failures, and corrections.
-- `/tink:update`: detect install source, diagnose user-modified files, and show the safe update command.
-
-## Operating rules
-1. Create or update `.tink/current/contract.json` for non-trivial runs: task type, risks, success conditions, forbidden actions, verification, and evidence.
-2. Read `.tink/rules/index.json` before loading harness bodies when it exists. Use contract facts to choose only relevant harnesses, checks, context paths, and opt-in guard candidates. Load matching `mandatory` rules first, retrieve only relevant `retrievable` rules by facts or keywords, and record loaded rule ids by phase in `.tink/current/session.json`. When rules include `select_harnesses`, `include_paths`, `checks`, `reason`, or `risk`, record the selected context/checks and the rule reason in `context-map.json` or `contract.json` instead of silently loading extra context.
-3. Read `.tink/harnesses/index.json` before loading harness bodies.
-4. Read small approved memory files when present: `.tink/memory/mistakes.md`, `preferences.md`, `lessons.md`.
-5. Prefer the smallest useful harness set. Use context footprint, not a universal hard cap: tiny harnesses may stack, large harnesses load one at a time after approval, and meta harnesses should reduce or replace context rather than pile on.
-6. If `.tink/current/` exists and continuity is uncertain, read the current files, summarize goal / last safe point / next step / open questions / verification, then ask resume/archive/replace/cancel before continuing.
-7. Run the synthesis probe on the initial harness choice. The probe produces one of three outcomes: strong fit (0-1 yes), generic fit (2-3 yes), or no fit (4-5 yes or no harness matches). Strong fit keeps the harness; generic fit adds a run-only draft; no fit loads `harness-synthesis`.
-8. Treat GJC-style visible-thinking workflows as ordinary Tink harness choices, not new commands: use `requirements-interview` for ambiguous ideas, `plan-consensus` for broad plans or architecture, `goal-checkpoint` for long runs with 2-6 current-run goals, and `delegation-brief` for safe handoff or parallel-work briefs.
-9. If no existing harness fits, use `harness-synthesis` to draft a narrow domain-specific harness instead of forcing a bad fit.
-10. If too many tools, skills, agents, or harnesses are available, use `harness-curation` to choose the smallest effective set before loading more context.
-11. If lightweight signals show recurring context, token, prompt-quality, output-length, reset, or evidence habits, use `harness-curation` to make one advisory recommendation.
-12. When research notes, examples, prior failures, or user corrections are available, extract behavior-shaping rules: triggers, decision rules, checks, stop conditions, recovery, and evidence.
-13. Run Stitch once before committing to `.tink/current/`: evaluate every time, show exactly one proposal only for high-impact quality or safety branches, and use configured language.
-14. Use soft Stitch choices `Approve`, `Add requirements`, `Continue as-is` or localized equivalents; use hard choices `Approve`, `Add requirements`, `Cancel` only.
-15. Hard gates must not offer `Continue as-is` or `이대로 진행`, and Stitch may change method or order but not the user's goal without separate approval.
-16. Treat Reusable State Save Gate as a separate hard approval gate for `.tink/memory/*`, `.tink/harnesses/*`, `.tink/rules/*`, `.tink/config.json`, `.claude/`, and template/plugin files that affect future installs.
-17. Current-run approval never authorizes reusable-state writes; before saving reusable state, show operation, destination files, exact entry or patch summary, reusable reason, sensitive content excluded, and rollback/removal path.
-18. Before saving a reusable rule graph update, run a structural gate: duplicate, breadth, evidence, verification, Claude Code/Codex compatibility, macOS/Windows compatibility, and portable commands. AI may propose a rule; saving it still requires separate approval.
-19. `/tink:frog` may inspect rule quality as well as harness quality. Prefer keep, rewrite, split, merge, or needs-evidence recommendations before any removal proposal.
-20. Ask for approval before applying, saving, purging, honing, or installing enforcement hooks.
-21. After approval, create `.tink/current/plan.md`, `checks.md`, `steps.json`, `notes.md`, `answers.md`, `contract.json`, `session.json`, `context-pack.md`, `context-map.json`, and `excluded-context.md`. If selected, also create `goals.json` for `goal-checkpoint` and `delegation.md` for `delegation-brief`.
-22. Do not stop at recommendation. Execute the first safe step after run state exists.
-23. Run `/tink:verify` behavior before final when `contract.json` lists required checks.
-24. Store reusable memory or rule updates only after separate Reusable State Save Gate approval.
-25. If a check fails, update `.tink/current/notes.md`, state the failure, last safe point, and next single action. Append compact friction to `.tink/maintenance/friction.jsonl` when it exists. Feed repeated failures to `/tink:weave`.
-26. Keep context compact. Do not paste raw logs or full diffs.
-27. Use calm, clear, concise language. Prefer plain everyday words over technical terms if a simpler word works. No jokes.
-
-## Quality bar
-The user should not have to repeat themselves. If the same mistake appears twice, propose `/tink:weave`, a rule graph update, an opt-in guard candidate, or a memory update through `/tink:cast`.
-
-A successful Tink run leaves evidence:
-- current run files exist or were intentionally archived,
-- `contract.json` states what must be true,
-- context artifacts explain what was included and excluded,
-- checks were verified or explicitly blocked,
-- the final answer reports changed files and evidence,
-- reusable learning is proposed only when it will matter again.
+---
+name: tink
+description: Self-growing harnesses for Claude Code. Use to cast, verify, frog, and weave task harnesses.
+---
+
+# Tink
+
+Tink helps Claude cast the smallest useful harness, materialize it as run state, and start the work. It keeps the active harness/tool set small because too many tools can hurt performance, and it can suggest small habit-aware calibrations from observed signals.
+
+## Core philosophy
+Tink is one self-growing skill, not a pile of commands and not a skill recommendation list.
+
+It should:
+1. understand the task,
+2. write a small task contract,
+3. choose the smallest effective harness/tool set,
+4. replace heavy harnesses when the current stage or token budget makes them harmful,
+5. build or synthesize a narrow harness when none fits,
+6. apply it only after approval,
+7. create `.tink/current/` run state before deeper work,
+8. execute the first safe step after approval,
+9. verify the promised checks,
+10. avoid repeating the same mistake,
+11. remember reusable lessons only after approval,
+12. keep the harness set small by purging or honing it over time.
+
+## Command surface
+Use only these commands:
+
+- `/tink:setup`: configure language, scope, git tracking, and hook policy.
+- `/tink:cast`: main path. Quick-triage the request first (simple and safe tasks start immediately without ceremony); otherwise choose/build/synthesize a harness, run Stitch, create run state, start work, and propose reusable learning. Long plans (3+ steps) end every response with a progress bar block.
+- `/tink:verify`: run the checks promised in `.tink/current/contract.json` and record evidence.
+- `/tink:list`: inspect harnesses and lightweight usage signals.
+- `/tink:frog`: propose unused or redundant harness removal. Never delete without approval.
+- `/tink:weave`: improve active harnesses based on real use, failures, and corrections.
+- `/tink:update`: detect install source, diagnose user-modified files, and show the safe update command.
+
+## Operating rules
+1. Create or update `.tink/current/contract.json` for non-trivial runs: task type, risks, success conditions, forbidden actions, verification, and evidence.
+2. Read `.tink/rules/index.json` before loading harness bodies when it exists. Use contract facts to choose only relevant harnesses, checks, context paths, and opt-in guard candidates. Load matching `mandatory` rules first, retrieve only relevant `retrievable` rules by facts or keywords, and record loaded rule ids by phase in `.tink/current/session.json`. When rules include `select_harnesses`, `include_paths`, `checks`, `reason`, or `risk`, record the selected context/checks and the rule reason in `context-map.json` or `contract.json` instead of silently loading extra context.
+3. Read `.tink/harnesses/index.json` before loading harness bodies.
+4. Read small approved memory files when present: `.tink/memory/mistakes.md`, `preferences.md`, `lessons.md`.
+5. Prefer the smallest useful harness set. Use context footprint, not a universal hard cap: tiny harnesses may stack, large harnesses load one at a time after approval, and meta harnesses should reduce or replace context rather than pile on.
+6. If `.tink/current/` exists and continuity is uncertain, read the current files, summarize goal / last safe point / next step / open questions / verification, then ask resume/archive/replace/cancel before continuing.
+7. Run the synthesis probe on the initial harness choice. The probe produces one of three outcomes: strong fit (0-1 yes), generic fit (2-3 yes), or no fit (4-5 yes or no harness matches). Strong fit keeps the harness; generic fit adds a run-only draft; no fit loads `harness-synthesis`.
+8. Treat GJC-style visible-thinking workflows as ordinary Tink harness choices, not new commands: use `requirements-interview` for ambiguous ideas, `plan-consensus` for broad plans or architecture, `goal-checkpoint` for long runs with 2-6 current-run goals, and `delegation-brief` for safe handoff or parallel-work briefs.
+9. If no existing harness fits, use `harness-synthesis` to draft a narrow domain-specific harness instead of forcing a bad fit.
+10. If too many tools, skills, agents, or harnesses are available, use `harness-curation` to choose the smallest effective set before loading more context.
+11. If lightweight signals show recurring context, token, prompt-quality, output-length, reset, or evidence habits, use `harness-curation` to make one advisory recommendation.
+12. When research notes, examples, prior failures, or user corrections are available, extract behavior-shaping rules: triggers, decision rules, checks, stop conditions, recovery, and evidence.
+13. Run Stitch once before committing to `.tink/current/`: evaluate every time, show exactly one proposal only for high-impact quality or safety branches, and use configured language.
+14. Use soft Stitch choices `Approve`, `Add requirements`, `Continue as-is` or localized equivalents; use hard choices `Approve`, `Add requirements`, `Cancel` only.
+15. Hard gates must not offer `Continue as-is` or `이대로 진행`, and Stitch may change method or order but not the user's goal without separate approval.
+16. Treat Reusable State Save Gate as a separate hard approval gate for `.tink/memory/*`, `.tink/harnesses/*`, `.tink/rules/*`, `.tink/config.json`, `.claude/`, and template/plugin files that affect future installs.
+17. Current-run approval never authorizes reusable-state writes; before saving reusable state, show operation, destination files, exact entry or patch summary, reusable reason, sensitive content excluded, and rollback/removal path.
+18. Before saving a reusable rule graph update, run a structural gate: duplicate, breadth, evidence, verification, Claude Code/Codex compatibility, macOS/Windows compatibility, and portable commands. AI may propose a rule; saving it still requires separate approval.
+19. `/tink:frog` may inspect rule quality as well as harness quality. Prefer keep, rewrite, split, merge, or needs-evidence recommendations before any removal proposal.
+20. Ask for approval before applying, saving, purging, honing, or installing enforcement hooks.
+21. After approval, create `.tink/current/plan.md`, `checks.md`, `steps.json`, `notes.md`, `answers.md`, `contract.json`, `session.json`, `context-pack.md`, `context-map.json`, and `excluded-context.md`. If selected, also create `goals.json` for `goal-checkpoint` and `delegation.md` for `delegation-brief`.
+22. Do not stop at recommendation. Execute the first safe step after run state exists.
+23. Run `/tink:verify` behavior before final when `contract.json` lists required checks.
+24. Store reusable memory or rule updates only after separate Reusable State Save Gate approval.
+25. If a check fails, update `.tink/current/notes.md`, state the failure, last safe point, and next single action. Append compact friction to `.tink/maintenance/friction.jsonl` when it exists. Feed repeated failures to `/tink:weave`.
+26. Keep context compact. Do not paste raw logs or full diffs.
+27. Use calm, clear, concise language. Prefer plain everyday words over technical terms if a simpler word works. No jokes.
+
+## Quality bar
+The user should not have to repeat themselves. If the same mistake appears twice, propose `/tink:weave`, a rule graph update, an opt-in guard candidate, or a memory update through `/tink:cast`.
+
+A successful Tink run leaves evidence:
+- current run files exist or were intentionally archived,
+- `contract.json` states what must be true,
+- context artifacts explain what was included and excluded,
+- checks were verified or explicitly blocked,
+- the final answer reports changed files and evidence,
+- reusable learning is proposed only when it will matter again.

package/templates/claude/commands/tink/cast.md

@@ -25,6 +25,7 @@ Tink should:
 Do not stop after saying which harness might fit.
 
 A valid `/tink:cast` response must do one of these:
+- complete a clearly simple, safe task directly through the quick-triage fast path (Lane 1 below) - work starts in the same response,
 - create or update `.tink/current/` and start the harnessed work,
 - ask one blocking question that is required to create `.tink/current/`, or
 - cancel because the user chose not to proceed.
@@ -351,31 +352,65 @@ Approved reusable changes should append one JSON line to `.tink/maintenance/ledg
 { "timestamp": "", "op_id": "op-...", "type": "weave|frog|memory|index-update|harness-create|harness-edit", "files": [], "evidence": [], "approval": "", "result": "applied|rejected|deferred", "rollback": "" }
 ```
 
-## Trivial task check
-Before normal harness classification, check whether the task is trivial. Evaluate in this exact order:
+## Quick triage
+Read the raw request text FIRST and pick a lane before reading any `.tink` files. The goal: simple requests produce visible work in the same response, and the heavy machinery loads only when it pays for itself. Time-to-first-action is part of Tink's quality bar.
 
 **Step 1 — Hard-gate override (runs first, no exceptions):**
-If any of the following is true, the task is NOT trivial:
+If any of the following is true, the task goes to Lane 3:
 - Irreversible or hard-to-reverse action (delete, reset, overwrite uncommitted work)
 - External visibility (publish, deploy, tag, push to remote, open a PR, post to a public system)
 - Sensitive data (secrets, credentials, payments, personal data)
 - The task description mentions any of the above concepts
 
-**Step 2 — Trivial criteria (only evaluated if step 1 finds no hard-gate):**
-A task is trivial only when ALL of the following are true:
-1. Single file target explicitly stated
-2. Goal expressed completely in 1–2 sentences
-3. No external effects (confirmed by step 1)
+**Step 2 — Lane decision (only if step 1 finds no hard-gate):**
 
-**If trivial:**
-- Skip Stitch evaluation
-- Create minimal run state: `steps.json` only
-- Replace the approval question with a single inline confirmation: `진행할까요? (y/n)` or `Proceed? (y/n)`
-- Begin work immediately after confirmation
+**Lane 1 — instant start.** Any of these signals, with no contradicting complexity signal:
+- a question, explanation, or lookup with no file edits
+- one obvious localized change (typo, rename, small fix, a single function or file clear from the request)
+- read-only inspection or diagnostics
+- the goal fits in one sentence with nothing worth a clarifying question
 
-**If not trivial:** proceed to normal classification below.
+Lane 1 behavior:
+- Start the work immediately in this response. No `AskUserQuestion`, no `(y/n)` line, no Stitch, no harness loading, no upfront run state.
+- Open with one short marker line: `⚡ 단순 작업 — 바로 진행합니다` / `⚡ Simple task - starting right away`.
+- If the work changed files, append a compact run record on completion; pure Q&A needs no record.
+- If the task turns out bigger mid-work, stop, say so in one line, and re-enter triage as Lane 2 or 3 with what was learned.
+
+**Lane 2 — light harness.** Small but multi-step work: one obvious harness fits, roughly 2-3 files, no architecture or contract decisions, no ambiguity worth an interview.
+
+Lane 2 behavior:
+- Announce the chosen harness in one line, create minimal run state (`steps.json` plus a short `plan.md`), and execute the first safe step in the same response.
+- Do not ask an approval question for soft-gate work; state the working assumption inline (`범위가 다르면 말씀 주세요` / `Tell me if the scope is different`) and keep moving.
+- Stitch runs silently and surfaces only hard gates.
+
+**Lane 3 — full cast.** Any of: 4+ files or multi-phase work, an ambiguous goal, architecture/schema/public contract decisions, release/publish/deploy, migration, or any hard-gate signal from step 1. Run the full Procedure below, including visible Stitch and explicit approval.
+
+When unsure between lanes, prefer the faster lane for reversible local work and the slower lane the moment external visibility or irreversibility appears.
+
+## Progress display
+When a plan is long, the user must always see how far along the run is - that is what makes real-life planning ("this much is left, I'll stop after step 4 today") possible.
+
+Trigger: `steps.json` has 3 or more steps, or `goals.json` exists with 2 or more goals. Lane 1 tasks never show this.
+
+Rule: while such a run is active, END every assistant response with a progress block - after each completed step, partial result, or blocked report. Update `steps.json` (and `goals.json` when present) first so the bar reflects reality, then render:
+
+```text
+📊 진행도
+전체   ▓▓▓▓▓▓░░░░ 60% · 5단계 중 3단계 완료
+현재   [4/5] 렌더러 수정 — 진행 중
+다음   테스트 추가 → 배포 준비
+```
+
+- The bar is 10 cells: `▓` for the completed share, `░` for the rest, computed from completed steps / total steps.
+- `현재` names the in-progress step with its index and status. `다음` lists up to 3 remaining steps joined by `→`; if more remain, end with `… 외 N개`.
+- When `goals.json` exists, show two bars: `전체` from goals (completed goals / total goals) and `현재 목표` from the active goal's steps.
+- English-config runs use `📊 Progress`, `Overall`, `Now`, `Next`, and `M of N steps done`.
+- On run completion, show the final 100% bar once with `✅` instead of `다음`.
+- Never skip the block because a response feels small; if the response is blocked, the block shows where work stopped.
 
 ## Procedure
+This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip most of it.
+
 1. Build a draft `.tink/current/contract.json` from the request. If `.tink/schemas/contract.schema.json` exists, follow that shape.
 2. Read `.tink/rules/index.json` if present. Use it as a small rule graph to choose candidate harnesses, checks, and opt-in guard candidates from contract facts. Do not read every harness.
    - Load `mandatory` nodes first when their `when` facts match the contract.
@@ -430,7 +465,7 @@ A task is trivial only when ALL of the following are true:
    - run a read-only diagnostic,
    - draft the first artifact,
    - or reproduce the issue.
-21. Keep `steps.json`, `notes.md`, `contract.json`, and `session.json` current as work progresses. When present, keep `goals.json` and `delegation.md` aligned with actual status and evidence.
+21. Keep `steps.json`, `notes.md`, `contract.json`, and `session.json` current as work progresses. When present, keep `goals.json` and `delegation.md` aligned with actual status and evidence. When the Progress display trigger applies, end every response with the progress block.
 22. Before final, run `/tink:verify` behavior for required contract checks or state why verification is blocked.
 23. If the task exposed a repeated mistake or reusable improvement, use the Reusable State Save Gate approval payload below. Save only after separate user approval.
 

package/templates/claude/skills/tink/SKILL.md

@@ -1,76 +1,76 @@
----
-name: tink
-description: Self-growing harnesses for Claude Code. Use to cast, verify, frog, and weave task harnesses.
----
-
-# Tink
-
-Tink helps Claude cast the smallest useful harness, materialize it as run state, and start the work. It keeps the active harness/tool set small because too many tools can hurt performance, and it can suggest small habit-aware calibrations from observed signals.
-
-## Core philosophy
-Tink is one self-growing skill, not a pile of commands and not a skill recommendation list.
-
-It should:
-1. understand the task,
-2. write a small task contract,
-3. choose the smallest effective harness/tool set,
-4. replace heavy harnesses when the current stage or token budget makes them harmful,
-5. build or synthesize a narrow harness when none fits,
-6. apply it only after approval,
-7. create `.tink/current/` run state before deeper work,
-8. execute the first safe step after approval,
-9. verify the promised checks,
-10. avoid repeating the same mistake,
-11. remember reusable lessons only after approval,
-12. keep the harness set small by purging or honing it over time.
-
-## Command surface
-Use only these commands:
-
-- `/tink:setup`: configure language, scope, git tracking, and hook policy.
-- `/tink:cast`: main path. Choose/build/synthesize a harness, run Stitch, create run state, start work, and propose reusable learning.
-- `/tink:verify`: run the checks promised in `.tink/current/contract.json` and record evidence.
-- `/tink:list`: inspect harnesses and lightweight usage signals.
-- `/tink:frog`: propose unused or redundant harness removal. Never delete without approval.
-- `/tink:weave`: improve active harnesses based on real use, failures, and corrections.
-- `/tink:update`: detect install source, diagnose user-modified files, and show the safe update command.
-
-## Operating rules
-1. Create or update `.tink/current/contract.json` for non-trivial runs: task type, risks, success conditions, forbidden actions, verification, and evidence.
-2. Read `.tink/rules/index.json` before loading harness bodies when it exists. Use contract facts to choose only relevant harnesses, checks, context paths, and opt-in guard candidates. Load matching `mandatory` rules first, retrieve only relevant `retrievable` rules by facts or keywords, and record loaded rule ids by phase in `.tink/current/session.json`. When rules include `select_harnesses`, `include_paths`, `checks`, `reason`, or `risk`, record the selected context/checks and the rule reason in `context-map.json` or `contract.json` instead of silently loading extra context.
-3. Read `.tink/harnesses/index.json` before loading harness bodies.
-4. Read small approved memory files when present: `.tink/memory/mistakes.md`, `preferences.md`, `lessons.md`.
-5. Prefer the smallest useful harness set. Use context footprint, not a universal hard cap: tiny harnesses may stack, large harnesses load one at a time after approval, and meta harnesses should reduce or replace context rather than pile on.
-6. If `.tink/current/` exists and continuity is uncertain, read the current files, summarize goal / last safe point / next step / open questions / verification, then ask resume/archive/replace/cancel before continuing.
-7. Run the synthesis probe on the initial harness choice. The probe produces one of three outcomes: strong fit (0-1 yes), generic fit (2-3 yes), or no fit (4-5 yes or no harness matches). Strong fit keeps the harness; generic fit adds a run-only draft; no fit loads `harness-synthesis`.
-8. Treat GJC-style visible-thinking workflows as ordinary Tink harness choices, not new commands: use `requirements-interview` for ambiguous ideas, `plan-consensus` for broad plans or architecture, `goal-checkpoint` for long runs with 2-6 current-run goals, and `delegation-brief` for safe handoff or parallel-work briefs.
-9. If no existing harness fits, use `harness-synthesis` to draft a narrow domain-specific harness instead of forcing a bad fit.
-10. If too many tools, skills, agents, or harnesses are available, use `harness-curation` to choose the smallest effective set before loading more context.
-11. If lightweight signals show recurring context, token, prompt-quality, output-length, reset, or evidence habits, use `harness-curation` to make one advisory recommendation.
-12. When research notes, examples, prior failures, or user corrections are available, extract behavior-shaping rules: triggers, decision rules, checks, stop conditions, recovery, and evidence.
-13. Run Stitch once before committing to `.tink/current/`: evaluate every time, show exactly one proposal only for high-impact quality or safety branches, and use configured language.
-14. Use soft Stitch choices `Approve`, `Add requirements`, `Continue as-is` or localized equivalents; use hard choices `Approve`, `Add requirements`, `Cancel` only.
-15. Hard gates must not offer `Continue as-is` or `이대로 진행`, and Stitch may change method or order but not the user's goal without separate approval.
-16. Treat Reusable State Save Gate as a separate hard approval gate for `.tink/memory/*`, `.tink/harnesses/*`, `.tink/rules/*`, `.tink/config.json`, `.claude/`, and template/plugin files that affect future installs.
-17. Current-run approval never authorizes reusable-state writes; before saving reusable state, show operation, destination files, exact entry or patch summary, reusable reason, sensitive content excluded, and rollback/removal path.
-18. Before saving a reusable rule graph update, run a structural gate: duplicate, breadth, evidence, verification, Claude Code/Codex compatibility, macOS/Windows compatibility, and portable commands. AI may propose a rule; saving it still requires separate approval.
-19. `/tink:frog` may inspect rule quality as well as harness quality. Prefer keep, rewrite, split, merge, or needs-evidence recommendations before any removal proposal.
-20. Ask for approval before applying, saving, purging, honing, or installing enforcement hooks.
-21. After approval, create `.tink/current/plan.md`, `checks.md`, `steps.json`, `notes.md`, `answers.md`, `contract.json`, `session.json`, `context-pack.md`, `context-map.json`, and `excluded-context.md`. If selected, also create `goals.json` for `goal-checkpoint` and `delegation.md` for `delegation-brief`.
-22. Do not stop at recommendation. Execute the first safe step after run state exists.
-23. Run `/tink:verify` behavior before final when `contract.json` lists required checks.
-24. Store reusable memory or rule updates only after separate Reusable State Save Gate approval.
-25. If a check fails, update `.tink/current/notes.md`, state the failure, last safe point, and next single action. Append compact friction to `.tink/maintenance/friction.jsonl` when it exists. Feed repeated failures to `/tink:weave`.
-26. Keep context compact. Do not paste raw logs or full diffs.
-27. Use calm, clear, concise language. Prefer plain everyday words over technical terms if a simpler word works. No jokes.
-
-## Quality bar
-The user should not have to repeat themselves. If the same mistake appears twice, propose `/tink:weave`, a rule graph update, an opt-in guard candidate, or a memory update through `/tink:cast`.
-
-A successful Tink run leaves evidence:
-- current run files exist or were intentionally archived,
-- `contract.json` states what must be true,
-- context artifacts explain what was included and excluded,
-- checks were verified or explicitly blocked,
-- the final answer reports changed files and evidence,
-- reusable learning is proposed only when it will matter again.
+---
+name: tink
+description: Self-growing harnesses for Claude Code. Use to cast, verify, frog, and weave task harnesses.
+---
+
+# Tink
+
+Tink helps Claude cast the smallest useful harness, materialize it as run state, and start the work. It keeps the active harness/tool set small because too many tools can hurt performance, and it can suggest small habit-aware calibrations from observed signals.
+
+## Core philosophy
+Tink is one self-growing skill, not a pile of commands and not a skill recommendation list.
+
+It should:
+1. understand the task,
+2. write a small task contract,
+3. choose the smallest effective harness/tool set,
+4. replace heavy harnesses when the current stage or token budget makes them harmful,
+5. build or synthesize a narrow harness when none fits,
+6. apply it only after approval,
+7. create `.tink/current/` run state before deeper work,
+8. execute the first safe step after approval,
+9. verify the promised checks,
+10. avoid repeating the same mistake,
+11. remember reusable lessons only after approval,
+12. keep the harness set small by purging or honing it over time.
+
+## Command surface
+Use only these commands:
+
+- `/tink:setup`: configure language, scope, git tracking, and hook policy.
+- `/tink:cast`: main path. Quick-triage the request first (simple and safe tasks start immediately without ceremony); otherwise choose/build/synthesize a harness, run Stitch, create run state, start work, and propose reusable learning. Long plans (3+ steps) end every response with a progress bar block.
+- `/tink:verify`: run the checks promised in `.tink/current/contract.json` and record evidence.
+- `/tink:list`: inspect harnesses and lightweight usage signals.
+- `/tink:frog`: propose unused or redundant harness removal. Never delete without approval.
+- `/tink:weave`: improve active harnesses based on real use, failures, and corrections.
+- `/tink:update`: detect install source, diagnose user-modified files, and show the safe update command.
+
+## Operating rules
+1. Create or update `.tink/current/contract.json` for non-trivial runs: task type, risks, success conditions, forbidden actions, verification, and evidence.
+2. Read `.tink/rules/index.json` before loading harness bodies when it exists. Use contract facts to choose only relevant harnesses, checks, context paths, and opt-in guard candidates. Load matching `mandatory` rules first, retrieve only relevant `retrievable` rules by facts or keywords, and record loaded rule ids by phase in `.tink/current/session.json`. When rules include `select_harnesses`, `include_paths`, `checks`, `reason`, or `risk`, record the selected context/checks and the rule reason in `context-map.json` or `contract.json` instead of silently loading extra context.
+3. Read `.tink/harnesses/index.json` before loading harness bodies.
+4. Read small approved memory files when present: `.tink/memory/mistakes.md`, `preferences.md`, `lessons.md`.
+5. Prefer the smallest useful harness set. Use context footprint, not a universal hard cap: tiny harnesses may stack, large harnesses load one at a time after approval, and meta harnesses should reduce or replace context rather than pile on.
+6. If `.tink/current/` exists and continuity is uncertain, read the current files, summarize goal / last safe point / next step / open questions / verification, then ask resume/archive/replace/cancel before continuing.
+7. Run the synthesis probe on the initial harness choice. The probe produces one of three outcomes: strong fit (0-1 yes), generic fit (2-3 yes), or no fit (4-5 yes or no harness matches). Strong fit keeps the harness; generic fit adds a run-only draft; no fit loads `harness-synthesis`.
+8. Treat GJC-style visible-thinking workflows as ordinary Tink harness choices, not new commands: use `requirements-interview` for ambiguous ideas, `plan-consensus` for broad plans or architecture, `goal-checkpoint` for long runs with 2-6 current-run goals, and `delegation-brief` for safe handoff or parallel-work briefs.
+9. If no existing harness fits, use `harness-synthesis` to draft a narrow domain-specific harness instead of forcing a bad fit.
+10. If too many tools, skills, agents, or harnesses are available, use `harness-curation` to choose the smallest effective set before loading more context.
+11. If lightweight signals show recurring context, token, prompt-quality, output-length, reset, or evidence habits, use `harness-curation` to make one advisory recommendation.
+12. When research notes, examples, prior failures, or user corrections are available, extract behavior-shaping rules: triggers, decision rules, checks, stop conditions, recovery, and evidence.
+13. Run Stitch once before committing to `.tink/current/`: evaluate every time, show exactly one proposal only for high-impact quality or safety branches, and use configured language.
+14. Use soft Stitch choices `Approve`, `Add requirements`, `Continue as-is` or localized equivalents; use hard choices `Approve`, `Add requirements`, `Cancel` only.
+15. Hard gates must not offer `Continue as-is` or `이대로 진행`, and Stitch may change method or order but not the user's goal without separate approval.
+16. Treat Reusable State Save Gate as a separate hard approval gate for `.tink/memory/*`, `.tink/harnesses/*`, `.tink/rules/*`, `.tink/config.json`, `.claude/`, and template/plugin files that affect future installs.
+17. Current-run approval never authorizes reusable-state writes; before saving reusable state, show operation, destination files, exact entry or patch summary, reusable reason, sensitive content excluded, and rollback/removal path.
+18. Before saving a reusable rule graph update, run a structural gate: duplicate, breadth, evidence, verification, Claude Code/Codex compatibility, macOS/Windows compatibility, and portable commands. AI may propose a rule; saving it still requires separate approval.
+19. `/tink:frog` may inspect rule quality as well as harness quality. Prefer keep, rewrite, split, merge, or needs-evidence recommendations before any removal proposal.
+20. Ask for approval before applying, saving, purging, honing, or installing enforcement hooks.
+21. After approval, create `.tink/current/plan.md`, `checks.md`, `steps.json`, `notes.md`, `answers.md`, `contract.json`, `session.json`, `context-pack.md`, `context-map.json`, and `excluded-context.md`. If selected, also create `goals.json` for `goal-checkpoint` and `delegation.md` for `delegation-brief`.
+22. Do not stop at recommendation. Execute the first safe step after run state exists.
+23. Run `/tink:verify` behavior before final when `contract.json` lists required checks.
+24. Store reusable memory or rule updates only after separate Reusable State Save Gate approval.
+25. If a check fails, update `.tink/current/notes.md`, state the failure, last safe point, and next single action. Append compact friction to `.tink/maintenance/friction.jsonl` when it exists. Feed repeated failures to `/tink:weave`.
+26. Keep context compact. Do not paste raw logs or full diffs.
+27. Use calm, clear, concise language. Prefer plain everyday words over technical terms if a simpler word works. No jokes.
+
+## Quality bar
+The user should not have to repeat themselves. If the same mistake appears twice, propose `/tink:weave`, a rule graph update, an opt-in guard candidate, or a memory update through `/tink:cast`.
+
+A successful Tink run leaves evidence:
+- current run files exist or were intentionally archived,
+- `contract.json` states what must be true,
+- context artifacts explain what was included and excluded,
+- checks were verified or explicitly blocked,
+- the final answer reports changed files and evidence,
+- reusable learning is proposed only when it will matter again.

package/templates/codex/skills/tink-core/RULES.md

@@ -60,7 +60,7 @@ Default Korean options are `승인`, `조정`, `취소`. If a run-only draft is
 
 Option label quality rules: use short, common, readable labels only. Good Korean labels include `승인`, `조정`, `취소`, `요구사항 입력`, `기본 하네스만 사용`, `새 하네스 초안 만들기`, `구조 점검`, `내용 점검`, and `전체 점검`. Do not invent compressed Korean labels, transliterated fragments, or unclear summaries such as `콘데의달 지질`. If the idea is too specific for a clean 1-5 word label, put the detail in `description` and use a generic label such as `내용 점검` or `전체 점검`. Before calling `request_user_input`, reread each Korean label; if it looks misspelled, unnatural, or semantically unclear, replace it with a plain fallback label.
 
-When `request_user_input` is unavailable, write the same approval request as a normal assistant message and wait for the user's answer. Do not create run state, load harness bodies, edit files, run commands, or continue the task before the answer. A user's `$tink:cast` invocation means "prepare and ask for approval", not "start immediately".
+When `request_user_input` is unavailable, write the same approval request as a normal assistant message and wait for the user's answer. Do not create run state, load harness bodies, edit files, run commands, or continue the task before the answer. A user's `$tink:cast` invocation means "prepare and ask for approval", not "start immediately". Exception - quick triage Lane 1: when the request is clearly simple and safe (a question, a read-only check, or one obvious localized edit with no hard-gate signals), start immediately with a one-line marker instead of asking; full preparation applies to non-trivial tasks. When an active plan has 3 or more steps, end every response with the Tink progress block (10-cell bar, current step, remaining steps).
 
 Use this compact approval request shape. Keep it short; do not expose internal terms such as Stitch, Probe, synthesis probe, generic fit, or hard gate in user-facing text. Translate them into plain wording such as `확인할 점`, `맞춤 절차 판단`, `기본 하네스로 충분`, or `기본 하네스만으로는 부족함`.