@codyswann/lisa 2.1.1 → 2.2.0

package/package.json

@@ -78,7 +78,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

package/plugins/lisa/agents/jira-build-intake.md

@@ -17,6 +17,10 @@ skills:
 
 You are a JIRA build-intake agent. Your single job is to run one cycle against a JIRA project / JQL filter — find Ready tickets, dispatch each through the build flow, transition successful builds to On Dev — then report what happened.
 
+## Confirmation policy
+
+Once you have a project key or JQL, RUN. Do not ask the caller whether to proceed, do not preview projected scope (ticket counts, PR counts, build estimates), 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. The pre-flight `Blocked` outcome owned by `jira-agent` is a valid terminal state of the per-ticket lifecycle, not a failure mode — large queues and complex tickets are exactly what this skill is for. The `jira-build-intake` skill defines the only legitimate early-exit conditions (missing query, misconfigured workflow, empty Ready set); ask only when one of those applies.
+
 ## Workflow
 
 ### 1. Receive the query

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

@@ -15,6 +15,10 @@ skills:
 
 You are a PRD intake agent. Your single job is to run one intake cycle against the Notion PRD database whose URL is given to you, then report what happened.
 
+## Confirmation policy
+
+Once you have a database URL, 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. `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 `notion-prd-intake` skill defines the only legitimate early-exit conditions (missing URL, misconfigured database, empty Ready set); ask only when one of those applies.
+
 ## Workflow
 
 ### 1. Receive the database URL

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

@@ -8,6 +8,23 @@ allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__cl
 
 Run one batch-intake cycle against the queue identified by `$ARGUMENTS`. Scans for `Status = Ready`, claims each item, and dispatches to the appropriate single-item lifecycle skill.
 
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a queue, run the cycle to completion. The caller (a human at the CLI or a scheduled cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
+
+Specifically forbidden:
+
+- Previewing projected scope (number of items, projected ticket counts, write counts) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip / dry-run only" — the documented behavior IS the default. Dry-run is a different skill, not an option here.
+- Pausing because the queue is large, items have many open questions, or items are likely to end in `Blocked`. `Blocked` is a valid terminal state of the downstream lifecycles, not a failure mode — routing items to `Blocked` with clarifying comments is success.
+- Pausing because 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 required input (no queue argument, missing project configuration). Surface the missing value and exit.
+- The queue itself is misconfigured (Status property missing expected values, JIRA workflow can't reach required transitions). Surface and exit.
+- Empty `Ready` set. Exit cleanly with the idle-case message.
+
 ## Orchestration: agent team
 
 If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.

package/plugins/lisa/skills/jira-build-intake/SKILL.md

@@ -13,6 +13,23 @@ allowed-tools: ["Skill", "Bash", "mcp__atlassian__getAccessibleAtlassianResource
 
 Run one build-intake cycle. Each Ready ticket is claimed, built via the `lisa:jira-agent` flow, and transitioned to `On Dev` (or the equivalent next-status for that project). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip `Ready`, agents pick up and progress.
 
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a project key or JQL, run the cycle to completion — claim, dispatch each ticket through `lisa:jira-agent`, transition successful builds to `On Dev`, 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 (ticket count, projected PR count, build duration) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip a few / dry-run only" — the documented behavior IS the default.
+- Pausing because the queue is large, tickets look complex, or tickets are likely to be `Blocked` by `lisa:jira-agent`'s pre-flight gate. The pre-flight `Blocked` outcome is a valid terminal state of the per-ticket lifecycle (owned by `lisa:jira-agent`), not a failure mode — surfacing those tickets to humans is success.
+- Pausing because the build flow 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 project key / JQL or required configuration. Surface the missing value and exit.
+- Workflow misconfigured (pre-flight check finds `In Progress` or `On Dev` not reachable, or `Ready` status absent). Surface and exit.
+- Empty `Ready` set. Exit cleanly with `"No tickets with Status=Ready. Nothing to do."`
+
 ## Lifecycle assumed
 
 The JIRA workflow has these statuses (or equivalents — see Configuration for renaming):

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

@@ -14,6 +14,23 @@ https://www.notion.so/geminisports/28fd00244d7d47c5866876f7de48c0fe?v=34eba63a28
 
 Run one intake cycle against that database. Each PRD with `Status = Ready` is claimed, validated, and routed to either `Blocked` (with clarifying comments) or `Ticketed` (with JIRA tickets created).
 
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a database URL, run the cycle to completion — claim, validate, branch to `Blocked` or `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 `Blocked`. `Blocked` is a valid terminal state of this lifecycle, not a failure mode — routing a PRD to `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 database URL or required configuration (`JIRA_PROJECT`, `JIRA_SERVER`, `E2E_BASE_URL`, etc.). Surface the missing value and exit.
+- Database misconfigured (Status property missing expected values, data source unreachable). Surface and exit.
+- Empty `Ready` set. Exit cleanly with `"No PRDs with Status=Ready. Nothing to do."`
+
 ## Lifecycle assumed
 
 The PRD database has a `Status` property whose value drives this skill:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.1.1",
+  "version": "2.2.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/jira-build-intake.md

@@ -17,6 +17,10 @@ skills:
 
 You are a JIRA build-intake agent. Your single job is to run one cycle against a JIRA project / JQL filter — find Ready tickets, dispatch each through the build flow, transition successful builds to On Dev — then report what happened.
 
+## Confirmation policy
+
+Once you have a project key or JQL, RUN. Do not ask the caller whether to proceed, do not preview projected scope (ticket counts, PR counts, build estimates), 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. The pre-flight `Blocked` outcome owned by `jira-agent` is a valid terminal state of the per-ticket lifecycle, not a failure mode — large queues and complex tickets are exactly what this skill is for. The `jira-build-intake` skill defines the only legitimate early-exit conditions (missing query, misconfigured workflow, empty Ready set); ask only when one of those applies.
+
 ## Workflow
 
 ### 1. Receive the query

package/plugins/src/base/agents/notion-prd-intake.md

@@ -15,6 +15,10 @@ skills:
 
 You are a PRD intake agent. Your single job is to run one intake cycle against the Notion PRD database whose URL is given to you, then report what happened.
 
+## Confirmation policy
+
+Once you have a database URL, 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. `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 `notion-prd-intake` skill defines the only legitimate early-exit conditions (missing URL, misconfigured database, empty Ready set); ask only when one of those applies.
+
 ## Workflow
 
 ### 1. Receive the database URL

package/plugins/src/base/skills/intake/SKILL.md

@@ -8,6 +8,23 @@ allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__cl
 
 Run one batch-intake cycle against the queue identified by `$ARGUMENTS`. Scans for `Status = Ready`, claims each item, and dispatches to the appropriate single-item lifecycle skill.
 
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a queue, run the cycle to completion. The caller (a human at the CLI or a scheduled cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
+
+Specifically forbidden:
+
+- Previewing projected scope (number of items, projected ticket counts, write counts) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip / dry-run only" — the documented behavior IS the default. Dry-run is a different skill, not an option here.
+- Pausing because the queue is large, items have many open questions, or items are likely to end in `Blocked`. `Blocked` is a valid terminal state of the downstream lifecycles, not a failure mode — routing items to `Blocked` with clarifying comments is success.
+- Pausing because 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 required input (no queue argument, missing project configuration). Surface the missing value and exit.
+- The queue itself is misconfigured (Status property missing expected values, JIRA workflow can't reach required transitions). Surface and exit.
+- Empty `Ready` set. Exit cleanly with the idle-case message.
+
 ## Orchestration: agent team
 
 If you are NOT already operating inside an agent team (no prior `TeamCreate` in this session, not spawned via `Agent` with `team_name`), your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.

package/plugins/src/base/skills/jira-build-intake/SKILL.md

@@ -13,6 +13,23 @@ allowed-tools: ["Skill", "Bash", "mcp__atlassian__getAccessibleAtlassianResource
 
 Run one build-intake cycle. Each Ready ticket is claimed, built via the `lisa:jira-agent` flow, and transitioned to `On Dev` (or the equivalent next-status for that project). The cycle is the symmetric mirror of `lisa:notion-prd-intake`: humans flip `Ready`, agents pick up and progress.
 
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a project key or JQL, run the cycle to completion — claim, dispatch each ticket through `lisa:jira-agent`, transition successful builds to `On Dev`, 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 (ticket count, projected PR count, build duration) and asking whether to continue.
+- Offering A/B/C-style choices like "proceed / skip a few / dry-run only" — the documented behavior IS the default.
+- Pausing because the queue is large, tickets look complex, or tickets are likely to be `Blocked` by `lisa:jira-agent`'s pre-flight gate. The pre-flight `Blocked` outcome is a valid terminal state of the per-ticket lifecycle (owned by `lisa:jira-agent`), not a failure mode — surfacing those tickets to humans is success.
+- Pausing because the build flow 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 project key / JQL or required configuration. Surface the missing value and exit.
+- Workflow misconfigured (pre-flight check finds `In Progress` or `On Dev` not reachable, or `Ready` status absent). Surface and exit.
+- Empty `Ready` set. Exit cleanly with `"No tickets with Status=Ready. Nothing to do."`
+
 ## Lifecycle assumed
 
 The JIRA workflow has these statuses (or equivalents — see Configuration for renaming):

package/plugins/src/base/skills/notion-prd-intake/SKILL.md

@@ -14,6 +14,23 @@ https://www.notion.so/geminisports/28fd00244d7d47c5866876f7de48c0fe?v=34eba63a28
 
 Run one intake cycle against that database. Each PRD with `Status = Ready` is claimed, validated, and routed to either `Blocked` (with clarifying comments) or `Ticketed` (with JIRA tickets created).
 
+## Confirmation policy
+
+Do NOT ask the caller whether to proceed. Once invoked with a database URL, run the cycle to completion — claim, validate, branch to `Blocked` or `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 `Blocked`. `Blocked` is a valid terminal state of this lifecycle, not a failure mode — routing a PRD to `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 database URL or required configuration (`JIRA_PROJECT`, `JIRA_SERVER`, `E2E_BASE_URL`, etc.). Surface the missing value and exit.
+- Database misconfigured (Status property missing expected values, data source unreachable). Surface and exit.
+- Empty `Ready` set. Exit cleanly with `"No PRDs with Status=Ready. Nothing to do."`
+
 ## Lifecycle assumed
 
 The PRD database has a `Status` property whose value drives this skill: