@zyaiting/keelson 0.4.0 → 0.5.0

package/registry/runtime-hashes.json

@@ -0,0 +1,41 @@
+{
+  "source": "Generated from published @zyaiting/keelson 0.4.0 and 0.4.1 (English/Chinese, lean/guided, guide on/off). Hashes include paths and normalized file bytes; only exact generated content may be replaced.",
+  "versions": {
+    "0.4.0": {
+      "shims": [
+        "cebe268136c46d9b190f31d5521770a8fe81dd0aa53dfccfd1dfbf39dafa26e7",
+        "5cef12b9c5aec6410040c1f5033fc60cc76fd9837bc73abfef147e36096b981a"
+      ],
+      "skills": [
+        "490534b10c8f594cd8ca40dc4817f56f1d9e84bca1cff973c45d857f367269d1",
+        "a8cdf54fc5e68a03d74c4d8a8a1f714997c1340318b3c664fab1d3473c865dd7",
+        "7d56a7c7197f2363bbbace9149465ade63c8308eb2dfed15d76fbcf892dd5a58",
+        "4e2ca439e8e11683d8913ab72f05537cbbde4afa6d61ad0e0848a59f9cf7bae7"
+      ],
+      "workflows": [
+        "455f5bb4060b984cd1839aed452fb82cbc09101d81d28630bdaa9547aca6d050",
+        "9099f590ae1b8192de759cc9b9d2187d37961b841e80bedd6175c23eac752af1",
+        "73f8562e785d8259d853257d02ac1e0688a5882d8c8e701b42a4e289b317be31",
+        "ca267bd38b5353684e3deb7d1774bb75d25005381541ba67597cd9fb530ad538"
+      ]
+    },
+    "0.4.1": {
+      "shims": [
+        "4afd7eb69ca1ab1913c73737e56890ca6e363881b1cedc76e95f97b0e5d528e3",
+        "a2d88237dbaa7a9aa0fc5340e73690737a5c58f13013dff93604d2414f3fef38"
+      ],
+      "skills": [
+        "bc676907188784049abf44f271643ea726b82ad34eb3af994bbf1b382f8e3d5f",
+        "9f2a472f526646a3f1e180bb1cf9f1aaec74a0da5f4e937c9ca1ed5d88f11602",
+        "adb328b4553e9d3d5e1826f91ffd10528b7f7b6b04565e0c1801606d04509686",
+        "d7ac8d6b0e8c849cca28f574fc6fb355aa863f90c93fbf2165a43a1d14cabe34"
+      ],
+      "workflows": [
+        "455f5bb4060b984cd1839aed452fb82cbc09101d81d28630bdaa9547aca6d050",
+        "9099f590ae1b8192de759cc9b9d2187d37961b841e80bedd6175c23eac752af1",
+        "73f8562e785d8259d853257d02ac1e0688a5882d8c8e701b42a4e289b317be31",
+        "ca267bd38b5353684e3deb7d1774bb75d25005381541ba67597cd9fb530ad538"
+      ]
+    }
+  }
+}

package/skills/keelson/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: keelson
-description: Engineering control plane for coding work in repositories with a .keelson/ directory. Use for exploring an idea, changing code, fixing/debugging, frontend design and UX review, continuing prior work, or improving recurring engineering failures. Keeps conversation sessions separate from durable work items so users can keep asking questions without having to announce when a task starts or ends.
+description: Engineering workflow for repositories with a .keelson/ directory. Apply automatically to ordinary requests to explore an idea, build or change a feature, fix a bug, create or improve an interface, continue prior work, or improve recurring engineering failures. Routes discovery, design, implementation, verification and project memory without requiring skill names or workflow commands.
 ---
 
 # Keelson
@@ -21,6 +21,8 @@ Completion is **not** an intent and never depends on the user saying “done”.
 
 - For interface design, review, interaction or responsive work, load `frontend.md`; use `keelson design` for focused action briefs. Keep browser observations distinct from code checks.
 
+Route from the requested outcome and repository evidence, not special vocabulary. Users describe work; the agent loads guidance and runs workflow commands. Automatically include `model.md` for conflicting terms or shared boundaries, `engineer.md` for non-obvious design choices, and `frontend.md` when the affected path includes a user interface, even without an explicit design request. During implementation use `build.md`; complete with `verify.md` → `land.md` → `reconcile.md` within existing authorization. `guide: true` adds teaching, not activation; both profiles use this workflow by default.
+
 ## Operating rules
 
 - A conversation/session is only a focus pointer. Ending a window, going idle, or continuing to ask questions MUST NOT mark a change complete.
@@ -28,9 +30,10 @@ Completion is **not** an intent and never depends on the user saying “done”.
 - On Resume, use `keelson focus --auto`; branch match or a sole active change may be suggested. Never silently bind an ambiguous session.
 - If `NOW.md` says “First contact”, infer and confirm `INTENT.md`; do not inventory the whole repository into specs/rules.
 - Non-trivial modifying work starts from current context; shared modules get `keelson impact <files>`.
-- Ask only at the decision frontier. Run the triggered blindspot pass, then use `interview.md`: up to three independent ready owner-owned decisions per round, skipping settled answers, concrete scenario/options, recommended default, and `not sure` as a valid route. Never ask what repo evidence, an experiment, or agent engineering judgment can settle.
+- Automatically assess discovery needs on new goals, material follow-ups and changed premises using `interview.md`; unresolved goals, connected product choices or high-impact commitments trigger deeper discovery without special wording. Clear tasks proceed directly. Ask one ready owner decision for a simple gap, or the whole ready frontier for connected uncertainty, with concrete options, a recommendation and reason; reuse settled answers and investigate facts yourself.
 - Route non-obvious mechanisms/architecture through `engineer.md`: reduce to facts, outcome, constraints, and invariants; state a falsifiable hypothesis; use the cheapest experiment/ablation that can discriminate; complexity must earn its keep with evidence.
-- Size only the work: trivial = direct edit; quick = lightweight change; spec = acceptance + behavior delta + plan within existing user authorization; clarify only unresolved owner choices.
+- Size only the work: trivial = minimal quick change; quick = lightweight change; spec = acceptance + behavior delta + plan within existing user authorization; clarify only unresolved owner choices.
+- Before product edits, automatically run `keelson start` for the focused change, then load `keelson context --phase implement`; after new material decisions, restart only once they are settled. Users need not run these commands.
 - Artifacts are information containers, not ceremony. Do not create empty roadmap/glossary/rule/task/ledger/handoff/spec files.
 - `tasks.md` is an execution plan, not completion authority. Unchecked plan items never override satisfied acceptance + fresh evidence; reconcile or remove stale tasks when the implementation path changes.
 - Knowledge maintenance is internal. During RECONCILE, automatically rewrite/split/dedupe pressured durable docs and let `land` auto-shard large specs; never ask the owner to maintain Keelson unless a product-semantic decision is required.

package/skills/keelson/references/build.md

@@ -2,6 +2,16 @@
 
 Execute `tasks.md` slice by slice. You choose how; these notes cover the parts that are easy to get wrong.
 
+## Enter implementation with the current plan
+<!-- keelson: id=build.start | without: an agent edits product files before resolving the plan or reads an unrelated change's rules | sunset: never -->
+
+For modifying work, create the smallest useful change, record concrete acceptance, and run `keelson start` automatically within the owner's existing authorization. Trivial work uses a minimal quick change without a separate plan or interview. Start rejects open decisions, assumptions, missing acceptance and active prerequisites; it records the current plan and declares phase context in `context.json`. Reopened decisions or changed plan/delta require resolving the affected branches and starting again. Do not ask the owner to operate the workflow.
+
+Read `keelson context --phase implement` before editing. The pack contains current and delta specs, relevant rules, decisions and checks; `context.json` can declare additional project-relative files per `implement`/`check` phase. Add newly affected paths to context routing. For spec work, retain the owner's original request and material follow-ups in `request.md` so the reviewer sees the actual requested outcome. Do not replace it with your implementation summary.
+
+Claude Code, Codex and CodeBuddy have native gates for supported file-editing tools and hooks for session context. Codex requires trusted hooks. Shell/MCP writers and other hosts must follow this same protocol through the agent. This is not a sandbox or proof of user authorization.
+
+
 ## Rulings, not stalls
 <!-- keelson: id=build.rulings | without: agent parks the session on questions the plan already answers; or decides silently and the reasoning is lost | sunset: never -->
 
@@ -21,6 +31,8 @@ When tasks are mostly independent and the host offers subagents, dispatch a fres
 
 More agents are not a linear throughput multiplier. When tasks share mutable state or the same contract, or need constant synchronization, coordination and merge cost can exceed the parallelism benefit; keep them sequential. Parallelize only when boundaries are clear, outputs are independently verifiable, and the merge contract is explicit. Do not try to rescue tightly coupled work by simply adding agents.
 
+For a tracked task, include a standalone `KEELSON_CHANGE=<change-name>` line and the phase in each child task. In Codex the child automatically runs `keelson focus <change-name>` and `keelson context --phase implement` (or `check` for review) before working. Each child has its own thread identity; never infer its task from the root session. Preserve assigned read-only scope. When resuming a child with an existing focus, retain it unless the new assignment explicitly changes it. Untracked read-only investigation needs no change or marker.
+
 After each task, a reviewer subagent (tier ≥ `standard`, never below the implementer) checks the diff against the spec and the rules. Record both in the ledger:
 
 ```markdown

package/skills/keelson/references/discover.md

@@ -1,6 +1,8 @@
 # Discovering what is wanted
 
-The user often cannot describe the whole requirement in the first sentence, and they should not need to know which engineering choice matters. Discovery finds the problem behind the request before anyone picks a database. Use `interview.md` for owner-owned uncertainty; load `design-lenses.md` only when the work triggers a real cross-domain risk.
+The user often cannot describe the whole requirement in the first sentence, and they should not need to know which engineering choice matters. Discovery finds the problem behind the request before anyone picks a database. Apply `interview.md` automatically to determine depth from the goal, unresolved choices and consequences, including when the user simply asks to build something. Load `design-lenses.md` only when the work triggers a real cross-domain risk.
+
+During read-only requests, reuse existing artifacts but keep all new write-backs, decisions and notes in the conversation, even when a change is active. The persistence steps below apply only within existing write authorization.
 
 ## Scenario before technology
 <!-- keelson: id=discover.scenario-first | without: the first question is a technology choice the owner cannot answer, and the product is shaped by whatever they guessed | sunset: never -->
@@ -42,11 +44,11 @@ Before asking, classify the gap by who can resolve it:
 |---|---|
 | Already established in repository/context | Use it; cite the source in the write-back |
 | Reality-owned (code behaviour, API contract, measurement, dependency capability) | Investigate or run a small experiment |
-| User-owned and load-bearing (goal, scope, acceptance, risk tolerance, public commitment) | Ask one question |
+| User-owned and load-bearing (goal, scope, acceptance, risk tolerance, public commitment) | Ask one question for a simple gap or the whole ready frontier for connected uncertainty |
 | Non-load-bearing or cheap to reverse | Decide under authorization, or leave unresolved for a later slice |
 | Evidence exhausted | Mark it UNKNOWN; do not convert uncertainty into a user belief |
 
-Choose the gap with the highest practical value of information: the answer most likely to change the next slice, weighted by the cost of being wrong. Before asking, apply the `interview.md` question protocol. After the answer, update the write-back and reassess the frontier. "Exactly one question" is a bottleneck for **blocking uncertainty**, not a ritual: when no user-owned load-bearing gap exists, ask nothing and proceed.
+Use `interview.md` to choose a single question for a simple gap or the whole ready frontier for connected uncertainty. Prioritize by practical value of information: the answer most likely to change the next slice, weighted by the cost of being wrong. Before asking, apply the `interview.md` question protocol. After the answer, update the write-back and reassess the frontier. Question count follows decision complexity: when no user-owned load-bearing gap exists, ask nothing and proceed.
 
 ## Scope guard
 <!-- keelson: id=discover.scope-guard | without: a first request asks for five independent domains at once, and integration risk, debugging cost, and requirement churn compound | sunset: never -->

package/skills/keelson/references/frontend.md

@@ -1,6 +1,6 @@
 # Frontend design
 
-Use for creating, improving, diagnosing or verifying an interface people see and operate. Keep the existing change lifecycle; add design judgment and observable interface acceptance.
+Apply automatically when the requested work or affected code creates, changes, diagnoses or verifies an interface people see and operate. Users need not request a design action or name this reference. Keep the existing change lifecycle; add design judgment and observable interface acceptance, scoped to the affected user journey.
 
 ## Route by the problem
 <!-- keelson: id=frontend.routing | without: Small UI fixes turn into broad redesigns and every request loads all guidance | sunset: never -->

package/skills/keelson/references/interview.md

@@ -1,6 +1,19 @@
 # Adaptive decision interviews
 
-Keelson users do not need software-architecture vocabulary. Interviewing is hidden control logic: discover only decisions the owner truly owns, make each one easy to answer, then return to building. Ordinary work is **not** a questionnaire; explicit “stress-test this” requests are deeper stress tests of the same decision tree.
+Keelson users describe their goals in ordinary language. The agent automatically chooses the depth of discovery from unresolved decisions and their consequences; users need no skill name, special phrase, or interview-mode switch. Investigate first, make owner decisions easy to answer, then return to the requested work.
+
+## Trigger discovery from the work
+<!-- keelson: id=interview.activation | without: users must know to request a deep interview, so vague goals and consequential assumptions reach implementation unchecked | sunset: never -->
+
+For a new goal, a material follow-up, or new evidence that changes a settled premise, inspect relevant repository facts and prior answers, then choose the depth:
+
+- **Clear and bounded:** the outcome, acceptance and relevant constraints are established. Proceed without an interview; a routine edit or factual explanation needs no discovery ceremony.
+- **One consequential gap:** ask the highest-value ready owner decision, with a recommendation and reason; reassess after the answer.
+- **Connected uncertainty:** the goal or success criteria are unclear, product choices depend on one another, requirements conflict, or unresolved permission/data/compatibility/migration commitments would materially change the design. Automatically work through the relevant decision branches before committing to a dependent design. A request such as “add team sharing” is enough when these choices remain open; do not ask whether to enable a deeper interview.
+
+Trigger on missing decisions and consequences, not keywords or task size alone. Existing contracts can settle even a high-risk question. Inspect domain risks using `design-lenses.md`, investigate facts yourself, and ask only what requires the owner's judgment. Apply the same rule when later answers reveal new branches. Preserve settled choices unless new evidence justifies reopening them.
+
+Discovery does not expand authorization: an exploratory conversation stays read-only, while an authorized change resumes implementation as soon as its relevant decisions are resolved. An explicit request for broader review can widen the review boundary, but is never required to activate discovery.
 
 ## Question protocol: earn the interruption
 <!-- keelson: id=interview.protocol | without: the agent asks unnecessary questions, hands implementation choices to the owner, or interrupts without knowing what the answer changes | sunset: never -->
@@ -23,10 +36,12 @@ Do one compact risk-triggered pass before interviewing. Load only the rows trigg
 
 A blindspot does **not** automatically become a question. Route it to an existing guarantee, an engineering default, an experiment, an acceptance/evidence case, or an owner decision. Ask only the last category.
 
-## One decision, recognition over recall
+## Match the round to the uncertainty
 <!-- keelson: id=interview.one-at-a-time | without: a wall of questions overloads the owner, while open-ended jargon questions force beginners to invent architecture preferences | sunset: never -->
 
-Read `keelson ask list --json` before asking. Never repeat a settled answer without new evidence and `ask reopen <id> --reason`. Ask at most three independent, ready user-owned decisions in one round; dependent choices wait for their prerequisite. Use `ask add`, `settle`, `assume`, and `frontier` to persist ownership, answer and basis. Irreversible decisions require settlement, not assumptions. Prefer a concrete scenario and recognition over recall:
+Read existing decisions before asking. When the current request authorizes project writes, use `ask add`, `settle`, `assume`, and `frontier` to persist ownership, dependencies, answers and basis on its active change. Never repeat a settled answer without new evidence and `ask reopen <id> --reason`. During read-only exploration, even if an active change exists, keep new answers in the conversation; transfer durable results only when implementation or persistence is authorized.
+
+For a simple gap, ask one highest-value ready owner decision (`ask frontier --limit 1`). For connected uncertainty, ask the **whole ready owner frontier in one round** (`ask frontier --all`), grouped by topic with a recommendation and reason for each question. If the host caps questions, bundle them in one supported text question or deliver same-round batches; do not move to dependent questions until the round's prerequisites are settled. A recommendation is not an answer: wait for the owner's response unless existing authorization explicitly delegates the choice. Repository/reality-owned facts are investigated, never put to the owner. Irreversible decisions require settlement, not assumptions. Prefer a concrete scenario and recognition over recall:
 
 - describe the situation in the owner’s language;
 - give 2–4 **materially different outcomes**; when useful, attach one concise **Engineering:** consequence to each option instead of making the owner infer the implementation;
@@ -79,6 +94,8 @@ Technology is explanatory context after the product consequence is clear. It is
 
 Resolve decisions in dependency order:
 
+Maintain a compact decision tree: each unresolved choice names its prerequisites and the outcome it changes. Each answer settles a branch or exposes new ones. Recompute the ready frontier after every round; ask the whole ready owner frontier in a complex round with recommended answers and reasons, wait for those answers, then work the newly unblocked branches. An investigation still in progress is an unresolved prerequisite, not permission to guess. Keep the full tree internal; show only the current questions and a concise result.
+
 **problem / actor → scope and non-goals → observable behavior → data/permission invariants → external contracts → failure semantics → expensive architecture → implementation details**
 
 Ask earlier questions only when they change later branches. Detect grab-bag requests and rabbit holes: separate independent domains, identify which one unlocks the next useful slice, and park speculative future needs instead of designing for them now.
@@ -109,12 +126,14 @@ Never turn “I don’t know which technology” into a technology poll. Transla
 ## Read back, persist the result, and stop
 <!-- keelson: id=interview.stop | without: answers stay trapped in chat, the same decision is asked again, or ordinary work becomes an endless interview | sunset: never -->
 
-After an answer, confirm **decision + consequence** in one sentence, persist only the durable result in the owning artifact, and recompute the decision frontier. Do not create a transcript.
+After an answer, confirm **decision + consequence** in one sentence, when the current request authorizes writes, persist only the durable result in the owning artifact, and recompute the decision frontier. Do not create a transcript.
 
-For ordinary work, stop asking as soon as the next vertical slice has:
+Stop asking when the current review boundary or next implementation slice has:
 - a clear observable outcome;
 - explicit boundaries/non-goals where needed;
-- no unresolved owner-owned decision that blocks it;
+- no unresolved owner-owned decision or silent assumption that could change its outcome or design commitment;
 - an acceptance/evidence path.
 
-Questions about later slices remain open without blocking current work. If the owner explicitly asks for a deep stress test, continue through every **material** branch inside the requested boundary, but still reject speculative future branches and low-value implementation trivia.
+In deeper discovery, resolve every material branch that could change the current outcome or design commitment, including downstream choices revealed by earlier answers. Do not call a slice safe while its shared architecture relies on an unresolved high-impact decision. Independent work can continue: move genuinely later open choices into ROADMAP or a separate change, preserving their dependencies and unresolved state. `start` gates the whole current change; do not leave a blocking decision there while declaring the change ready. Reject speculative future branches and low-value implementation trivia. Return to the requested work without requiring an “end interview” phrase or repeating an approval already given.
+
+For a tracked interview, `keelson ask frontier --all --json` must report `complete: true` before claiming its registered tree is settled. An empty question list alone can mean pending investigations, blocked dependencies or assumptions. Also check the current outcome, boundaries and domain risks for material branches not yet registered: graph completion cannot prove discovery completeness. Keep new findings in the conversation for read-only requests.

package/skills/keelson/references/land.md

@@ -2,6 +2,8 @@
 
 A change is implemented when its slices are verified, integrated when it is on the target branch with its specs folded, and released when a tagged version ships it. These are three states, and Keelson reports them separately.
 
+Before landing, inspect settled `decisions.json` answers. Promote only durable product contracts into delta requirements or capability-prefixed `change.md → Decisions`; preserve reasons that affect future work. Investigation trivia stays in the change. `land` folds those contracts, and the next phase context loads the updated truth.
+
 ## `keelson land <name>`
 <!-- keelson: id=land.command | without: delta specs never merge, specs stop describing the current system, and unverified or unapproved work is declared integrated | sunset: never -->
 

package/skills/keelson/references/shape.md

@@ -20,7 +20,7 @@ When quick work is materially ambiguous, and for every spec change, do a compact
 3. **Missing** — information that cannot be learned from the repository; rank it by how much the answer could change the outcome, boundary, acceptance, or an expensive-to-reverse choice.
 4. **Failure if wrong** — name one likely failure pattern for this class of work: wrong problem, scope creep, compatibility break, unmeasured optimisation, unsafe migration, or another concrete risk.
 
-Keep the audit internal except for the facts/assumptions needed in the short write-back. If no missing item is load-bearing, proceed under project authorizations/defaults. If one is load-bearing and user-owned, route it through `interview.md`, ask the single highest-value question, update the write-back, then reassess. Do not expose an audit checklist to the owner.
+Keep the audit internal except for the facts/assumptions needed in the short write-back. If no missing item is load-bearing, proceed under project authorizations/defaults. If one is load-bearing and user-owned, route it through `interview.md`, ask one question for a simple gap or the whole ready frontier for connected uncertainty, update the write-back, then reassess. Do not expose an audit checklist to the owner.
 
 ## Write back your understanding
 <!-- keelson: id=shape.write-back | without: agent builds its own interpretation; mismatches surface after code exists | sunset: never -->
@@ -44,14 +44,14 @@ When you must proceed without an answer, write the working assumption as `- (ass
 ## Stop asking when the next slice is deliverable
 <!-- keelson: id=shape.stop-rule | without: agent either exhausts the owner with questions about later slices, or starts building on a slice whose acceptance is undefined | sunset: never -->
 
-The bar is not "no unknowns in the project". It is: the next slice has a clear outcome, a boundary, and an acceptance check. Unresolved questions about later slices go under `## Open questions` with what they block, and the work they do not block continues. Example: download permissions undecided, link management list can be built, public download must not be defaulted on.
+The bar is not "no unknowns in the project". It is: the current scope has a clear outcome, boundaries and an acceptance check, with the material decision branches resolved as described in `interview.md`. A small first slice is not a shortcut around unresolved shared architecture or product commitments. Genuinely independent work continues while later questions remain under `## Open questions` with what they block. Example: download permissions undecided, link management list can be built only if it does not commit to those semantics; public download must not be defaulted on.
 
 ## Interview (only when the decision frontier requires it)
 <!-- keelson: id=shape.interview | without: architectural ambiguity is silently guessed, or every spec change turns into a mandatory questionnaire | sunset: never -->
 
 Use `interview.md` for the interaction protocol. A spec-sized change does **not** automatically require user questions: first resolve repository-owned facts and reversible engineering choices yourself. If the work touches data, security, concurrency, compatibility, error handling/resource lifetime, operations, performance, UI/accessibility, or AI behavior, inspect only the triggered rows in `design-lenses.md` and turn them into decisions or evidence obligations. For failure-path changes, follow its pre-implementation regression step.
 
-Run the assumption check internally. Do not open with an abstract "what are we assuming?" question unless the owner truly owns that uncertainty; translate it into the concrete user-visible or risk consequence instead. Explicit "stress-test this" requests continue through the relevant decision tree; ordinary work stops as soon as the next safe slice is ready.
+Run the assumption check internally. Translate owner-owned uncertainty into concrete user-visible or risk consequences. Apply the automatic depth rules in `interview.md` without waiting for a special request: connected uncertainties or high-impact unresolved commitments require deeper discovery before dependent design choices. Clear work proceeds directly; resume authorized implementation once the relevant branches are settled.
 
 ## Authorization
 <!-- keelson: id=shape.authorization | without: either every step waits for approval or the agent decides product questions and production actions by itself | sunset: never -->

package/skills/keelson/references/verify.md

@@ -46,7 +46,7 @@ Editing a test is normal when the requirement changed. Deleting an assertion, sk
 ## Fresh-reader review (spec tier)
 <!-- keelson: id=verify.fresh-reader | without: the author reviews their own work; the same blind spot passes twice | sunset: when 50 consecutive fresh-reader reviews found nothing the per-task reviews missed -->
 
-Dispatch a reviewer that has not seen the conversation (tier ≥ `deep` for spec changes), with the original request, `change.md`, the delta specs, and the diff. Ask for: acceptance items without real coverage, requirement gaps, rule violations, risky assumptions, anything a maintainer would object to. Address or ledger each finding. Agreement from a second agent is a signal, not a proof; the acceptance list is what is checked.
+Dispatch a reviewer that has not seen the conversation (tier ≥ `deep` for spec changes), with the original request, `change.md`, the delta specs, and the diff. Use `keelson context --phase check` as the evidence packet; include `request.md` and include standalone `KEELSON_CHANGE=<change-name>` and `KEELSON_PHASE=check` lines in the reviewer task. Codex reviewers automatically bind the assigned change with `keelson focus` and load `keelson context --phase check`; other supported hooks inject the check dependencies. Give the reviewer read-only scope and no inherited conversation; the implementer fixes findings, then the reviewer checks the affected result. If the host cannot provide a fresh reviewer, report that gap rather than inventing a review. Ask for: acceptance items without real coverage, requirement gaps, rule violations, risky assumptions, anything a maintainer would object to. Address or ledger each finding. Agreement from a second agent is a signal, not a proof; the acceptance list is what is checked.
 
 ## Completion report
 

package/skills/keelson/templates/resident-block.md

@@ -1,7 +1,7 @@
 <!-- keelson:start -->
 ## Keelson
 
-This project is managed by Keelson. Before non-trivial work, run `keelson guide` and follow it.
+This project is managed by Keelson. For project work, run `keelson guide` and follow it.
 For a routed topic, run `keelson guide <reference>`. Use `keelson init --vendor` only when the project needs a checked-in guidance copy.
 Files outside `.keelson/` are discovery adapters only; do not duplicate Keelson guidance here.
 <!-- keelson:end -->

package/skills/keelson/templates/workflow.md

@@ -2,11 +2,11 @@
 
 Project truth and durable work live under `.keelson/`. Machine-local focus, trust and keys live in Git’s private runtime directory; durable signed records and logs stay with each change. A **session is not a task**: it only points at the work item this conversation is currently about.
 
-Every non-trivial modifying request follows **ORIENT → BOUND → BUILD → SENSE → RECONCILE**.
+Every modifying request follows **ORIENT → BOUND → BUILD → SENSE → RECONCILE**.
 
 - **ORIENT** — inspect the worktree and current session focus. Same-goal follow-ups keep the focused change. For “continue”, run `keelson focus --auto`; never bind an ambiguous session silently.
-- **BOUND** — read before asking. Resolve repository facts and reversible engineering choices yourself; ask up to three independent, ready owner decisions at the decision frontier, only when they materially affect the result. Trivial: edit directly; quick: smallest useful change; spec: acceptance + behavior delta + plan. Inspect only risk lenses actually triggered by the work.
-- **BUILD** — one vertical slice at a time. A new independent requested outcome gets a new change; continuing questions about the same outcome do not.
+- **BOUND** — read before asking. Use `interview.md` to automatically deepen discovery when the goal is unclear, product choices are connected or high-impact commitments remain unresolved; no special prompt is needed. Resolve repository facts and reversible engineering choices yourself; ask one ready owner decision for a simple gap or the whole ready frontier for connected uncertainty with recommendations and reasons. Clear tasks proceed directly. Trivial: minimal quick change; quick: smallest useful change; spec: acceptance + behavior delta + plan. Inspect only risk lenses actually triggered by the work.
+- **BUILD** — automatically pass `keelson start`, load `keelson context --phase implement`, then implement one vertical slice at a time. A new independent requested outcome gets a new change; continuing questions about the same outcome do not.
 - **SENSE** — cheap checks early; completion requires fresh `keelson check --record` evidence on the current tree. Task checkboxes describe the current plan; they never decide completion.
 - **RECONCILE** — evaluate lifecycle after each modifying pass from acceptance, blockers, rollout/compatibility, and fresh verification. Before landing, silently perform any internal knowledge maintenance surfaced by context: rewrite singleton current-state docs, split/dedupe rules, and let `land` auto-shard large specs. If gates are satisfied, status becomes `ready` and the agent lands automatically; do not wait for the user to say “done” or expose maintenance ceremony.
 - Ending a session, going idle, compaction, or closing the window changes only session runtime state. It never completes, cancels, or lands durable work.

package/skills/zh/keelson/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: keelson
-description: 面向含 .keelson/ 目录项目的工程控制层。用于探索想法、修改代码、修复/调试、前端设计与 UX 评审、继续之前的工作，或改进反复出现的工程失败。把“对话会话”和“长期 work item”分开，因此用户可以一直追问，而不需要主动宣布任务何时开始或结束。
+description: 面向含 .keelson/ 目录项目的工程工作流。普通的想法讨论、功能开发或修改、问题修复、界面创建或优化、继续工作、改进反复出现的工程失败请求均自动适用。按需衔接需求探索、设计、实现、验证与项目记忆，无需用户指定 Skill 名称或工作流命令。
 ---
 
 # Keelson
@@ -21,6 +21,8 @@ description: 面向含 .keelson/ 目录项目的工程控制层。用于探索
 
 - 涉及界面设计、评审、交互或响应式时，加载 `frontend.md`；用 `keelson design` 读取具体动作指导。区分浏览器观察与代码检查。
 
+根据请求结果与仓库证据路由，不依赖特殊用词。用户描述工作，Agent 自行读取指导并执行工作流命令。术语冲突或共享边界自动加载 `model.md`，非显然设计选择加载 `engineer.md`，受影响路径包含用户界面时加载 `frontend.md`，即使用户没有明确要求设计。实现时使用 `build.md`；在已有授权内按 `verify.md` → `land.md` → `reconcile.md` 完成收尾。`guide: true` 只增加教学，不负责启用能力；两种 profile 默认均使用此流程。
+
 ## 执行规则
 
 - conversation/session 只是焦点指针。关闭窗口、长时间不说话、继续追问，都**不能**把 change 判成完成。
@@ -28,9 +30,10 @@ description: 面向含 .keelson/ 目录项目的工程控制层。用于探索
 - Resume 时先用 `keelson focus --auto`；可以根据 branch 或唯一活动 change 给出候选，但存在歧义时绝不静默绑定。
 - `NOW.md` 为 First contact 时，只推断并确认 `INTENT.md`；不要盘点整个仓库生成 specs/rules。
 - 非平凡修改先读取当前上下文；改共享模块前运行 `keelson impact <files>`。
-- 只在 decision frontier 提问。先做风险触发式盲点扫描，再按 `interview.md` 每轮最多三个独立、已就绪的所有者决策：具体场景/选项、推荐默认值，“不确定”是合法路由。仓库证据、小实验或 Agent 工程判断能解决的事绝不问用户。
+- 新目标、实质性补充或前提变化时，按 `interview.md` 自动判断探索深度；目标不清、产品选择相互依赖或高影响承诺未定时主动深入，无需特殊提示词。明确任务直接推进。简单缺口每轮问一个就绪用户决定，复杂不确定性一轮问完当前就绪 frontier，给具体选项、推荐和理由；复用已定答案，自行调查事实。
 - 非显然机制/架构选择走 `engineer.md`：先还原事实、结果、约束和不变量，再写可证伪 hypothesis，用最便宜的实验/消融区分方案；复杂度必须用证据证明自己值得存在。
-- 只给工作本身定大小：trivial 直接改；quick 轻量 change；spec 先写验收、行为 delta 和计划，在用户已有授权内推进；只澄清尚未解决的所有者决策。
+- 只给工作本身定大小：trivial 走最小 quick 变更；quick 轻量 change；spec 先写验收、行为 delta 和计划，在用户已有授权内推进；只澄清尚未解决的所有者决策。
+- 修改产品文件前，自动对当前变更运行 `keelson start`，再加载 `keelson context --phase implement`；出现新关键决定后，确定答案再重新启动。用户无需运行这些命令。
 - 工件是信息容器，不是仪式。不要创建空 roadmap/glossary/rule/task/ledger/handoff/spec。
 - `tasks.md` 只是执行计划，不拥有“完成”判定权。只要 acceptance 与新鲜证据已经满足，未勾选的旧计划不能覆盖这个事实；实现路径变化时应重写或删除过时任务。
 - 知识维护属于 Keelson 内部职责。RECONCILE 时自动重写、拆分、去重超压的长期文档，大 spec 由 `land` 自动分片；除非涉及产品语义决策，否则绝不要求用户维护 Keelson。

package/skills/zh/keelson/references/build.md

@@ -2,6 +2,16 @@
 
 按切片逐个执行 `tasks.md`。怎么做由你选；这里只写容易出错的部分。
 
+## 按当前计划进入实现
+<!-- keelson: id=build.start | without: Agent 在计划未确定前改产品代码，或读取了另一个变更的规范 | sunset: never -->
+
+修改任务先创建最小有用变更，写明具体验收，再在已有用户授权内自动运行 `keelson start`。琐碎修改走最小 quick 变更，不另做计划或访谈。启动检查拒绝未决决定、未确认假设、缺失验收和未完成前置变更；记录当前计划，并在 `context.json` 中声明阶段上下文。决定被重开或计划/delta 改变时，先解决受影响分支再重新启动。不要让用户操作工作流。
+
+编辑前读取 `keelson context --phase implement`。它包含当前规范、delta、相关规则、决定和检查命令；`context.json` 可为 `implement`/`check` 阶段额外声明项目内相对路径。新涉及的路径应纳入上下文路由。spec 变更将用户原始要求和实质补充保留在 `request.md`，让评审者看到真正的目标，不用实现总结替代。
+
+Claude Code、Codex 和 CodeBuddy 提供受支持文件工具的原生门禁与会话上下文 hook；Codex 需要宿主信任 hooks。shell/MCP 写入及其他宿主由 Agent 遵循同一协议。该机制不是沙箱，也不能证明用户已经授权。
+
+
 ## 裁定，而不是停顿
 <!-- keelson: id=build.rulings | without: 代理把会话卡在计划早已回答的问题上；或者悄悄决定，推理过程丢失 | sunset: never -->
 
@@ -21,6 +31,8 @@ At-least-once with idempotent consumers. Exactly-once would need a broker featur
 
 更多 Agent 不是线性的 throughput multiplier。任务共享可变状态、同一契约，或者需要持续互相同步时，coordination/merge cost 可能超过并行收益；此时保持串行。只有边界清楚、输出可以独立验证、最终 merge contract 明确时才并行。不要靠“再加几个 Agent”挽救一个高度耦合的任务。
 
+已登记变更的子任务均附带独立一行 `KEELSON_CHANGE=<change-name>` 和阶段。Codex 子代理先自动运行 `keelson focus <change-name>`，再读取 `keelson context --phase implement`（评审用 `check`），然后执行任务。每个子代理有自己的线程身份，不从根会话猜测任务；保留分配的只读限制。恢复已有 focus 的子代理时，除非新任务明确要求切换，否则保留其当前关联。未登记变更的只读调查无需创建变更或添加标记。
+
 每个任务之后，由一个评审子代理（层级 ≥ `standard`，绝不低于实施者）对照 spec 和 rules 检查 diff。两者都记进 ledger：
 
 ```markdown

package/skills/zh/keelson/references/discover.md

@@ -1,6 +1,8 @@
 # 发现真正想要的是什么
 
-用户往往没法在第一句话里把完整需求说清楚，也不应该先学会哪些工程选型重要。发现阶段要在任何人挑数据库之前，先找到请求背后的问题。属于所有者的不确定性按 `interview.md` 处理；只有工作真实触发跨领域风险时才读 `design-lenses.md`。
+用户往往没法在第一句话里把完整需求说清楚，也不应该先学会哪些工程选型重要。发现阶段要在任何人挑数据库之前，先找到请求背后的问题。按 `interview.md` 自动根据目标、未决选择及后果决定探索深度，用户只说想做什么也适用；只有工作真实触发跨领域风险时才读 `design-lenses.md`。
+
+只读请求可以读取已有工件，但新回写、决定和记录只留在对话中，即使已有活动变更。下方持久化步骤仅在已有写入授权范围内执行。
 
 ## 先谈场景，再谈技术
 <!-- keelson: id=discover.scenario-first | without: 第一个问题就是负责人答不上来的技术选型，产品被他们的猜测塑形 | sunset: never -->
@@ -42,11 +44,11 @@
 |---|---|
 | 仓库或上下文已经确定 | 直接使用，并在写回中指出依据 |
 | 属于现实世界（代码行为、API 契约、实测、依赖能力） | 自己调查，或做一个小实验 |
-| 属于用户且会阻塞结果（目标、范围、验收、风险容忍度、公开承诺） | 只问一个问题 |
+| 属于用户且会阻塞结果（目标、范围、验收、风险容忍度、公开承诺） | 按复杂度询问一个问题或完整就绪 frontier |
 | 不阻塞，或很容易撤销 | 按授权决定，或留给后续切片 |
 | 证据已经耗尽 | 标为 UNKNOWN；不要把不确定性改写成用户的观点 |
 
-选择“实际信息价值”最高的缺口：哪个答案最可能改变下一个切片，再结合猜错它的代价。提问前先走 `interview.md` 的 Question Protocol。得到答案后更新写回，再重新判断决策前沿。“只问一个问题”只用于**真正阻塞工作的不确定性**，不是仪式：没有由用户掌握的关键缺口时，一个问题都不要问，直接推进。
+选择“实际信息价值”最高的缺口：哪个答案最可能改变下一个切片，再结合猜错它的代价。提问前先走 `interview.md` 的 Question Protocol。得到答案后更新写回，再重新判断决策前沿。简单缺口问一个问题，复杂不确定性问当前完整就绪 frontier；题数跟随决策结构：没有由用户掌握的关键缺口时，一个问题都不要问，直接推进。
 
 ## 范围守卫
 <!-- keelson: id=discover.scope-guard | without: 第一个请求就同时要五个独立领域，集成风险、调试成本和需求变动叠加放大 | sunset: never -->

package/skills/zh/keelson/references/frontend.md

@@ -1,6 +1,6 @@
 # 前端设计
 
-用于创建、改善、诊断或验收用户可见、可操作的界面。沿用现有变更生命周期，补充设计判断与可观察的界面验收。
+请求或受影响代码涉及创建、修改、诊断或验收用户可见、可操作的界面时自动适用，用户无需指定设计动作或本指导名称。沿用现有变更生命周期，在受影响的用户路径内补充设计判断与可观察的界面验收。
 
 ## 按问题加载
 <!-- keelson: id=frontend.routing | without: 局部修复被扩大为重设计，每次任务都加载全部指导 | sunset: never -->

package/skills/zh/keelson/references/interview.md

@@ -1,6 +1,19 @@
 # 自适应决策访谈
 
-Keelson 的使用者不需要掌握软件架构术语。访谈是隐藏控制逻辑：只找出真正属于所有者的决定，让每个问题都容易回答，然后尽快回到实现。普通工作**不是**问卷；只有用户明确要求“深挖一下 / 压力测试这个方案”时，才深入走完同一棵决策树的重要分支。
+Keelson 的使用者只需用普通语言描述目标。Agent 根据未决选择及其后果自动决定探索深度；用户无需知道 Skill 名称、特殊提示词或访谈模式开关。先调查，再让属于用户的决定容易回答，然后回到用户请求的工作。
+
+## 由工作本身触发需求探索
+<!-- keelson: id=interview.activation | without: 用户必须知道要主动要求深度访谈，模糊目标和影响重大的假设因此未经检查就进入实现 | sunset: never -->
+
+出现新目标、实质性补充，或足以改变已定前提的新证据时，先检查相关仓库事实和已有答案，再决定深度：
+
+- **清楚且有边界：** 结果、验收与相关约束已经明确，直接推进；常规小修改或事实解释不需要访谈仪式。
+- **一个关键缺口：** 询问当前已就绪、信息价值最高的用户决定，给出推荐和理由；得到答案后重新判断。
+- **相互关联的不确定性：** 目标或成功标准不清、产品选择存在依赖、需求相互冲突，或尚未确定的权限/数据/兼容/迁移承诺会实质改变设计。自动沿相关决策分支深入，在确定依赖它们的设计前解决。只要这些选择未定，“加个团队共享功能”这样的普通请求就足够触发，不要询问是否启用深度访谈。
+
+按缺失的决定与后果触发，不靠关键词或任务大小。高风险问题也可能已有契约可循。按 `design-lenses.md` 检查领域风险，自行调查事实，只问需要所有者判断的事。后续答案暴露新分支时使用同一规则；没有足以重开的新证据，就复用已定选择。
+
+需求探索不会扩大授权：讨论方案仍然只读；已授权修改在相关决定解决后继续实现。用户明确要求扩大评审范围时可以扩大范围，但自动探索不以此为前提。
 
 ## Question Protocol：每次打断都必须值得
 <!-- keelson: id=interview.protocol | without: Agent 会问没必要的问题，把实现选型甩给用户，或者自己都说不清答案会改变什么 | sunset: never -->
@@ -23,10 +36,12 @@ Keelson 的使用者不需要掌握软件架构术语。访谈是隐藏控制逻
 
 发现盲点**不等于**马上问用户。先路由成：已有保证、工程默认值、小实验、验收/证据场景，或者真正属于所有者的决定。只有最后一种才提问。
 
-## 一次一个决定，优先“识别”而不是“回忆”
+## 按复杂度组织问题，优先“识别”而不是“回忆”
 <!-- keelson: id=interview.one-at-a-time | without: 问题墙会压垮用户，而开放式技术术语会逼新人编造架构偏好 | sunset: never -->
 
-提问前读取 `keelson ask list --json`，已确定的答案不得重复询问；新证据确实要求重开时使用 `ask reopen <id> --reason`。每轮至多提出三个独立、前提已满足的用户决定；依赖问题等待前提解决。用 `ask add`、`settle`、`assume`、`frontier` 保存归属、答案和依据，不可逆决定不能靠假设通过。优先用具体场景，并让用户“识别”而不是凭空“回忆”：
+提问前先读取已有决定。当前请求授权修改项目时，在其活动变更上用 `ask add`、`settle`、`assume`、`frontier` 保存归属、依赖、答案和依据。已确定的答案不得重复询问；新证据确实要求重开时使用 `ask reopen <id> --reason`。只读探索即使已有活动变更，新答案也只留在对话中；获得实施或持久化授权后才写入。
+
+简单缺口每轮问一个最有价值的就绪用户决定（`ask frontier --limit 1`）。存在相互依赖的不确定性时，**一轮问完当前所有前提已确定的用户问题**（`ask frontier --all`），按主题分组，每题给推荐和理由。宿主限制题数时，用一个受支持的文本问题打包，或分批呈现同一轮；本轮前提未确定前不进入依赖问题。推荐不等于答案：除非已有授权明确委托该选择，否则等待用户回答。仓库和现实事实由 Agent 调查，不交给用户猜。不可逆决定必须明确确定，不能靠假设通过。优先用具体场景，并让用户“识别”而不是凭空“回忆”：
 
 - 用用户自己的语言描述场景；
 - 给 2–4 个**结果真正不同**的选项；有帮助时给每个选项附一条简短的 **工程影响**，不要让用户自己猜实现后果；
@@ -79,6 +94,8 @@ Keelson 的使用者不需要掌握软件架构术语。访谈是隐藏控制逻
 
 大致按依赖顺序解决：
 
+维护紧凑的决策树：每个未决选择标明前提，以及它会改变的结果。每个答案解决一个分支，也可能暴露新分支。每轮后重新计算已就绪的问题；复杂轮次问完整的就绪用户问题集合，每题给推荐和理由；等待这些答案后，再沿新解锁的分支继续。调查仍在进行意味着前提未定，不代表可以猜测。完整决策树留在内部，只展示当前问题和简短结果。
+
 **问题/角色 → 范围与非目标 → 可观察行为 → 数据/权限不变量 → 外部契约 → 故障语义 → 昂贵架构 → 实现细节**
 
 只有上游答案会改变后续分支时才问。发现 grab-bag 或 rabbit hole 时，把独立领域拆开，先确认哪个领域能解锁下一个真正有用的切片，把纯未来需求停放起来，不为“以后也许需要”提前设计。
@@ -109,12 +126,14 @@ Keelson 的使用者不需要掌握软件架构术语。访谈是隐藏控制逻
 ## 回读结果、写回真相、及时停止
 <!-- keelson: id=interview.stop | without: 答案只留在聊天里、同一个决定被重复询问，或者普通开发变成没完没了的访谈 | sunset: never -->
 
-得到答案后，用一句话确认 **决定 + 后果**，只把长期有效的结果写入其所属工件，然后重新计算 decision frontier。不要保存访谈流水账。
+得到答案后，用一句话确认 **决定 + 后果**，仅在当前请求授权写入时，把长期有效的结果写入其所属工件，然后重新计算 decision frontier。不要保存访谈流水账。
 
-普通工作中，只要下一个纵向切片已经具备：
+当前评审范围或下一个实现切片具备以下条件时停止提问：
 - 清楚的可观察结果；
 - 必要的边界/非目标；
-- 没有真正阻塞它的 owner-owned 未决项；
+- 没有会改变其结果或设计承诺的用户未决项或隐含假设；
 - 明确的 acceptance / evidence 路径；
 
-就停止提问。后续切片的问题可以保持 open，但不阻塞当前工作。只有用户明确要求 深挖 / 压力测试时，才继续走完请求边界内的**重要**分支；仍然拒绝纯未来假设和低价值实现细节。
+深入探索时，解决所有会改变当前结果或设计承诺的重要分支，包括前面答案新暴露的下游选择。共享架构仍依赖高影响未决项时，不得把切片当成已经安全。独立工作可以继续：把真正属于后续的未决问题移到 ROADMAP 或单独的 change，保留其依赖和未决状态。`start` 检查整个当前 change，不允许把阻塞项留在当前变更中却宣称该变更已就绪。拒绝纯未来假设和低价值实现细节。回到用户请求的工作，无需“结束访谈”口令，也不重复索取已有授权。
+
+对于已落盘的访谈，只有 `keelson ask frontier --all --json` 返回 `complete: true`，才能说已登记的树全部确定。问题列表为空也可能是调查未完、依赖阻塞或假设未确认。同时检查当前目标、边界和领域风险是否还有未登记的重要分支：图已完成不能证明发现已穷尽。只读请求的新发现仍保留在对话中。

package/skills/zh/keelson/references/land.md

@@ -2,6 +2,8 @@
 
 切片都验证通过，变更就是已实现；进入目标分支且 specs 已折叠，就是已集成；某个打了 tag 的版本把它发出去，才是已发布。这是三种状态，Keelson 分别报告。
 
+归档前检查 `decisions.json` 中已确定的答案。只把长期有效的产品契约提升为 delta Requirement 或带 capability 前缀的 `change.md → Decisions`，保留影响后续工作的理由。调查琐事留在变更内。`land` 合并这些契约，下次阶段上下文会读取更新后的事实。
+
 ## `keelson land <name>`
 <!-- keelson: id=land.command | without: delta specs 永远不合并，specs 不再描述当前系统，未验证或未批准的工作被宣布为已集成 | sunset: never -->
 

package/skills/zh/keelson/references/shape.md

@@ -20,7 +20,7 @@ quick 工作存在实质性歧义时，以及每一个 spec 变更里，都要
 3. **缺失信息（Missing）** — 无法从仓库查到的信息；按它能多大程度改变结果、边界、验收或难以撤销的选择来排序。
 4. **假设错了会怎样（Failure if wrong）** — 指出这类工作最可能的一种失败模式，例如解决错问题、范围膨胀、兼容性破坏、没有测量就优化、不安全迁移，或当前任务真正相关的风险。
 
-审计默认留在内部，只把短 write-back 真正需要的事实/假设写出来。没有关键缺口就按项目授权和默认值继续；存在由用户掌握且会改变结果的缺口时，按 `interview.md` 路由，只问一个最高价值问题，更新写回后重新判断。不要把审计清单展示给用户。
+审计默认留在内部，只把短 write-back 真正需要的事实/假设写出来。没有关键缺口就按项目授权和默认值继续；存在由用户掌握且会改变结果的缺口时，按 `interview.md` 路由，简单缺口问一个最高价值问题，复杂不确定性问完整就绪 frontier，更新写回后重新判断。不要把审计清单展示给用户。
 
 ## 写回你的理解
 <!-- keelson: id=shape.write-back | without: 代理按自己的解读去做；不一致要到代码写出来之后才暴露 | sunset: never -->
@@ -44,14 +44,14 @@ quick 工作存在实质性歧义时，以及每一个 spec 变更里，都要
 ## 下一个切片可交付时就停止提问
 <!-- keelson: id=shape.stop-rule | without: 代理要么用后面切片的问题把负责人问到筋疲力尽，要么在验收还没定义的切片上开工 | sunset: never -->
 
-标准不是"项目里没有任何未知"，而是：下一个切片有清楚的结果、边界和验收检查。关于后面切片的未决问题写进 `## Open questions` 并注明它阻塞什么，它不阻塞的工作继续。例如：下载权限未定，链接管理列表可以先建，但公开下载不能被默认打开。
+标准不是“项目里没有任何未知”，而是：当前范围有清楚的结果、边界和验收检查，并已按 `interview.md` 解决重要决策分支。不能靠缩小首个切片绕过未定的共享架构或产品承诺。真正独立的工作继续，后续问题写进 `## Open questions` 并标明阻塞什么。例如：下载权限没定，只有不预先绑定其语义的链接管理列表可以先做，不能默认开放公开下载。
 
 ## 访谈（只有 decision frontier 真正需要时）
 <!-- keelson: id=shape.interview | without: 架构歧义被 Agent 默默猜测，或者每个 spec change 都变成强制问卷 | sunset: never -->
 
 交互方式统一按 `interview.md`。spec 级变更**不等于**必须向用户提问：先自行解决仓库拥有的事实和可逆工程选择。工作涉及数据、安全、并发、兼容、错误处理/资源生命周期、运维、性能、UI/可访问性或 AI 行为时，只检查 `design-lenses.md` 里真正触发的行，把结果转成决定或证据义务。修改失败路径时，按其中的要求先写回归测试，再开始实现。
 
-假设检查默认在内部完成。除非不确定性确实属于所有者，否则不要用抽象的“我们在假设什么？”开场；把它翻译成具体的用户行为或风险后果再问。明确要求“深挖这个方案”才沿相关决策树继续问到底；普通工作只要下一个安全切片准备好就停止。
+假设检查默认在内部完成，把属于所有者的不确定性转成具体用户行为或风险后果。按 `interview.md` 自动决定深度，不等待特殊请求：相关选择相互依赖或高影响承诺未定时，在确定依赖它们的设计前深入探索。明确工作直接推进；相关分支解决后继续已授权的实现。
 
 ## 授权
 <!-- keelson: id=shape.authorization | without: 要么每一步都等批准，要么代理自己决定产品问题和生产操作 | sunset: never -->

package/skills/zh/keelson/references/verify.md

@@ -46,6 +46,8 @@ Ready/完成是由长期 gate 与证据支撑的状态，而证据有两个会
 ## 陌生读者评审（spec 档）
 <!-- keelson: id=verify.fresh-reader | without: 作者评审自己的工作；同一个盲点通过两次 | sunset: 连续 50 次陌生读者评审都没发现逐任务评审漏掉的东西时 -->
 
+用 `keelson context --phase check` 生成评审材料，附上 `request.md`；评审任务分别用独立行标明 `KEELSON_CHANGE=<change-name>` 和 `KEELSON_PHASE=check`。Codex 评审者自动执行 `keelson focus` 绑定任务，再读取 `keelson context --phase check`；其他受支持 hook 注入 check 依赖。评审者使用全新上下文、只读范围，不继承整段对话；实现者修复问题后，再复核受影响结果。宿主无法提供独立评审者时，明确报告缺口，不得编造评审。
+
 派一个没看过对话的评审者（spec 变更层级 ≥ `deep`），给它原始请求、`change.md`、delta specs 和 diff。让它找：没有真实覆盖的验收项、需求缺口、rule 违反、有风险的假设、任何维护者会反对的地方。每条发现要么处理，要么记入 ledger。第二个代理的同意是信号，不是证明；被检查的是验收清单。
 
 ## 完成报告

package/skills/zh/keelson/templates/resident-block.md

@@ -1,7 +1,7 @@
 <!-- keelson:start -->
 ## Keelson
 
-本项目由 Keelson 管理。非平凡工作开始前运行 `keelson guide` 并按其执行。
+本项目由 Keelson 管理。处理项目工作时运行 `keelson guide` 并按其执行。
 需要任务专用指导时运行 `keelson guide <reference>`；只有项目需要提交审计副本时才使用 `keelson init --vendor`。
 `.keelson/` 之外的文件只负责宿主发现，不要在这里复制 Keelson 规则。
 <!-- keelson:end -->

package/skills/zh/keelson/templates/workflow.md

@@ -2,11 +2,11 @@
 
 项目真相与长期 work item 位于 `.keelson/`；本机会话、信任与密钥位于 Git 私有运行目录；持久签名记录和日志跟随变更归档。**Session 不是 Task**：它只是指向当前对话正在围绕哪个 work item。
 
-每个非平凡修改请求遵循 **ORIENT → BOUND → BUILD → SENSE → RECONCILE**。
+每个修改请求遵循 **ORIENT → BOUND → BUILD → SENSE → RECONCILE**。
 
 - **ORIENT** —— 检查工作树和当前 session focus。同一目标的追问继续使用 focus change；用户说“继续”时运行 `keelson focus --auto`，存在歧义时绝不静默绑定。
-- **BOUND** —— 提问前先读仓库。仓库事实和可逆工程选择自行解决；只在 decision frontier 每轮询问最多三个独立、已就绪、真正属于所有者且会影响结果的决定。trivial 直接改；quick 创建最小有用 change；spec 写 acceptance、行为 delta 和 plan。只检查当前工作真实触发的风险镜头。
-- **BUILD** —— 一次推进一个纵向切片。独立的新修改目标创建新 change；围绕同一目标继续追问不会。
+- **BOUND** —— 提问前先读仓库。按 `interview.md` 在目标不清、产品选择相互依赖或高影响承诺未定时自动深入探索，无需特殊提示词。仓库事实和可逆工程选择自行解决；简单缺口问一个就绪用户决定，复杂不确定性一轮问完就绪 frontier，附推荐和理由。明确任务直接推进。trivial 走最小 quick 变更；quick 创建最小有用 change；spec 写 acceptance、行为 delta 和 plan。只检查当前工作真实触发的风险镜头。
+- **BUILD** —— 自动通过 `keelson start` 并加载 `keelson context --phase implement`，然后一次推进一个纵向切片。独立的新修改目标创建新 change；围绕同一目标继续追问不会。
 - **SENSE** —— 尽早跑便宜检查；完成必须有当前工作树上的新鲜 `keelson check --record` 证据。任务复选框只描述当前计划，不负责判定完成。
 - **RECONCILE** —— 每轮修改后根据 acceptance、阻塞项、rollout/兼容性和新鲜 verification 重新计算生命周期。land 前静默完成 context 暴露的内部知识维护：重写单例当前状态文档、拆分/去重 rules，并让 `land` 自动分片大型 spec。gate 满足后状态成为 `ready` 并自动 land；不等待用户说“做完了”，也不把维护流程暴露给用户。
 - 会话结束、长时间空闲、compaction、关闭窗口只改变本机会话 runtime，绝不自动完成、取消或 land 长期 work item。