@codyswann/lisa weekly downloads statistics

Lisa

Lisa turns a repository into a set of software factories — agent-operated production lines (Research → Plan → Implement → Verify) that build, verify, and ship software with as few humans as possible. Underneath the factories, Lisa is governance-as-code for AI-assisted software development: one set of standards, workflows, and quality gates applies identically whether the work is done by a human, by an AI agent on a laptop, or by a scheduled job — distributed to every project as a versioned dependency, and to every major coding agent platform (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot, Devin) from one source.

How to read this README

Lisa changes frequently, so this file stays deliberately conceptual. It teaches the mental model, which is stable, and avoids the specifics that drift — exact command names, flags, file paths, supported stacks, and version-dependent behavior. Wherever you need a current, concrete answer, you'll find a Prompt for your coding agent: a question to ask Claude Code (or whichever agent you use) that reads the live repository and answers from source.

- Humans — paste the prompt into your agent instead of trusting a hard-coded list that may be stale. - Agents — treat these prompts as instructions. Prefer discovering the current answer from the repository over asserting it from memory, and verify against source before stating it as fact. That habit is the same one Lisa enforces on all work: *prove it, don't assume it.*

What Lisa is

Lisa wears four faces from a single package:

• A factory operator. Scheduled intake agents watch queues of ready work, adversarially gate what enters the pipeline, and run each item through Research → Plan → Implement → Verify without a human in the loop. • A standards engine. It applies a curated set of configs, CI workflows, git hooks, and project rules into a target repository and keeps them current as the package updates. • An operating system for coding agents. It ships the skills, commands, agent roles, rules, and hooks that define *how* an AI agent investigates, builds, reviews, ships, and verifies work — and it delivers that same content to every supported agent runtime from one source. • A configuration library. Projects can consume Lisa's linting, testing, and TypeScript presets directly, per technology stack, without adopting the rest.

All four are versioned together, so "how we build software here" upgrades by bumping one dependency.

Prompt for your coding agent "Give me a one-paragraph tour of this repository's top-level layout: where the apply/template engine lives, where the agent plugin content is authored, and where the shared config presets are exported. Read the source and cite paths."

The factory model

Lisa's purpose is to run four factories in your project — production lines operated by agents, not people — so that non-technical people can create scalable software by describing outcomes while the factories supply the engineering discipline. Research creates PRDs. Plan turns a PRD into ordered work units. Implement turns work units into quality software — tests, code, UI, APIs, infrastructure. Verify issues a go/no-go by using the software the way a human would, and files any failures straight back into Implement as build-ready tickets, so the loop heals itself.

Humans don't work inside a factory. Handoff happens outside, at the gates: agents, humans, and automations submit inputs, and an intake agent adversarially evaluates each one — is it high-quality and unambiguous, and does the factory have the tooling *and provable access to that tooling* to execute it? The intake agent tries to resolve gaps itself first; what it genuinely can't resolve, it rejects and raises to a human rather than guessing.

Three loops keep the pipeline fed without anyone asking: QA explores the product like a first-time user and files bugs, Product Planning ideates PRDs, and Monitoring audits observability signals and files regressions. Everything runs on the coding agent's native scheduler, and by default the loops' outputs enter the gates pickup-ready — the adversarial intake is the quality control, not a human triager. Executed properly, end users have zero direct contact with coding agents: they see the tracker, the PRDs, and the shipped software.

Prompt for your coding agent "Explain how this project's factory pipeline is wired right now: which automations exist and on what cadence, what each gate checks before admitting work, and where a human is still required. Read the installed automations and intake skills — don't guess."

Core principles

These are the durable ideas. Everything concrete descends from them.

Single source, many destinations. Agent instructions are authored once and compiled into runtime-specific artifacts and into each project. You never hand-edit the generated output — you edit the source and rebuild.

Prompt for your coding agent "In this repo, which directory is the source of truth for plugin/agent content, which directories are generated artifacts, and what command rebuilds them? Show me the guard that fails CI if the artifacts drift from source."

Location-agnostic. The same rules and gates hold on a developer's workstation, in a scheduled improvement job, and in a CI workflow reacting to a PR. Only the plumbing adapts — local integrations versus REST in CI — the standards do not.

Layered quality gates. Rules load into every agent session as context; git hooks are hard stops on commit and push; agent hooks bridge an agent's actions to the project's real tooling so linting, tests, and checks actually run.

Prompt for your coding agent "List the quality gates that would run against a change in this project — session rules, git hooks, and agent hooks — and for each, tell me whether it blocks or only warns, and how you can tell from the code."…

Description from the npm listing.