@codyswann/lisa 2.4.0 → 2.5.1

package/cdk/copy-overwrite/tsconfig.json

@@ -1,6 +1,3 @@
 {
-  "extends": ["@codyswann/lisa/tsconfig/cdk", "./tsconfig.local.json"],
-  "compilerOptions": {
-    "baseUrl": "./"
-  }
+  "extends": ["@codyswann/lisa/tsconfig/cdk", "./tsconfig.local.json"]
 }

package/dist/configs/eslint/base.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/configs/eslint/base.ts"],"names":[],"mappings":"AACA;;;;;;;;GAQG;AACH,OAAO,cAAc,MAAM,iDAAiD,CAAC;AAC7E,OAAO,EAAE,MAAM,YAAY,CAAC;AAC5B,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AACrC,OAAO,UAAU,MAAM,0BAA0B,CAAC;AAClD,OAAO,KAAK,MAAM,qBAAqB,CAAC;AACxC,OAAO,QAAQ,MAAM,oCAAoC,CAAC;AAC1D,OAAO,OAAO,MAAM,uBAAuB,CAAC;AAC5C,OAAO,OAAO,MAAM,SAAS,CAAC;AAC9B,OAAO,QAAQ,MAAM,mBAAmB,CAAC;AAIzC;;;GAGG;AACH,eAAO,MAAM,cAAc,UAmD1B,CAAC;AAEF;;;GAGG;AACH,eAAO,MAAM,iBAAiB;;;;CAI7B,CAAC;AAEF;;;;GAIG;AACH,eAAO,MAAM,cAAc,QAAO,MAAM,CAAC,MAAM,EA+Bd,CAAC;AAElC;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc,eAAgB,OAAO,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyJjE,CAAC;AAEH;;;GAGG;AACH,eAAO,MAAM,sBAAsB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAUjC,CAAC;AAEH;;;GAGG;AACH,eAAO,MAAM,kBAAkB;;;;;;;CAO7B,CAAC;AAEH;;;GAGG;AACH,eAAO,MAAM,sBAAsB;;;;;CAKjC,CAAC;AAEH;;;;GAIG;AACH,eAAO,MAAM,oBAAoB,wBAAwB,MAAM,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;CA6B/D,CAAC;AAEH;;;;;GAKG;AACH,eAAO,MAAM,kBAAkB,iBACf,MAAM,EAAE,+BACL,MAAM;;;;;;;;;;;;;;;;;;CAuBvB,CAAC;AAEH;;;;GAIG;AACH,eAAO,MAAM,sBAAsB,kBACnB,MAAM,EAAE;;;;;;CAStB,CAAC;AAGH,OAAO,EACL,cAAc,EACd,UAAU,EACV,OAAO,EACP,EAAE,EACF,KAAK,EACL,QAAQ,EACR,OAAO,EACP,QAAQ,GACT,CAAC"}
+{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/configs/eslint/base.ts"],"names":[],"mappings":"AACA;;;;;;;;GAQG;AACH,OAAO,cAAc,MAAM,iDAAiD,CAAC;AAC7E,OAAO,EAAE,MAAM,YAAY,CAAC;AAC5B,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AACrC,OAAO,UAAU,MAAM,0BAA0B,CAAC;AAClD,OAAO,KAAK,MAAM,qBAAqB,CAAC;AACxC,OAAO,QAAQ,MAAM,oCAAoC,CAAC;AAC1D,OAAO,OAAO,MAAM,uBAAuB,CAAC;AAC5C,OAAO,OAAO,MAAM,SAAS,CAAC;AAC9B,OAAO,QAAQ,MAAM,mBAAmB,CAAC;AAIzC;;;GAGG;AACH,eAAO,MAAM,cAAc,UAmD1B,CAAC;AAEF;;;GAGG;AACH,eAAO,MAAM,iBAAiB;;;;CAI7B,CAAC;AAEF;;;;GAIG;AACH,eAAO,MAAM,cAAc,QAAO,MAAM,CAAC,MAAM,EA+Bd,CAAC;AAElC;;;;;;;;GAQG;AACH,eAAO,MAAM,cAAc,GAAI,YAAY,OAAO,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyJjE,CAAC;AAEH;;;GAGG;AACH,eAAO,MAAM,sBAAsB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAUjC,CAAC;AAEH;;;GAGG;AACH,eAAO,MAAM,kBAAkB;;;;;;;CAO7B,CAAC;AAEH;;;GAGG;AACH,eAAO,MAAM,sBAAsB;;;;;CAKjC,CAAC;AAEH;;;;GAIG;AACH,eAAO,MAAM,oBAAoB,GAAI,qBAAoB,MAAM,EAAO;;;;;;;;;;;;;;;;;;;;;;;;;;CA6BpE,CAAC;AAEH;;;;;GAKG;AACH,eAAO,MAAM,kBAAkB,GAC7B,cAAc,MAAM,EAAE,YAAc,EACpC,iBAAiB,MAAM;;;;;;;;;;;;;;;;;;CAuBvB,CAAC;AAEH;;;;GAIG;AACH,eAAO,MAAM,sBAAsB,GACjC,eAAc,MAAM,EAAsC;;;;;;CAS1D,CAAC;AAGH,OAAO,EACL,cAAc,EACd,UAAU,EACV,OAAO,EACP,EAAE,EACF,KAAK,EACL,QAAQ,EACR,OAAO,EACP,QAAQ,GACT,CAAC"}

package/dist/configs/jest/base.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/base.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC;;;GAGG;AACH,eAAO,MAAM,iBAAiB,EAAE,MAAM,CAAC,mBAAmB,CAOzD,CAAC;AAEF;;;;;;;;;;;;;GAaG;AACH,wBAAgB,8BAA8B,IAAI,SAAS,MAAM,EAAE,CAMlE;AAED;;;GAGG;AACH,eAAO,MAAM,yBAAyB,EAAE,SAAS,MAAM,EAatD,CAAC;AAEF;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,eAAe,aAChB,MAAM,CAAC,mBAAmB,CAAC,aAC1B,MAAM,CAAC,mBAAmB,CAAC,KACrC,MAAM,CAAC,mBAAmB,CAO3B,CAAC;AAEH;;;;;;;;;GASG;AACH,eAAO,MAAM,YAAY,eAAgB,MAAM,EAAE,KAAG,MAyBjD,CAAC"}
+{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/base.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC;;;GAGG;AACH,eAAO,MAAM,iBAAiB,EAAE,MAAM,CAAC,mBAAmB,CAOzD,CAAC;AAEF;;;;;;;;;;;;;GAaG;AACH,wBAAgB,8BAA8B,IAAI,SAAS,MAAM,EAAE,CAMlE;AAED;;;GAGG;AACH,eAAO,MAAM,yBAAyB,EAAE,SAAS,MAAM,EAatD,CAAC;AAEF;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,eAAe,GAC1B,UAAU,MAAM,CAAC,mBAAmB,CAAC,EACrC,WAAW,MAAM,CAAC,mBAAmB,CAAC,KACrC,MAAM,CAAC,mBAAmB,CAO3B,CAAC;AAEH;;;;;;;;;GASG;AACH,eAAO,MAAM,YAAY,GAAI,GAAG,SAAS,MAAM,EAAE,KAAG,MAyBjD,CAAC"}

package/dist/configs/jest/cdk.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cdk.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/cdk.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EAChB,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,GAChB,CAAC;AAEF;;GAEG;AACH,UAAU,cAAc;IACtB,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAED;;;;;;;;GAQG;AACH,eAAO,MAAM,gBAAgB,qBAE1B,cAAc,KAAQ,MAevB,CAAC"}
+{"version":3,"file":"cdk.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/cdk.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EAChB,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,GAChB,CAAC;AAEF;;GAEG;AACH,UAAU,cAAc;IACtB,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAED;;;;;;;;GAQG;AACH,eAAO,MAAM,gBAAgB,GAAI,kBAE9B,cAAmB,KAAG,MAevB,CAAC"}

package/dist/configs/jest/expo.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"expo.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/expo.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,EAC/B,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,GAC/B,CAAC;AAEF;;GAEG;AACH,UAAU,eAAe;IACvB,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAED;;;;;;;;GAQG;AACH,eAAO,MAAM,iBAAiB,qBAE3B,eAAe,KAAQ,MAmDxB,CAAC"}
+{"version":3,"file":"expo.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/expo.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,EAC/B,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,GAC/B,CAAC;AAEF;;GAEG;AACH,UAAU,eAAe;IACvB,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAED;;;;;;;;GAQG;AACH,eAAO,MAAM,iBAAiB,GAAI,kBAE/B,eAAoB,KAAG,MAmDxB,CAAC"}

package/dist/configs/jest/nestjs.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"nestjs.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/nestjs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EAChB,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,GAChB,CAAC;AAEF;;GAEG;AACH,UAAU,iBAAiB;IACzB,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAwBD;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,mBAAmB,qBAE7B,iBAAiB,KAAQ,MAW1B,CAAC"}
+{"version":3,"file":"nestjs.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/nestjs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EAChB,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,GAChB,CAAC;AAEF;;GAEG;AACH,UAAU,iBAAiB;IACzB,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAwBD;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,mBAAmB,GAAI,kBAEjC,iBAAsB,KAAG,MAW1B,CAAC"}

package/dist/configs/jest/typescript.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"typescript.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/typescript.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,EAC/B,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,GAC/B,CAAC;AAEF;;GAEG;AACH,UAAU,qBAAqB;IAC7B,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,uBAAuB,qBAEjC,qBAAqB,KAAQ,MAwB9B,CAAC"}
+{"version":3,"file":"typescript.d.ts","sourceRoot":"","sources":["../../../src/configs/jest/typescript.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AACH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,MAAM,CAAC;AAEnC,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,EAC/B,MAAM,WAAW,CAAC;AAGnB,OAAO,EACL,yBAAyB,EACzB,iBAAiB,EACjB,YAAY,EACZ,eAAe,EACf,8BAA8B,GAC/B,CAAC;AAEF;;GAEG;AACH,UAAU,qBAAqB;IAC7B,gEAAgE;IAChE,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC,mBAAmB,CAAC,CAAC;CACnD;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,uBAAuB,GAAI,kBAErC,qBAA0B,KAAG,MAwB9B,CAAC"}

package/dist/configs/vitest/base.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/base.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC;;;;GAIG;AACH,MAAM,WAAW,gBAAgB;IAC/B,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;IAC7B,QAAQ,CAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAC3B,QAAQ,CAAC,SAAS,CAAC,EAAE,MAAM,CAAC;IAC5B,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAC;CACzB;AAED;;;;GAIG;AACH,MAAM,WAAW,kBAAkB;IACjC,QAAQ,CAAC,MAAM,CAAC,EAAE;QAChB,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;QAC7B,QAAQ,CAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;QAC3B,QAAQ,CAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAC5B,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAC;KACzB,CAAC;IACF,QAAQ,EAAE,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC;CAClC;AAED;;;GAGG;AACH,eAAO,MAAM,iBAAiB,EAAE,kBAO/B,CAAC;AAEF;;;;;;GAMG;AACH,eAAO,MAAM,yBAAyB,EAAE,SAAS,MAAM,EActD,CAAC;AAEF;;;;GAIG;AACH,eAAO,MAAM,qBAAqB,EAAE,SAAS,MAAM,EAIlD,CAAC;AAEF;;;;;;GAMG;AACH,eAAO,MAAM,aAAa,eACZ,kBAAkB,KAC7B,gBAaD,CAAC;AAEH;;;;;;;;;;GAUG;AACH,eAAO,MAAM,eAAe,aAChB,kBAAkB,aACjB,kBAAkB,KAC5B,kBAOD,CAAC;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,eAAgB,UAAU,EAAE,KAAG,UA4C7D,CAAC"}
+{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/base.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC;;;;GAIG;AACH,MAAM,WAAW,gBAAgB;IAC/B,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;IAC7B,QAAQ,CAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;IAC3B,QAAQ,CAAC,SAAS,CAAC,EAAE,MAAM,CAAC;IAC5B,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAC;CACzB;AAED;;;;GAIG;AACH,MAAM,WAAW,kBAAkB;IACjC,QAAQ,CAAC,MAAM,CAAC,EAAE;QAChB,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;QAC7B,QAAQ,CAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;QAC3B,QAAQ,CAAC,SAAS,CAAC,EAAE,MAAM,CAAC;QAC5B,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAC;KACzB,CAAC;IACF,QAAQ,EAAE,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC;CAClC;AAED;;;GAGG;AACH,eAAO,MAAM,iBAAiB,EAAE,kBAO/B,CAAC;AAEF;;;;;;GAMG;AACH,eAAO,MAAM,yBAAyB,EAAE,SAAS,MAAM,EActD,CAAC;AAEF;;;;GAIG;AACH,eAAO,MAAM,qBAAqB,EAAE,SAAS,MAAM,EAIlD,CAAC;AAEF;;;;;;GAMG;AACH,eAAO,MAAM,aAAa,GACxB,YAAY,kBAAkB,KAC7B,gBAaD,CAAC;AAEH;;;;;;;;;;GAUG;AACH,eAAO,MAAM,eAAe,GAC1B,UAAU,kBAAkB,EAC5B,WAAW,kBAAkB,KAC5B,kBAOD,CAAC;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,GAAI,GAAG,SAAS,UAAU,EAAE,KAAG,UA4C7D,CAAC"}

package/dist/configs/vitest/cdk.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cdk.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/cdk.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,EACnB,MAAM,WAAW,CAAC;AAEnB,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAGpD,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,GACnB,CAAC;AAEF,YAAY,EAAE,kBAAkB,EAAE,CAAC;AAEnC;;GAEG;AACH,UAAU,gBAAgB;IACxB,mFAAmF;IACnF,QAAQ,CAAC,UAAU,CAAC,EAAE,kBAAkB,CAAC;CAC1C;AAED;;;;;;;;;;GAUG;AACH,eAAO,MAAM,kBAAkB,qBAE5B,gBAAgB,KAAQ,UAuBzB,CAAC"}
+{"version":3,"file":"cdk.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/cdk.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,EACnB,MAAM,WAAW,CAAC;AAEnB,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAGpD,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,GACnB,CAAC;AAEF,YAAY,EAAE,kBAAkB,EAAE,CAAC;AAEnC;;GAEG;AACH,UAAU,gBAAgB;IACxB,mFAAmF;IACnF,QAAQ,CAAC,UAAU,CAAC,EAAE,kBAAkB,CAAC;CAC1C;AAED;;;;;;;;;;GAUG;AACH,eAAO,MAAM,kBAAkB,GAAI,kBAEhC,gBAAqB,KAAG,UAuBzB,CAAC"}

package/dist/configs/vitest/nestjs.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"nestjs.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/nestjs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,EACnB,MAAM,WAAW,CAAC;AAEnB,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAGpD,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,GACnB,CAAC;AAEF,YAAY,EAAE,kBAAkB,EAAE,CAAC;AAEnC;;GAEG;AACH,UAAU,mBAAmB;IAC3B,mFAAmF;IACnF,QAAQ,CAAC,UAAU,CAAC,EAAE,kBAAkB,CAAC;CAC1C;AAwBD;;;;;;;;;GASG;AACH,eAAO,MAAM,qBAAqB,qBAE/B,mBAAmB,KAAQ,UAe5B,CAAC"}
+{"version":3,"file":"nestjs.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/nestjs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,EACnB,MAAM,WAAW,CAAC;AAEnB,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAGpD,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,GACnB,CAAC;AAEF,YAAY,EAAE,kBAAkB,EAAE,CAAC;AAEnC;;GAEG;AACH,UAAU,mBAAmB;IAC3B,mFAAmF;IACnF,QAAQ,CAAC,UAAU,CAAC,EAAE,kBAAkB,CAAC;CAC1C;AAwBD;;;;;;;;;GASG;AACH,eAAO,MAAM,qBAAqB,GAAI,kBAEnC,mBAAwB,KAAG,UAe5B,CAAC"}

package/dist/configs/vitest/typescript.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"typescript.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/typescript.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,EACnB,MAAM,WAAW,CAAC;AAEnB,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAGpD,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,GACnB,CAAC;AAEF,YAAY,EAAE,kBAAkB,EAAE,CAAC;AAEnC;;GAEG;AACH,UAAU,uBAAuB;IAC/B,mFAAmF;IACnF,QAAQ,CAAC,UAAU,CAAC,EAAE,kBAAkB,CAAC;CAC1C;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,yBAAyB,qBAEnC,uBAAuB,KAAQ,UAchC,CAAC"}
+{"version":3,"file":"typescript.d.ts","sourceRoot":"","sources":["../../../src/configs/vitest/typescript.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAEpD,8DAA8D;AAC9D,KAAK,UAAU,GAAG,cAAc,CAAC;AAEjC,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,EACnB,MAAM,WAAW,CAAC;AAEnB,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAGpD,OAAO,EACL,yBAAyB,EACzB,qBAAqB,EACrB,iBAAiB,EACjB,aAAa,EACb,eAAe,EACf,kBAAkB,GACnB,CAAC;AAEF,YAAY,EAAE,kBAAkB,EAAE,CAAC;AAEnC;;GAEG;AACH,UAAU,uBAAuB;IAC/B,mFAAmF;IACnF,QAAQ,CAAC,UAAU,CAAC,EAAE,kBAAkB,CAAC;CAC1C;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,yBAAyB,GAAI,kBAEvC,uBAA4B,KAAG,UAchC,CAAC"}

package/dist/utils/fibonacci.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"fibonacci.d.ts","sourceRoot":"","sources":["../../src/utils/fibonacci.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH;;;;;;;;;;;;;GAaG;AACH,wBAAiB,kBAAkB,IAAI,SAAS,CAAC,MAAM,EAAE,KAAK,EAAE,OAAO,CAAC,CASvE;AAED;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,SAAS,MAAO,MAAM,KAAG,MAYrC,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,iBAAiB,WAAY,MAAM,KAAG,SAAS,MAAM,EASjE,CAAC"}
+{"version":3,"file":"fibonacci.d.ts","sourceRoot":"","sources":["../../src/utils/fibonacci.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH;;;;;;;;;;;;;GAaG;AACH,wBAAiB,kBAAkB,IAAI,SAAS,CAAC,MAAM,EAAE,KAAK,EAAE,OAAO,CAAC,CASvE;AAED;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,SAAS,GAAI,GAAG,MAAM,KAAG,MAYrC,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,iBAAiB,GAAI,QAAQ,MAAM,KAAG,SAAS,MAAM,EASjE,CAAC"}

package/expo/copy-overwrite/tsconfig.expo.json

@@ -3,7 +3,6 @@
   "compilerOptions": {
     "strict": true,
     "jsx": "react-native",
-    "baseUrl": "./",
     "noEmit": true,
     "declaration": false,
     "allowImportingTsExtensions": true,

package/expo/copy-overwrite/tsconfig.json

@@ -1,6 +1,3 @@
 {
-  "extends": ["@codyswann/lisa/tsconfig/expo", "./tsconfig.local.json"],
-  "compilerOptions": {
-    "baseUrl": "./"
-  }
+  "extends": ["@codyswann/lisa/tsconfig/expo", "./tsconfig.local.json"]
 }

package/nestjs/copy-overwrite/tsconfig.json

@@ -1,6 +1,3 @@
 {
-  "extends": ["@codyswann/lisa/tsconfig/nestjs", "./tsconfig.local.json"],
-  "compilerOptions": {
-    "baseUrl": "./"
-  }
+  "extends": ["@codyswann/lisa/tsconfig/nestjs", "./tsconfig.local.json"]
 }

package/nestjs/copy-overwrite/tsconfig.nestjs.json

@@ -8,7 +8,6 @@
     "declaration": true,
     "sourceMap": true,
     "outDir": ".build",
-    "baseUrl": "./",
     "paths": {
       "@/*": ["./src/*"]
     }

package/package.json

@@ -78,7 +78,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.4.0",
+  "version": "2.5.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -162,7 +162,7 @@
     "eslint-plugin-react-compiler": "^19.1.0-rc.2",
     "eslint-plugin-react-hooks": "^7.0.0",
     "eslint-plugin-react-perf": "^3.3.0",
-    "eslint-plugin-sonarjs": "^3.0.0",
+    "eslint-plugin-sonarjs": "^4.0.3",
     "eslint-plugin-tailwindcss": "^3.18.0",
     "fs-extra": "^11.0.0",
     "globals": "^16.0.0",
@@ -181,7 +181,7 @@
     "ts-jest": "^29.4.9",
     "ts-morph": "^27.0.2",
     "tsx": "^4.0.0",
-    "typescript": "~5.7.0",
+    "typescript": "^6.0.3",
     "typescript-eslint": "^8.0.0",
     "vitest": "^4.1.0"
   },

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.4.0",
+  "version": "2.5.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/agents/linear-prd-intake.md

@@ -0,0 +1,64 @@
+---
+name: linear-prd-intake
+description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims `prd-ready` projects (relabels to `prd-in-review`), validates each through the dry-run pipeline, and routes to `prd-blocked` (with clarifying comments on a sentinel feedback issue) or `prd-ticketed` (with JIRA tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
+skills:
+  - linear-prd-intake
+  - linear-to-jira
+  - jira-validate-ticket
+  - jira-source-artifacts
+  - product-walkthrough
+  - jira-write-ticket
+  - prd-ticket-coverage
+---
+
+# PRD Intake Agent (Linear)
+
+You are a PRD intake agent. Your single job is to run one intake cycle against the Linear scope (a workspace or a team) given to you, then report what happened.
+
+This agent is the Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. The behavior is identical apart from the source-of-truth tool surface and one structural difference (clarifying comments land on a sentinel feedback issue under each project, not on the project page itself, because Linear's MCP doesn't expose project-level comments). If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent.
+
+## Confirmation policy
+
+Once you have a workspace or team scope, RUN. Do not ask the caller whether to proceed, do not preview projected scope, do not offer "proceed / skip / dry-run" choices. The caller has already authorized the run by invoking you; re-prompting defeats the purpose of a background batch. `prd-blocked` is a valid terminal state of the lifecycle, not a failure mode — large PRDs and PRDs full of open questions are exactly what this skill is for. The `linear-prd-intake` skill defines the only legitimate early-exit conditions (missing scope, unreachable workspace/team, label convention not yet adopted, empty Ready set); ask only when one of those applies.
+
+## Workflow
+
+### 1. Receive the scope URL or key
+
+The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Linear workspace URL, a team URL, a bare team key, or the literal token `linear` (which falls back to `LINEAR_WORKSPACE`). You do not pick the scope yourself.
+
+If no scope is provided, stop and ask. Never run intake against a default or guessed scope — the side effects (label changes, sentinel-issue creation, JIRA tickets created) are too high to act without an explicit target.
+
+### 2. Run the intake skill
+
+Invoke the `linear-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, sentinel feedback issue management, summary. Do not duplicate that logic here.
+
+Treat the skill's output as the source of truth. If it reports `prd-ticketed: 3 / prd-blocked: 1 / Errors: 0`, that's what you report.
+
+### 3. Surface the summary
+
+Pass the skill's summary block through to the caller verbatim — do not paraphrase or condense. The caller (often a human running `/linear-prd-intake` ad-hoc, or a scheduled cron) needs the structured record:
+
+- Total processed
+- Per-PRD outcomes (`prd-ticketed` → which tickets created; `prd-blocked` → how many gate failures; Errors → reason)
+- JIRA ticket count
+
+If the cycle errored before processing any PRDs (e.g. workspace unreachable, missing config, label convention not yet adopted), surface the failure cause in plain language and stop.
+
+### 4. Suggest next actions when warranted
+
+After a successful cycle, if any PRDs ended in `prd-blocked`, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the sentinel feedback issue (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
+
+When reporting `prd-blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in JIRA, but the PRD has uncovered requirements that the next intake cycle will address). Both result in `prd-blocked`, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
+
+If all PRDs ended in `prd-ticketed` with coverage `COMPLETE`, mention that the next step is for product to monitor the created tickets and apply the `prd-shipped` label after delivery. If any are `COMPLETE_WITH_SCOPE_CREEP`, point that out so product can review the flagged tickets.
+
+## Rules
+
+- **Never run a cycle without an explicit scope.** Side effects are too high to default.
+- **Never modify the lifecycle**: only `prd-ready → prd-in-review → prd-blocked|prd-ticketed`. Never touch `prd-draft` or `prd-shipped`. Never invent new labels.
+- **Never write JIRA tickets directly.** All writes go through the skill chain (intake → linear-to-jira → jira-write-ticket).
+- **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the sentinel feedback issue otherwise.
+- **Never close, archive, or repurpose the sentinel feedback issue.** It is reused across cycles; its longevity is the audit trail.
+- **Never start a second cycle while one is in flight against the same scope.** Serial execution; the scheduling layer is responsible for not double-firing.
+- **Stop and surface failures rather than retry-loop.** If `linear-to-jira` returns an error, the skill records it under `Errors` in the summary; pass that through.

package/plugins/lisa/commands/intake.md

@@ -1,6 +1,6 @@
 ---
-description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa:plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa:plan per item. JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
-argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | JIRA-project-key | JQL-filter>"
+description: "Vendor-agnostic batch scanner for Ready queues. Notion PRD database URL → finds Status=Ready PRDs and runs lisa:plan per item. Confluence space or parent-page URL → finds prd-ready PRDs and runs lisa:plan per item. Linear workspace or team URL → finds prd-ready Linear projects and runs lisa:plan per item. JIRA project key or JQL → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule."
+argument-hint: "<Notion-PRD-database-URL | Confluence-space-URL | Confluence-parent-page-URL | Linear-workspace-URL | Linear-team-URL | JIRA-project-key | JQL-filter>"
 ---
 
 Use the /lisa:intake skill to scan the queue for Ready items and dispatch each one through the appropriate single-item lifecycle skill. $ARGUMENTS

package/plugins/lisa/skills/intake/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: intake
-description: "Vendor-agnostic batch scanner for Ready queues. Given a Notion PRD database URL → finds Ready PRDs and runs lisa:plan per item. Given a Confluence space or parent page URL → finds prd-ready PRDs and runs lisa:plan per item. Given a JIRA project key or JQL filter → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule — one cycle per invocation, processes everything currently Ready, exits cleanly on empty. Symmetric counterpart to the single-item lisa:plan and lisa:implement skills."
-allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-search", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluenceSpaces", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getJiraIssue"]
+description: "Vendor-agnostic batch scanner for Ready queues. Given a Notion PRD database URL → finds Ready PRDs and runs lisa:plan per item. Given a Confluence space or parent page URL → finds prd-ready PRDs and runs lisa:plan per item. Given a Linear workspace URL or team key → finds prd-ready Linear projects and runs lisa:plan per item. Given a JIRA project key or JQL filter → finds Ready tickets and runs lisa:implement per item. Designed as the cron target for /schedule — one cycle per invocation, processes everything currently Ready, exits cleanly on empty. Symmetric counterpart to the single-item lisa:plan and lisa:implement skills."
+allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__claude_ai_Notion__notion-search", "mcp__atlassian__getConfluencePage", "mcp__atlassian__getConfluenceSpaces", "mcp__atlassian__searchConfluenceUsingCql", "mcp__atlassian__getAccessibleAtlassianResources", "mcp__atlassian__searchJiraIssuesUsingJql", "mcp__atlassian__getJiraIssue", "mcp__linear-server__list_projects", "mcp__linear-server__list_teams", "mcp__linear-server__list_project_labels"]
 ---
 
 # Intake: $ARGUMENTS
@@ -42,19 +42,24 @@ Detect the queue type from `$ARGUMENTS` and route:
 | A Notion **database** URL or database ID | PRD queue (Notion) | Invoke `lisa:notion-prd-intake` (which scans the DB for Status=Ready, claims each, runs `lisa:plan` per PRD via the dry-run validate → branch → write pipeline) |
 | A Confluence **space** URL or space key (e.g. `https://acme.atlassian.net/wiki/spaces/PRD` or `PRD`) | PRD queue (Confluence) | Invoke `lisa:confluence-prd-intake` (which CQL-queries the space for `label = "prd-ready"`, claims each by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline) |
 | A Confluence **parent page** URL or page ID (the page whose descendants are PRDs) | PRD queue (Confluence, narrowed) | Invoke `lisa:confluence-prd-intake` with the parent ID (CQL: `ancestor = <id> AND label = "prd-ready"`) |
+| A Linear **workspace** URL (e.g. `https://linear.app/acme`) | PRD queue (Linear) | Invoke `lisa:linear-prd-intake` (which queries `list_projects({label: "prd-ready"})` across the workspace, claims each by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline) |
+| A Linear **team** URL (e.g. `https://linear.app/acme/team/ENG/projects`) or a token already routed as a Linear team key | PRD queue (Linear, narrowed) | Invoke `lisa:linear-prd-intake` with the team key (`list_projects({team, label: "prd-ready"})`) |
+| The literal token `linear` | PRD queue (Linear, default workspace) | Invoke `lisa:linear-prd-intake linear` — only valid if `LINEAR_WORKSPACE` is configured |
 | A JIRA project key (e.g. `SE`) | Work queue (JIRA) | Invoke `lisa:jira-build-intake` (which scans the project for Status=Ready, claims each via In Progress, runs `lisa:implement` per ticket, transitions to On Dev on success) |
 | A full JQL filter (e.g. `project = SE AND component = "frontend"`) | Work queue (JIRA, narrowed) | Invoke `lisa:jira-build-intake` with the JQL |
-| A Linear / GitHub Issues queue | Not yet implemented | Stop and report — no `linear-tracker` or `github-tracker` adapter has been built. Don't fall back. |
+| A GitHub Issues queue | Not yet implemented | Stop and report — no `github-tracker` adapter has been built. Don't fall back. |
 
 Disambiguation rules:
 
 - A `notion.so` / `notion.site` URL → Notion queue.
 - An Atlassian Confluence URL containing `/wiki/spaces/<KEY>` with no `/pages/...` segment → Confluence space queue.
 - An Atlassian Confluence URL containing `/wiki/spaces/<KEY>/pages/<ID>/...` → Confluence parent-page queue (the page is the parent whose descendants are PRDs). If the user actually meant "this single page is a PRD, plan it", route to `lisa:plan` instead — this skill is batch-only.
-- A bare alphanumeric token that matches the configured `JIRA_PROJECT` regex (uppercase letters / digits / hyphen, ≤10 chars) is treated as a JIRA project key by default. A token that does not match the regex is treated as a Confluence space key. The only time to stop and ask is when the token matches the JIRA_PROJECT regex AND is also a confirmed reachable Confluence space key (verified via Atlassian API) — in that specific overlap the user must disambiguate which queue to scan.
+- A `linear.app` URL → Linear queue. If the path is `/<workspace>` only or `/<workspace>/team/<KEY>/...`, route here. If the path includes `/project/<slug>-<id>` it's a single-PRD URL — direct the caller to `lisa:plan` instead, this skill is batch-only.
+- The literal token `linear` (case-insensitive) → Linear queue, default workspace from `LINEAR_WORKSPACE`.
+- A bare alphanumeric token that matches the configured `JIRA_PROJECT` regex (uppercase letters / digits / hyphen, ≤10 chars) is treated as a JIRA project key by default. A token that does not match the regex is treated as a Confluence space key. If it does not resolve as a Confluence space key either, attempt to resolve as a Linear team key via `mcp__linear-server__list_teams({query})` before giving up. The only time to stop and ask is when the token resolves to more than one of {JIRA project, Confluence space, Linear team} simultaneously — in that overlap the user must disambiguate which queue to scan.
 - A string starting with `project = ` or containing JQL operators (`AND`, `OR`, `=`, `!=`, `~`, etc.) → JQL filter.
 
-The single-item skills (`lisa:plan`, `lisa:implement`) and the per-vendor batch skills (`lisa:notion-prd-intake`, `lisa:confluence-prd-intake`, `lisa:jira-build-intake`) are internal — Intake is the public entry point. Developers schedule `/lisa:intake <queue>`; the rest is composition.
+The single-item skills (`lisa:plan`, `lisa:implement`) and the per-vendor batch skills (`lisa:notion-prd-intake`, `lisa:confluence-prd-intake`, `lisa:linear-prd-intake`, `lisa:jira-build-intake`) are internal — Intake is the public entry point. Developers schedule `/lisa:intake <queue>`; the rest is composition.
 
 ## Cycle behavior
 
@@ -64,6 +69,7 @@ The single-item skills (`lisa:plan`, `lisa:implement`) and the per-vendor batch
 4. **Process each Ready item serially** (claim-first ordering for idempotency):
    - Notion PRDs → `lisa:notion-prd-intake` handles per-item: claim (Status=In Review), dry-run validate, branch to Blocked or Ticketed, coverage audit
    - Confluence PRDs → `lisa:confluence-prd-intake` handles per-item: claim (relabel to `prd-in-review`), dry-run validate, branch to `prd-blocked` or `prd-ticketed`, coverage audit
+   - Linear PRDs → `lisa:linear-prd-intake` handles per-item: claim (relabel project to `prd-in-review`), dry-run validate, branch to `prd-blocked` or `prd-ticketed` (with a sentinel feedback issue under each project hosting clarifying-question comments), coverage audit
    - JIRA tickets → `lisa:jira-build-intake` handles per-item: claim, dispatch to `lisa:jira-agent`, transition to On Dev on success
 5. **Failure isolation** — one item failing does not stop the cycle; record under "Errors" and continue.
 6. **Summary report** — per-item outcomes, total processed, total errors.
@@ -73,6 +79,8 @@ The single-item skills (`lisa:plan`, `lisa:implement`) and the per-vendor batch
 ```text
 /schedule "every 30 minutes" /lisa:intake https://www.notion.so/<workspace>/<database-id>
 /schedule "every 30 minutes" /lisa:intake https://acme.atlassian.net/wiki/spaces/PRD
+/schedule "every 30 minutes" /lisa:intake https://linear.app/acme
+/schedule "every 30 minutes" /lisa:intake https://linear.app/acme/team/ENG/projects
 /schedule "every 30 minutes" /lisa:intake SE
 /schedule "every hour" /lisa:intake "project = SE AND component = 'frontend'"
 ```

package/plugins/lisa/skills/linear-prd-intake/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: linear-prd-intake
+description: "Scans a Linear workspace (or a specific team) for projects labelled `prd-ready` and runs each one through the dry-run validation pipeline. Projects that pass every gate get tickets written and the label flipped to `prd-ticketed`; projects that fail get clarifying-question comments (on a sentinel feedback issue under the project) and the label flipped to `prd-blocked`. Linear counterpart of `lisa:notion-prd-intake` and `lisa:confluence-prd-intake` — the workflow is identical; only the source-of-truth tools differ. Composes existing skills (linear-to-jira, jira-validate-ticket, jira-source-artifacts, product-walkthrough)."
+allowed-tools: ["Skill", "Bash", "mcp__linear-server__list_projects", "mcp__linear-server__get_project", "mcp__linear-server__save_project", "mcp__linear-server__list_project_labels", "mcp__linear-server__list_issues", "mcp__linear-server__get_issue", "mcp__linear-server__save_issue", "mcp__linear-server__list_comments", "mcp__linear-server__save_comment", "mcp__linear-server__list_issue_labels", "mcp__linear-server__create_issue_label", "mcp__linear-server__list_documents", "mcp__linear-server__get_document", "mcp__linear-server__list_teams"]
+---
+
+# Linear PRD Intake: $ARGUMENTS
+
+`$ARGUMENTS` is one of:
+
+- A Linear **workspace** URL — scans every project in the workspace whose labels include `prd-ready`. Example: `https://linear.app/acme`.
+- A Linear **team** URL or team key — scans every project on the team whose labels include `prd-ready`. Example: `https://linear.app/acme/team/ENG/projects` or bare `ENG`.
+- The literal token `linear` — equivalent to "the default Linear workspace"; only valid if `LINEAR_WORKSPACE` is configured.
+
+Run one intake cycle against that scope. Each project with the `prd-ready` label is claimed, validated, and routed to either `prd-blocked` (with clarifying comments on a sentinel feedback issue) or `prd-ticketed` (with JIRA tickets created).
+
+This skill is the Linear counterpart of `lisa:notion-prd-intake` and `lisa:confluence-prd-intake`. The phases, gates, comment templates, and rules are identical — the only differences are (1) the lifecycle is encoded as **project labels** instead of a Status property, (2) the fetch / update tools are Linear MCP, and (3) clarifying-question comments land on a sentinel feedback Issue under the project (because Linear's MCP does not expose project-level comments). Keep all three skills behaviorally aligned: when changing intake logic, change them together.
+
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a workspace/team scope, run the cycle to completion — claim, validate, branch to `prd-blocked` or `prd-ticketed`, write the summary. The caller (a human or a cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
+
+Specifically forbidden:
+
+- Previewing projected scope (epic count, story count, write count) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip / dry-run only" — the documented behavior IS the default.
+- Pausing because a PRD looks large, has many open questions, or is likely to end in `prd-blocked`. `prd-blocked` is a valid terminal state of this lifecycle, not a failure mode — routing a PRD to `prd-blocked` with gate-failure comments is exactly how this skill communicates "the PRD needs more work before it can be ticketed." That outcome is success.
+- Pausing because the dry-run validation looks expensive. The cost of one cycle is bounded; the cost of stalling a scheduled cron waiting on a human is unbounded.
+
+The only legitimate reasons to stop early:
+
+- Missing scope argument or required configuration (`JIRA_PROJECT`, `JIRA_SERVER`, `LINEAR_WORKSPACE`, `E2E_BASE_URL`, etc.). Surface the missing key(s) and exit this cycle — never invent values.
+- Workspace/team unreachable, or the labelling convention not yet adopted (no projects carry any of `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed`). Surface and exit.
+- Empty `prd-ready` set. Exit cleanly with `"No Linear projects labelled prd-ready. Nothing to do."`
+
+## Lifecycle assumed
+
+The Linear PRD lifecycle is encoded as **project labels** (we deliberately do NOT key off Linear's native project state, since project state is product's day-to-day signal and we don't want to fight it). Exactly one of these labels is expected on a project at any time:
+
+```text
+prd-draft → prd-ready → prd-in-review → prd-blocked | prd-ticketed → prd-shipped
+            (product)    (us)            (us)                          (product)
+```
+
+This skill ONLY transitions:
+
+- `prd-ready` → `prd-in-review` (claim)
+- `prd-in-review` → `prd-blocked` (gate failures or coverage gaps)
+- `prd-in-review` → `prd-ticketed` (success)
+- `prd-ticketed` → `prd-blocked` (post-write coverage gaps from Phase 3e)
+
+It never adds, removes, or touches `prd-draft` or `prd-shipped`. Those labels are owned by product.
+
+A "transition" means: remove the old lifecycle label and add the new one in a single `save_project` call (passing the full new label set in the `labels` array). The skill MUST verify that exactly one lifecycle label exists on the project after the update — having two simultaneously breaks idempotency.
+
+If the project does not yet use `prd-*` labels, this skill cannot run. Adopting the convention is a one-time setup the project owner does (see "Adoption" at the bottom of this file).
+
+## Phases
+
+### Phase 1 — Resolve the scope
+
+1. Parse `$ARGUMENTS`:
+   - Workspace URL (`https://linear.app/<workspace>`) → extract workspace slug; the scope is the entire workspace.
+   - Team URL containing `/team/<KEY>/...` → extract team key; the scope is that team.
+   - Bare team key → use as-is; the scope is that team.
+   - The literal `linear` → fall back to `LINEAR_WORKSPACE` env var; error if not set.
+2. Verify the scope is reachable:
+   - For a workspace: call `mcp__linear-server__list_teams` and confirm at least one team is returned (non-empty workspaces are readable; empty results indicate auth or workspace-mismatch).
+   - For a team: call `mcp__linear-server__list_teams({query: <KEY>})` and confirm the team resolves.
+3. Resolve the project-label IDs for `prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed` via `mcp__linear-server__list_project_labels`. Cache them — every transition uses these IDs. If any of the four are missing, surface a label-convention error and exit (see "Adoption").
+
+### Phase 2 — Find Ready PRDs
+
+Call `mcp__linear-server__list_projects({label: "prd-ready", ...scope-filter})`:
+
+- For a workspace scope: pass `label: "prd-ready"` only.
+- For a team scope: pass `label: "prd-ready"` AND `team: "<KEY>"`.
+
+The query returns the list of candidate projects with IDs, names, and label sets. For each candidate, confirm that exactly one lifecycle label is present (the API filter is `prd-ready`, but a project could have ended up with two labels by hand — that's a misconfiguration, not a normal queue entry).
+
+If the result set is empty, run a secondary query to distinguish between a genuinely empty queue and a workspace/team that has not yet adopted the label convention:
+
+- Secondary query: `list_projects({...scope-filter})` with no label filter, then in-process check whether any returned project carries any of `prd-ready` / `prd-in-review` / `prd-blocked` / `prd-ticketed`.
+
+If the secondary query shows zero projects carrying any `prd-*` label → the convention has not been adopted. Surface a misconfiguration message: `"No Linear projects in this scope carry prd-* labels. If this is a new project, apply the prd-ready label to projects that are ready for ticketing (see Adoption section)."` Exit with an error — this is a setup issue, not a normal idle cycle.
+
+If the secondary query shows projects with other `prd-*` labels but none with `prd-ready` → the queue is genuinely empty (all PRDs are already in-review, blocked, ticketed, or shipped). Exit cleanly with `"No Linear projects labelled prd-ready. Nothing to do."`
+
+### Phase 3 — Process each Ready PRD
+
+For each project (process serially to keep label transitions auditable):
+
+#### 3a. Claim
+
+Transition labels via `mcp__linear-server__save_project({id, labels})`: pass the full new label set with `prd-ready` removed and `prd-in-review` added. This is the idempotency lock — a re-entrant cycle running concurrently won't see this project because its query filters on `label: "prd-ready"`.
+
+If the update fails (permission error, race condition), log it and skip this project. Do not proceed to validation on a project you didn't successfully claim.
+
+The `save_project` call must preserve all other project fields (description, state, priority, lead, dates, teams, initiatives) untouched — pass only `id` and the new `labels` array. This skill never edits PRD body content.
+
+#### 3b. Dry-run validation
+
+Invoke the `lisa:linear-to-jira` skill with `dry_run: true` and the project's URL. The skill returns a structured report containing:
+- The planned ticket hierarchy
+- Per-ticket validation verdicts and remediation
+- An overall PASS / FAIL verdict
+- A failure count
+
+This call also indirectly invokes `lisa:jira-source-artifacts` (artifact extraction + classification) and `lisa:product-walkthrough` (when the PRD touches existing user-facing surfaces). All gate logic lives in `lisa:jira-validate-ticket`, which `lisa:linear-to-jira` calls per ticket.
+
+#### 3c. Branch on the verdict
+
+**If `PASS`** (every planned ticket passed every applicable gate):
+
+1. Re-invoke `lisa:linear-to-jira` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
+2. Capture the created ticket keys from the skill's output.
+3. Ensure the project has a sentinel feedback issue (see "Sentinel feedback issue" below for the helper). Post a comment on it via `mcp__linear-server__save_comment` listing the created tickets (epic, stories, sub-tasks) with their JIRA URLs. Lead with: `"Ticketed by Claude. Created N JIRA issues — see below. Add the prd-shipped label to the Linear project after the work is delivered."`
+4. Transition labels: remove `prd-in-review`, add `prd-ticketed` via `save_project`.
+5. **Run Phase 3e (coverage audit)** before considering this PRD done.
+
+**If `FAIL`** (one or more planned tickets failed one or more gates):
+
+The audience for these comments is the **product team**, not engineers. They are not familiar with JIRA gate IDs, validator vocabulary, or skill internals. Follow the rules below strictly — the goal is for a non-engineer product owner to read a comment, understand what is unclear, and know what to do next.
+
+##### 3c.1 Partition failures
+
+1. Drop every failure where `product_relevant = false`. Those are internal data-quality problems — the agent should fix its own spec rather than ask product to clarify a missing core field. Record the dropped failures under `Errors` in the cycle summary so engineers can see them; never surface them on the PRD.
+2. Group the remaining product-relevant failures by `prd_anchor` (which, for Linear, is a sub-issue identifier when the failure traces to a specific issue, or `null` otherwise). Failures that share an anchor become one comment thread on that issue. Failures with `prd_anchor: null` are batched into one comment on the sentinel feedback issue, since they have no source sub-issue to attach to.
+
+##### 3c.2 Render each comment
+
+Ensure the project has a sentinel feedback issue (see helper below). For each anchored group (`prd_anchor` is a sub-issue identifier), post a comment on THAT sub-issue via `mcp__linear-server__save_comment({issueId: <prd_anchor>, body: <template>})`. For the unanchored group, post a single comment on the sentinel feedback issue using the same template, prefixed with `Issues without a specific sub-issue anchor:` and one block per failure.
+
+If `save_comment` fails for a specific anchored sub-issue (the issue was deleted between fetch and post, or the agent lacks comment permission), fall back to the sentinel feedback issue for that group. Do not silently drop the failure.
+
+##### 3c.3 Comment template
+
+Each comment body MUST contain these four parts, in this order, no exceptions:
+
+```text
+[<Category badge>] <prd_section heading text>
+
+**What's unclear:** <validator's `what` field, verbatim — already product-readable>
+
+**Recommendation:** <validator's `recommendation` field, verbatim — must contain 1–3 concrete options, never a generic "please clarify">
+
+**Action:** Update this section in the PRD, then replace the `prd-blocked` label with `prd-ready` on the Linear project and Claude will re-run intake.
+```
+
+If multiple failures share an anchor, render each as its own `**What's unclear:** ... **Recommendation:** ...` block within the same comment, separated by horizontal lines (`---`). Keep the single `[Category badge]` heading at the top using the most-severe / most-blocking category from the group.
+
+##### 3c.4 Category badges
+
+Use these exact badge labels — they are the validator's category values translated for product readers:
+
+| Validator category | Badge label |
+|---------------------|-------------|
+| `product-clarity` | `[Product clarity]` |
+| `acceptance-criteria` | `[Acceptance criteria]` |
+| `design-ux` | `[Design / UX]` |
+| `scope` | `[Scope]` |
+| `dependency` | `[Dependency]` |
+| `data` | `[Data]` |
+| `technical` | `[Technical]` |
+
+`structural` failures must never reach this step (filtered in 3c.1). If you see one here, treat it as an Error and surface internally.
+
+##### 3c.5 Forbidden in product comments
+
+- Gate IDs (`S4`, `F2`, etc.). Never appear in a comment body.
+- JIRA terminology that has no product meaning (e.g. "Gherkin", "epic parent", "issue link", "validation journey", "sub-task hierarchy"). Paraphrase before posting.
+- Internal skill names (`lisa:jira-validate-ticket`, `linear-to-jira`).
+- Engineering shorthand (`AC`, `OOS`, `repo`, `env var`).
+- "Clarify this" / "Please specify" without candidate resolutions. The validator is required to provide candidates; if `recommendation` is empty or vague, treat the failure as an Error and surface internally rather than posting a useless comment.
+
+##### 3c.6 Label transition
+
+After all comments are posted (anchored groups + the optional sentinel-issue summary), transition labels: remove `prd-in-review`, add `prd-blocked` via `save_project`. Do NOT write any JIRA tickets.
+
+#### 3d. Continue
+
+Move to the next Ready PRD. One PRD failing does not affect others.
+
+#### 3e. Coverage audit (mandatory after prd-ticketed)
+
+Per-ticket gates prove each ticket is well-formed; they do NOT prove the *set* of created tickets covers the *whole* PRD. Silent drops happen — invoke the `lisa:prd-ticket-coverage` skill to catch them.
+
+1. Invoke `lisa:prd-ticket-coverage` with `<PRD URL> tickets=[<created ticket keys from 3c step 2>]`. The coverage skill auto-detects the PRD vendor from the URL.
+2. Read the verdict:
+
+   | Verdict | Action |
+   |---------|--------|
+   | `COMPLETE` | Done. Leave label as `prd-ticketed`. Move to next PRD. |
+   | `COMPLETE_WITH_SCOPE_CREEP` | Post an advisory comment on the sentinel feedback issue naming the scope-creep tickets (so product can decide whether to close them as out-of-scope). Leave label as `prd-ticketed`. |
+   | `GAPS_FOUND` | The created ticket set is incomplete. (a) For each gap, post a comment using the same product-facing template as Phase 3c.3 — anchored on the relevant sub-issue when `prd_anchor` is non-null, on the sentinel feedback issue otherwise; category badge from the gap's `category` field; `What's unclear` and `Recommendation` from the audit report's `what` and `recommendation` fields. Apply the same forbidden-language rules from Phase 3c.5. (b) Post one summary comment on the sentinel feedback issue listing the tickets that *were* successfully created (so product knows what to keep vs. what to extend). (c) Transition labels from `prd-ticketed` back to `prd-blocked` via `save_project`. |
+   | `NO_TICKETS_FOUND` | Should not happen if step 2 succeeded. If it does, log it as an Error in the cycle summary and leave label as `prd-ticketed` with a comment flagging the audit failure for human review. |
+
+3. The created tickets remain in JIRA regardless of the verdict — they are valid in their own right. The audit only tells us whether *more* are needed.
+
+### Phase 4 — Summary report
+
+After processing every Ready PRD, emit a summary:
+
+```text
+## linear-prd-intake summary
+
+Scope: <workspace-slug | team-key> (<URL>)
+Cycle started: <ISO timestamp>
+Cycle completed: <ISO timestamp>
+
+PRDs processed: <n>
+- prd-ticketed: <n>
+  - <project name> → <epic-key> + <story-count> stories + <subtask-count> sub-tasks (coverage: COMPLETE | COMPLETE_WITH_SCOPE_CREEP)
+- prd-blocked: <n>
+  - <project name> → <gate-failure-count> gate failures (pre-write) OR <gap-count> coverage gaps (post-write)
+- Errors (claim failed, etc): <n>
+  - <project name> — <reason>
+
+Total JIRA tickets created: <n>
+Coverage audit summary: <n> COMPLETE / <n> COMPLETE_WITH_SCOPE_CREEP / <n> GAPS_FOUND
+```
+
+Print to the agent's output. Do not write this summary to Linear or JIRA — it's an operational record for the human.
+
+## Sentinel feedback issue
+
+Linear's MCP does not expose project-level comments. To preserve the comment-based feedback channel that Notion and Confluence intake have natively, this skill maintains a single sentinel **feedback Issue** under each project. All clarifying-question comments that don't anchor to a specific sub-issue land here.
+
+The sentinel issue is identified by:
+
+- A stable title: `"PRD intake: clarifying questions"`
+- A stable label: `prd-intake-feedback` (issue-level label, distinct from the project-level `prd-*` labels)
+- Membership in the project being processed
+
+Helper behavior — call this **before** posting any clarifying-question comment in Phase 3c or 3e:
+
+1. Search for an existing feedback issue: `list_issues({project: <id>, label: "prd-intake-feedback"})`. If multiple match (shouldn't happen, but defensive), use the oldest by `createdAt`.
+2. If none exists: ensure the `prd-intake-feedback` label exists on the project's team via `list_issue_labels` then `create_issue_label` if needed; then create the sentinel via `save_issue({team: <team-id>, project: <id>, title: "PRD intake: clarifying questions", description: "Auto-created by lisa:linear-prd-intake. This issue collects clarifying-question comments that don't anchor to a specific sub-issue. Do not close manually — it is reused across intake cycles.", labels: ["prd-intake-feedback"]})`. Capture the new issue identifier.
+3. Return the issue identifier to the caller for use in `save_comment({issueId: <id>, body: ...})`.
+
+Idempotency: the helper finds-or-creates. Re-runs of the cycle reuse the same sentinel issue. Comments accumulate; product reads top-down to see the latest cycle's findings. Do not delete or repurpose old comments — history is the audit trail.
+
+## Idempotency & safety
+
+- **Single-cycle scope**: this skill processes the `prd-ready` set as it exists at the start of Phase 2. New `prd-ready` projects added mid-cycle are picked up next run.
+- **No writes outside the lifecycle**: this skill only ever writes to JIRA via `lisa:linear-to-jira` (which delegates to `lisa:jira-write-ticket`), only ever changes Linear project labels among `prd-in-review`, `prd-blocked`, `prd-ticketed`, only ever creates/comments on the sentinel feedback issue (never any other Linear issue). It never edits project descriptions, never edits Linear documents, never touches `prd-draft` or `prd-shipped`, never archives or deletes projects.
+- **Claim-first ordering**: the label flip to `prd-in-review` happens BEFORE validation runs, so a re-entrant call won't double-process.
+- **Failure isolation**: an exception processing one project must not stop the cycle. Catch, record under "Errors" in the summary, continue to the next project. The project that errored is left labelled `prd-in-review` — the human investigates from there.
+- **Single-label invariant**: after every transition, verify exactly one lifecycle label is present on the project. If two are present (rare race), surface as an Error and skip — do NOT auto-resolve, the human decides.
+
+## Configuration
+
+Same env vars as `lisa:linear-to-jira` — `JIRA_PROJECT`, `JIRA_SERVER`, `LINEAR_WORKSPACE`, `E2E_BASE_URL`, `E2E_TEST_PHONE`, `E2E_TEST_OTP`, `E2E_TEST_ORG`, `E2E_GRAPHQL_URL`. If any required value is missing, surface the missing key(s) and exit this cycle — never invent values.
+
+## Rules
+
+- Never write to JIRA outside of `lisa:linear-to-jira` → `lisa:jira-write-ticket`. The validator's verdict gates progress; bypassing it produces broken tickets.
+- Never add or remove a label this skill doesn't own (`prd-in-review`, `prd-blocked`, `prd-ticketed`). Product owns `prd-draft`, `prd-ready`, `prd-shipped`. The issue-level `prd-intake-feedback` label is owned by this skill but is not a lifecycle label.
+- Never edit a project's description or any attached Linear document. Communication with product happens only through comments on sub-issues or on the sentinel feedback issue.
+- Never post a single dump of all gate failures on one comment. One comment per `prd_anchor` group on the relevant sub-issue (or one comment on the sentinel feedback issue for unanchored failures only). Comments must be sub-issue-anchored where possible, categorized, plain-language, and contain a concrete recommendation.
+- Never include a gate ID, internal skill name, or engineering shorthand in a comment body.
+- Never run more than one intake cycle concurrently against the same scope. This skill assumes serial execution.
+- Never close, archive, or otherwise modify the sentinel feedback issue except to post comments on it. Its longevity is the audit trail.
+- If `lisa:linear-to-jira` returns errors, treat them as gate failures: comment + `prd-blocked`. Don't silently fail.
+
+## Adoption (one-time per project)
+
+Before this skill can run against a Linear workspace or team, the team must adopt the `prd-*` project-label convention:
+
+1. Apply `prd-ready` to projects that are ready for ticketing (replaces the Notion `Status = Ready` flip and the Confluence `prd-ready` page label).
+2. Reserve `prd-in-review`, `prd-blocked`, `prd-ticketed` for this skill — humans should not set them manually except to recover from an error.
+3. (Optional but recommended) Add `prd-draft` for in-progress PRDs and `prd-shipped` for delivered work, so the full lifecycle is visible at a glance.
+4. The labels must exist as **project labels** in Linear (`list_project_labels` should return them). Issue-level labels with the same names won't work; Linear keeps the two label kinds separate.
+
+If the workspace hasn't adopted these labels, the first run exits with a label-convention error (not the idle empty-set message) — this distinguishes a setup issue from a genuinely empty queue so operators know to apply the convention rather than assuming the queue is drained. See Phase 2 for how the skill detects this case.