@enrichlayer/el-linear 1.44.0 → 1.44.1

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

@@ -185,6 +185,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 +211,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 +402,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.1",
   "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"
   },