Ln Disambiguate
Generate cases where plausible interpretations diverge; ask the user to classify the case.
Users recognize intent in concrete examples faster than they author abstract predicates. Use the TiCoder move generalized beyond tests: produce examples, counterexamples, edge cases, and candidate outcomes that separate meanings. Then translate the answer into typed conclusions.
Use this instead of ln-grill when the work has enough shape that ambiguity collapse is the next move. Use ln-grill when the idea still needs broad Socratic pressure.
If local context can answer the question, inspect it instead of asking. Read only the context needed to form precise contrasts: memory/SPEC.md, memory/PLAN.md, and files they explicitly point to. Use the current lexicon; when terms are overloaded, name the competing meanings.
For each ambiguity:
- Name the ambiguous claim.
- Generate 2–4 competing interpretations.
- Find the smallest scenario where they produce different outcomes.
- Ask one contrastive classification question.
- Translate the answer into candidate durable conclusions:
decisioninvariantconstraintassumptionexamplecounterexamplecriterionunresolved ambiguity
Prefer one high-yield question at a time. Multiple choice is useful when options are real; forced choice is harmful when it hides the likely fifth answer. Always allow “other / depends — explain.”
Ask questions like:
- “In this exact case, which outcome is correct?”
- “Is this inside or outside the commitment?”
- “Would this count as a bug?”
- “Which option should be rejected?”
- “Does this example witness the rule, contradict it, or sit outside scope?”
Include your recommended answer when you have enough context, and explain why.
Use behavioral kernels as hidden interviewer machinery. Activate at most the top 2–3 relevant kernels:
| Kernel |
Looks for |
Typical artifact |
| Identity & reference |
ids, references, links, uniqueness |
entity / reference invariant |
| Containment & topology |
parent/child, folders, ordering, graphs |
membership / topology invariant |
| Validation & normalization |
valid/invalid input, canonical forms |
parser or validation contract |
| State & lifecycle |
states, transitions, terminal states |
state-machine invariant |
| Temporal history |
undo, redo, audit, expiration |
history / timeline invariant |
| Optimization & preference |
best, preferred, tie-breaks |
ranking or objective rule |
| Authority & capability |
roles, permissions, delegation |
authorization predicate |
| Concurrency & collaboration |
offline, stale, conflict, merge |
conflict-resolution semantics |
| Transactions & atomicity |
all-or-nothing multi-object updates |
transaction invariant |
| Resource accounting |
balances, quotas, capacity, limits |
conservation / bounds invariant |
| Derived data & views |
counts, filters, projections, caches |
view consistency invariant |
| Error & recovery |
retry, rollback, compensation |
failure / recovery contract |
| External effects |
APIs, queues, webhooks, clocks |
boundary / adapter contract |
| Change & migration |
legacy, compatibility, upgrade |
migration / refinement invariant |
| Observability & evidence |
logs, traces, explanations, audit |
trace / provenance invariant |
Example:
A project is deleted while it still has tasks. Which behavior is correct?
A. Delete the tasks too.
B. Archive the tasks and keep them readable.
C. Move tasks to an unassigned pool.
D. Block deletion until tasks are reassigned or deleted.
E. Other / depends.
My recommendation is B if historical traceability matters more than cleanup, because it preserves references and gives us a clear data-integrity invariant.
Translate the answer:
- decision: “Deleted projects archive their tasks rather than deleting or reassigning them.”
- invariant: “Archived tasks retain a tombstone reference to the deleted project.”
- positive example: “Deleting a project with open tasks makes those tasks archived and readable.”
- counterexample: “Tasks silently disappearing after project deletion is rejected.”
- criterion: “A deletion test verifies task archival and readable tombstone references.”
Stop when the ambiguity is collapsed, explicitly deferred, or ready for ln-spec.
Do not create or edit planning artifacts here. Durable conclusions promote into memory/SPEC.md or memory/PLAN.md through the next routed skill.
Routing
When the ambiguity pass is complete, present these options to the user. If tool-ask-question is available, use it; otherwise use a numbered list.
| # |
Label |
Target |
Why |
| 1 |
Write/update spec |
ln-spec |
Durable conclusions should enter memory/SPEC.md |
| 2 |
Plan frontier |
ln-plan |
The meaning is clear but work needs sequencing |
| 3 |
Scope one slice |
ln-scope |
One implementation slice is now obvious |
| 4 |
Grill further |
ln-grill |
The ambiguity pass exposed broader design uncertainty |
Recommended: choose ln-spec when decisions, invariants, assumptions, lexicon, examples, or criteria changed.
1---2name: ln-disambiguate3description: Collapse meaningful ambiguity with contrastive examples. Use when a plan/design has several plausible meanings, requirements feel vague, examples would clarify intent faster than grilling, or the user asks to disambiguate, find ambiguity, use behavioral kernels, or ask contrastive questions.4---56# Ln Disambiguate78Generate cases where plausible interpretations diverge; ask the user to classify the case.910Users recognize intent in concrete examples faster than they author abstract predicates. Use the TiCoder move generalized beyond tests: produce examples, counterexamples, edge cases, and candidate outcomes that separate meanings. Then translate the answer into typed conclusions.1112Use this instead of `ln-grill` when the work has enough shape that ambiguity collapse is the next move. Use `ln-grill` when the idea still needs broad Socratic pressure.1314If local context can answer the question, inspect it instead of asking. Read only the context needed to form precise contrasts: `memory/SPEC.md`, `memory/PLAN.md`, and files they explicitly point to. Use the current lexicon; when terms are overloaded, name the competing meanings.1516For each ambiguity:17181. Name the ambiguous claim.192. Generate 2–4 competing interpretations.203. Find the smallest scenario where they produce different outcomes.214. Ask one contrastive classification question.225. Translate the answer into candidate durable conclusions:23 - `decision`24 - `invariant`25 - `constraint`26 - `assumption`27 - `example`28 - `counterexample`29 - `criterion`30 - `unresolved ambiguity`3132Prefer one high-yield question at a time. Multiple choice is useful when options are real; forced choice is harmful when it hides the likely fifth answer. Always allow “other / depends — explain.”3334Ask questions like:3536- “In this exact case, which outcome is correct?”37- “Is this inside or outside the commitment?”38- “Would this count as a bug?”39- “Which option should be rejected?”40- “Does this example witness the rule, contradict it, or sit outside scope?”4142Include your recommended answer when you have enough context, and explain why.4344Use behavioral kernels as hidden interviewer machinery. Activate at most the top 2–3 relevant kernels:4546| Kernel | Looks for | Typical artifact |47| --- | --- | --- |48| Identity & reference | ids, references, links, uniqueness | entity / reference invariant |49| Containment & topology | parent/child, folders, ordering, graphs | membership / topology invariant |50| Validation & normalization | valid/invalid input, canonical forms | parser or validation contract |51| State & lifecycle | states, transitions, terminal states | state-machine invariant |52| Temporal history | undo, redo, audit, expiration | history / timeline invariant |53| Optimization & preference | best, preferred, tie-breaks | ranking or objective rule |54| Authority & capability | roles, permissions, delegation | authorization predicate |55| Concurrency & collaboration | offline, stale, conflict, merge | conflict-resolution semantics |56| Transactions & atomicity | all-or-nothing multi-object updates | transaction invariant |57| Resource accounting | balances, quotas, capacity, limits | conservation / bounds invariant |58| Derived data & views | counts, filters, projections, caches | view consistency invariant |59| Error & recovery | retry, rollback, compensation | failure / recovery contract |60| External effects | APIs, queues, webhooks, clocks | boundary / adapter contract |61| Change & migration | legacy, compatibility, upgrade | migration / refinement invariant |62| Observability & evidence | logs, traces, explanations, audit | trace / provenance invariant |6364Example:6566> A project is deleted while it still has tasks. Which behavior is correct?67>68> A. Delete the tasks too.69> B. Archive the tasks and keep them readable.70> C. Move tasks to an unassigned pool.71> D. Block deletion until tasks are reassigned or deleted.72> E. Other / depends.73>74> My recommendation is B if historical traceability matters more than cleanup, because it preserves references and gives us a clear data-integrity invariant.7576Translate the answer:7778- decision: “Deleted projects archive their tasks rather than deleting or reassigning them.”79- invariant: “Archived tasks retain a tombstone reference to the deleted project.”80- positive example: “Deleting a project with open tasks makes those tasks archived and readable.”81- counterexample: “Tasks silently disappearing after project deletion is rejected.”82- criterion: “A deletion test verifies task archival and readable tombstone references.”8384Stop when the ambiguity is collapsed, explicitly deferred, or ready for `ln-spec`.8586Do not create or edit planning artifacts here. Durable conclusions promote into `memory/SPEC.md` or `memory/PLAN.md` through the next routed skill.8788## Routing8990When the ambiguity pass is complete, present these options to the user. If `tool-ask-question` is available, use it; otherwise use a numbered list.9192| # | Label | Target | Why |93| --- | --- | --- | --- |94| 1 | Write/update spec | `ln-spec` | Durable conclusions should enter `memory/SPEC.md` |95| 2 | Plan frontier | `ln-plan` | The meaning is clear but work needs sequencing |96| 3 | Scope one slice | `ln-scope` | One implementation slice is now obvious |97| 4 | Grill further | `ln-grill` | The ambiguity pass exposed broader design uncertainty |9899Recommended: choose `ln-spec` when decisions, invariants, assumptions, lexicon, examples, or criteria changed.
hashintel