@enrichlayer/el-linear 1.44.0 → 1.44.2

package/claude-skills/linear-operations/SKILL.md

@@ -99,6 +99,38 @@ el-linear issues read DEV-123 --format json 2>&1 | python3 -c "import json,sys;
 
 `--body` is mutually exclusive with `--field` / `--sections` / `--with` (those extract named parts or extend the JSON envelope; `--body` is the whole thing as text).
 
+#### Citing an issue's stated rationale: `--body` or `--field`, never `--format summary`
+
+**`--format summary` truncates the description.** That is correct for scanning a board and wrong the moment you quote, cite, or reason from what an issue *says*. A research pass once read an issue with `--format summary`, saw a truncated description, and published the opposite of the design position that issue states outright — the fix was one command with a different flag, run twenty minutes too late.
+
+So: the moment a claim is about an issue's **stated rationale** — what a decision claimed at the time, why an approach was chosen, what a spec requires — read `--body` (or `--field <section>` for one section) and quote from that.
+
+```bash
+# ✅ Reasoning from what the issue actually says
+el-linear issues read DEV-123 --body 2>&1
+el-linear issues read DEV-123 --field "Why we need this" 2>&1
+
+# ❌ Citing a summary — the description you are quoting may be cut off
+el-linear issues read DEV-123 --format summary 2>&1
+```
+
+The scope is narrow and worth stating precisely: an issue body is a weak source for *system behavior* — it records what someone intended, not what the code does — but it is the **authoritative** artifact for what a decision claimed at the time. Use it for the second, not the first.
+
+#### An umbrella's status is not delivery evidence
+
+A parent or umbrella issue's own status says nothing reliable about whether the work shipped. Read its children and slices, then read the artifact.
+
+```bash
+el-linear issues related DEV-100 --format summary 2>&1
+```
+
+Neither direction is safe on its own:
+
+- **Canceled does not mean abandoned.** An umbrella is routinely closed as bookkeeping after its slices land — one was reported as "abandoned" in a research document while all six of its children were Done and the code was in production.
+- **Done children do not prove delivery either.** A child can be a duplicate, a rename, or an administrative closure.
+
+The tracker is a lead. The **merged MR or the deployed code** is the evidence — go look at it before writing "shipped" or "abandoned".
+
 ### Comment reads and full comment bodies
 
 When you need a specific comment, or the full text of a long comment, use the
@@ -185,6 +217,14 @@ Every issue should communicate **why** the work matters and **what** success loo
 ### Example
 
 ```markdown
+## Intake decision
+- Needed: Yes — contact tracking is split across spreadsheets, Linear, and memory.
+- Worth doing: Yes — outbound scale makes the fragmentation costly now, not later.
+- Existing work: searched "CRM", "contact tracking" with --include-closed; no duplicate.
+- Owner: Nico (operations tooling).
+- Placement: OPS / Sales infrastructure; self-hosted on the Hetzner box.
+- Decision: PROCEED
+
 ## Set up a self-hosted CRM
 
 The team needs a CRM to replace fragmented contact tracking
@@ -203,6 +243,26 @@ and outreach tracked in one place.
 
 ---
 
+## Intake Decision Block (MANDATORY, blocking)
+
+**`el-linear issues create` refuses any description without a `## Intake decision` section.** It must open the description, and the six lines must appear in this order:
+
+```markdown
+## Intake decision
+- Needed: Yes — <why this is needed>
+- Worth doing: Yes — <why the value exceeds the cost>
+- Existing work: <duplicate/search result and evidence>
+- Owner: <canonical owner or source of truth>
+- Placement: <team/project/repository/document path>
+- Decision: PROCEED
+```
+
+Write it **before** composing the rest of the body. The gate runs before the create POST, so omitting it fails the call outright — nothing is written, and a finished issue body then has to be reassembled around a section you were never told to include.
+
+The point is that the decision is *recorded*, not merely reached: `Existing work` cites the search you actually ran, and `Owner`/`Placement` name a concrete destination rather than a plausible one. It is the same discipline the two gates below enforce mechanically, applied to the judgment they cannot check.
+
+Escape hatch: `--allow-missing-intake-decision`, which is recorded. It exists for an **accountable human** who has approved an exceptional create — not for an agent that would rather not write the block. `--skip-validation` also bypasses it but disables every other field check too, so prefer the narrow flag.
+
 ## Duplicate & Related Issues Check (MANDATORY)
 
 **Search before creating. No exceptions.**
@@ -374,6 +434,7 @@ Don't start implementation work on an unassigned issue — the assignee is the p
 
 Complete ALL items before creating any issue:
 
+- [ ] **Intake decision** — description opens with the `## Intake decision` block (above). Blocking.
 - [ ] **Duplicate & related check** — searched for existing issues, linked related ones (above).
 - [ ] **Team** — ask user if unclear (`el-linear teams list`).
 - [ ] **Assignee** — ask user if unclear (`el-linear users list --active`).

package/dist/config/intake-decision-validation.js

@@ -63,7 +63,11 @@ const WRAPPED_IN_EMPHASIS = /^([*_]{1,3})([^*_].*?)\1$/;
 const INLINE_EMPHASIS = /(^|[^\p{L}\p{N}])([*_]{1,3})(?=\S)(.+?\S)\2(?=$|[^\p{L}\p{N}])/gu;
 const PLACEHOLDER = /^(?:tbd|todo|unknown|n\/?a|none|unsure|not decided|-)\.?$/i;
 const NON_SPECIFIC = /^(?:yes|no)$/i;
-const AFFIRMATIVE_WITH_REASON = /^yes\s*(?:[-—:;,]|because)\s*(\S.{2,})$/i;
+// The gate exists to force an explicit verdict AND a reason. Which punctuation
+// joins the two carries no meaning, so every ordinary separator is accepted —
+// including `.`, which reads most naturally when the reason is a full sentence.
+// A bare verdict still fails: the trailing group requires real reason text.
+const AFFIRMATIVE_WITH_REASON = /^yes\s*(?:[-–—.:;,]|because)\s*(\S.{2,})$/i;
 function labelOf(key) {
     return FIELD_DEFINITIONS.find((field) => field.key === key)?.label ?? key;
 }
@@ -252,7 +256,7 @@ function describeFieldProblem(field, problem, value) {
         case "non-specific":
             return `The intake field "${field}" reads "${quote(value)}", which is too short or too generic to be a specific answer.`;
         case "no-judgment":
-            return `The intake field "${field}" reads "${quote(value)}" — the content is there, but it is not an explicit "Yes — <reason>" judgment.`;
+            return `The intake field "${field}" reads "${quote(value)}" — the verdict is there, but no reason follows it. Write both together, e.g. "Yes — <reason>" or "Yes. <reason>"; any ordinary separator works.`;
         case "placeholder-reason":
             return `The intake field "${field}" says Yes but gives the placeholder reason "${quote(value)}"; record the real reason.`;
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@enrichlayer/el-linear",
-  "version": "1.44.0",
+  "version": "1.44.2",
   "description": "A pragmatic CLI for Linear.app — deterministic team/label/member resolution, structured issue validation, configurable term enforcement, and a GraphQL escape hatch.",
   "main": "dist/main.js",
   "types": "dist/main.d.ts",
@@ -52,7 +52,7 @@
   },
   "dependencies": {
     "@inquirer/prompts": "^8.4.2",
-    "@linear/sdk": "^87.0.0",
+    "@linear/sdk": "^88.0.0",
     "commander": "^15.0.0",
     "picocolors": "^1.1.1"
   },