Lisa Intake

Intake: $ARGUMENTS

Run one intake cycle against the queue identified by $ARGUMENTS, or by merged GitHub config when the repo argument is omitted and a GitHub source/tracker default is resolvable. Scan for Status = Ready, claim the first eligible item, dispatch it to the appropriate single-item lifecycle skill, then exit. 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, resolve the explicit or config-backed queue and 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 and no resolvable GitHub default, or 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:

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).
• A GitHub URL or owner/repo token is an explicit queue and always wins. The literal token github (case-insensitive), or an omitted repo when merged config resolves a GitHub source/tracker and identity, resolves local then global github.queueRepo, then identity github.org/github.repo for build dispatch. Normalize a short queueRepo to github.org. PRD dispatch remains on the configured GitHub PRD source. Without an explicit queue or resolvable GitHub default, stop with the missing-input error. Do not use the build queue repo as current-repo identity for repo:<name> scoping.
• 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 lisa-linear-access operation: 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, GitHub org/repo} simultaneously — in that overlap the user must disambiguate which queue to scan.
• An <org>/<repo> token (slash-separated, both halves are GitHub-name-shaped) → GitHub queue.
• 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-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 (clarifying-question comments posted on the project itself), 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 BLOCKED, ambiguous, duplicate-of-open, or otherwise human-owned terminal dispositions.
   • Closing the PRD loop: beyond claiming one Ready PRD, every PRD scanner also runs the closure rollup (ticketed → shipped, Phase 3f) and dispatches lisa-verify-prd for one shipped PRD (Phase 3g) each cycle — so a shipped PRD does not sit unverified. On pass the PRD goes shipped → verified; on fail it is re-opened shipped → ticketed with build-ready fix tickets that auto-build and trigger a re-verify (never blocked). The scanner only dispatches; lisa-verify-prd owns the transition (per the prd-lifecycle-rollup rule's "Closing the loop" section), and the self-healing loop continues until the PRD verifies.
5. Stop after one item — a claimed Ready item, a safe-blocked container, or a per-item error ends the ready-claim portion of the cycle. The per-vendor PRD scanner still runs its rollup and one verify-prd dispatch. Remaining Ready items stay untouched for later scheduler invocations.
6. Summary report — the single processed/skipped/error item, total processed, total errors. Before returning, record intake usage on the persisted cycle-summary artifact via lisa-usage-accounting so the summary carries a direct lisa-intake entry in the canonical ## Lisa Usage section. If the claimed / skipped work item's parent-child graph is already known, prefer record_and_rollup so ancestor totals refresh in the same cycle; otherwise still write the direct entry, and if runtime usage is unavailable, use source: unavailable with nullable token/cost fields instead of skipping the row.

Run outcome

As a registered automation loop, each Intake cycle conforms to the automation-runbook-contract rule: it ends in exactly one of the six run outcomes and records it, so a quiet queue and a broken loop never look alike. Intake backs two registered loop-ids — record under the one that matches the mode this cycle ran in: intake-prd (PRD-side dispatch) or intake-tickets (build-queue dispatch).

Seam warning (the #1 misread in this ticket). A run outcome describes this cycle; Blocked is a work item's lifecycle terminal state — the two never merge in the summary. When Intake correctly routes to Blocked (an item whose requirements are unresolvable, carrying clarifying questions), the cycle produced something, so it is a successful run — candidate-proposed, and never recovery-required (the machinery is not broken) and never nothing-needed (the run did not find nothing). The summary must say both plainly: the item was blocked and the run succeeded.

Record exactly one outcome per invocation through the run-record CLI, naming this loop's runbook (the --summary is the operator-readable one-liner in the contract's exemplar voice — plain, specific, actionable, e.g. Scanned 12 ready items; nothing to propose. for nothing-needed):

node "${CLAUDE_PLUGIN_ROOT:-node_modules/@codyswann/lisa/plugins/lisa}/scripts/automation-run-record.mjs" \
  --loop-id intake-tickets --outcome candidate-proposed \
  --summary "Routed PRD #1810 to Blocked with clarifying questions; the run succeeded." \
  --runbook .lisa/automations/intake-tickets.runbook.md [--ref <item-url>]...

A dry build lane must say what it looked in. A nothing-needed run on intake-tickets additionally passes --denominator — the JSON from buildIntakeDenominator() in the plugin scripts directory's intake-prework-denominator.mjs, resolved exactly like the recorder below — and the recorder refuses the row without it. This is not decoration: 31 consecutive cycles reported a dry lane against a queue holding 61 unswept pre-work rows, and every one of those records was honest. A missing row is noisy on inspection; a wrong denominator is silent forever and looks exactly like a healthy dry queue. Stating the swept set is what turns the silent wrong answer into an inspectable one (#2657).

node "${CLAUDE_PLUGIN_ROOT:-node_modules/@codyswann/lisa/plugins/lisa}/scripts/automation-run-record.mjs" \
  --loop-id intake-tickets --outcome nothing-needed \
  --summary "Nothing ready to build on team ENG. Looked in every lane holding work that has not started — Backlog (20), Todo (17), Ready (2), Blocked (61) — 100 items checked out of 343 still open." \
  --denominator "$DENOMINATOR_JSON" \
  --runbook .lisa/automations/intake-tickets.runbook.md

The :- default in that command is load-bearing, not decoration. CLAUDE_PLUGIN_ROOT is not exported into an agent's Bash tool environment, so the bare "${CLAUDE_PLUGIN_ROOT}/scripts/…" form expands to an absolute /scripts/… and exits 1. The default names the installed package copy, which resolves from the consumer repository root — which is where the recorder is actually invoked. Never substitute a bare plugins/lisa/scripts/… or plugins/src/base/scripts/… path: those are relative to the Lisa package root, not the repository you are standing in, and exit 1 from there. If recording still fails, degrade, never abort (per automation-runbook-contract): note the recording failure in the run output and finish the cycle — a recording failure is a degradation to report, never a reason to block the loop.

Retirement evaluation (every run). Both loop-ids this skill backs are structural to the factory — they do not retire. Their runbooks say so plainly instead of leaving the Retirement condition blank, so the automation-runbook-contract rule's two-part retirement test never fires here: neither intake-prd nor intake-tickets ever records policy-obsolete, and neither ever files a teardown proposal. An operator who wants intake to stop runs /lisa:tear-down-automations themselves — the loop never removes its own registration.

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.