lisa-intake

name	lisa-intake
description	Vendor-agnostic scanner for…
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"]

Intake: $ARGUMENTS

Run one intake cycle against the queue identified by $ARGUMENTS. Scans for Status = Ready, claims the first eligible item, dispatches it to the appropriate single-item lifecycle skill, then exits. Remaining Ready items are left for later scheduler invocations.

For build-queue runs, Intake also accepts an optional assignee=<vendor-user-id-or-login> filter. Resolution order is:

1. $ARGUMENTS assignee=<...>
2. .lisa.config.local.json intake.assignee
3. empty default

When the resolved assignee is empty, Intake keeps the shared queue behavior and scans any ready item. When non-empty, it forwards the filter to the vendor build-intake skill so that only ready items already assigned to that assignee are considered. Intake never assigns or reassigns tickets as part of this filter.

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: thin dispatcher (no team of its own)

Intake creates NO agent team and spawns NO named teammates. It is a bounded scanner/dispatcher: resolve the queue, find the first eligible Ready item, claim it, and hand it to the single-item lifecycle skill — all in the current session.

This is deliberate. The per-item lifecycle skills (lisa-plan for PRDs, lisa-implement for build tickets) are team-first flows: each contains its own orchestration preamble that creates the agent team, records the roster, and fans out specialists. That preamble only has authority when the skill runs in the lead session — a teammate cannot add named teammates (Claude teams are flat: "Teammates cannot spawn other teammates — the team roster is flat"), so pushing the lifecycle skill down into a spawned subagent strands it without its team and collapses the flow into the single inline worker every team-first skill forbids. Therefore:

• Scanning and claiming run inline in this session (Bash / MCP / vendor skills via the Skill tool). This is cheap, bounded work — it does not need a team.
• Per-item dispatch is a Skill-tool invocation in this same session — never an Agent spawn. The chain Intake → vendor batch skill → lifecycle skill stays in the lead session end-to-end, so when lisa-plan / lisa-implement starts, its team-first preamble fires exactly as if the user had invoked it directly: it creates the per-item agent team, records the Roster Decision, and fans out its specialists.
• Fresh context per item comes from the scheduler, not from subagent isolation. Intake processes ONE eligible item per invocation and exits; each scheduled invocation is a fresh session. Never claim or process a second item after the first item's lifecycle flow has run in this session — exit and let the next cycle take it with clean context.
• The only permissible Agent use inside an Intake cycle is a bounded anonymous helper (Agent with name omitted) for scan-side legwork whose result returns directly to this session — e.g., paging a large queue. Never spawn the lifecycle flow, a vendor lifecycle agent (jira-agent / github-agent / linear-agent), or any implementation worker as a subagent from Intake.

Codex: the same contract applies — run the scan inline in the root session and invoke the lifecycle skill there so it can multi_agent_v1.spawn_agent its own team; do not spawn_agent the lifecycle flow itself. Other runtimes: apply the same rule through their equivalent delegation surface. If the runtime has no team/subagent tooling at all, the lifecycle skill's own no-team fallback handles it — Intake's job is unchanged.

If a teammate inside an existing team somehow invokes Intake (this should not happen — Intake is a session entry point, not a nested flow), do not scan or claim from there: return a structured delegation-request to the team lead asking it to run the Intake cycle in the lead session, and surface the misrouting.

One item per cycle. One team per item, created and owned by the lifecycle skill. A fresh session per cycle, provided by the scheduler.

Source dispatch

Detect the queue type from $ARGUMENTS and route:

If $ARGUMENTS is...	Queue type	Per-item dispatch
A Notion database URL or database ID	PRD queue (Notion)	Invoke lisa-notion-prd-intake (which scans the DB for Status=Ready, claims the first eligible PRD, runs lisa-plan via the dry-run validate → branch → write pipeline, then exits)
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 the first eligible PRD by relabeling to prd-in-review, runs the dry-run validate → branch → write pipeline, then exits)
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 the first eligible project by relabeling to prd-in-review, runs the dry-run validate → branch → write pipeline, then exits)
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 in .lisa.config.json
A JIRA project key (e.g. SE)	Work queue (JIRA)	Invoke lisa-jira-build-intake (which scans the project for Status=Ready, claims the first eligible ticket via In Progress, runs , transitions to On Dev on success, then exits)

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 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 in .lisa.config.json.
• A github.com URL or an <org>/<repo> token → GitHub queue. The PRD-vs-build dispatch is determined by which label namespace the repo currently uses: PRD-side (prd-ready) → lisa-github-prd-intake; build-side (status:ready and tracker = github in .lisa.config.json) → lisa-tracker-build-intake. If both namespaces are present, prefer the PRD queue unless $ARGUMENTS includes intake_mode=build. If the URL points at a single issue (https://github.com/<org>/<repo>/issues/<n>), this skill is batch-only — direct the caller to lisa-plan (for a single PRD issue) or lisa-implement (for a single build issue).
• The literal token github (case-insensitive) → GitHub queue, default repo from .lisa.config.json github.org / github.repo.
• A bare alphanumeric token that matches the JIRA project key regex (uppercase letters / digits / hyphen, ≤10 chars — typically the value of jira.project in .lisa.config.json) 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 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, GitHub } simultaneously — in that overlap the user must disambiguate which queue to scan.

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-github-prd-intake, lisa-jira-build-intake, lisa-github-build-intake) are internal — Intake is the public entry point. Developers schedule /lisa:intake <queue>; the rest is composition.

Cycle behavior

1. Resolve the queue — fetch the database/project metadata, confirm the Status property/workflow has the expected Ready value.
2. Pre-flight check — for JIRA, confirm In Progress and On Dev are reachable transitions before doing any per-ticket work. Stop with a clear error if the workflow is misconfigured.
3. Find Ready items — query the queue. Empty → exit cleanly with "No items with Status=Ready. Nothing to do." This is the common idle case for a scheduled run.
4. Process the first eligible Ready item only (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
   • GitHub PRDs → lisa-github-prd-intake handles per-item: claim (relabel issue to prd-in-review), dry-run validate, branch to prd-blocked or prd-ticketed (with clarifying-question comments posted directly on the PRD issue), coverage audit
   • JIRA tickets → lisa-jira-build-intake handles per-item: claim, dispatch to lisa-jira-agent, transition to On Dev on success
   • GitHub build issues (when tracker = github) → lisa-tracker-build-intake → lisa-github-build-intake handles per-item: optional ready-queue assignee filtering, claim (relabel to status:in-progress), dispatch to lisa-github-agent, relabel to status:on-dev on success
   • Duplicate-already-fixed build tickets are the one build-intake closeout exception: when ticket-triage returns DUPLICATE_ALREADY_FIXED with a canonical item and empirical base-branch evidence, the vendor build-intake skill closes the claimed ticket as a duplicate without opening a PR. This does not apply to , ambiguous, duplicate-of-open, or otherwise human-owned terminal dispositions.

Schedule examples

/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 https://github.com/acme/product-prds
/schedule "every 30 minutes" /lisa:intake acme/product-prds
/schedule "every 30 minutes" /lisa:intake SE
/schedule "every 30 minutes" /lisa:intake acme/frontend-v2 intake_mode=build
/schedule "every 30 minutes" /lisa:intake acme/frontend-v2 intake_mode=build assignee=codyswanngt
/schedule "every hour" /lisa:intake "project = SE AND component = 'frontend'"

Rules

• Never run a cycle without an explicit queue. Side effects too high to default.
• Never modify the source/destination lifecycles directly — Intake delegates per-item to the vendor adapter, which owns status transitions.
• Never run two Intake cycles concurrently against overlapping queues — concurrent claims could race. The scheduling layer is responsible for serialization.
• Stop and surface failures rather than retry-loop.