Liza Skills: 25 Composable Capabilities for Coding Agents

Liza ships 25 composable skills — prompt modules agents invoke for code review, debugging, testing, ADR generation, red-team testing, and more.

Skills are Liza’s methodology layer. Where the behavioral contract defines what agents must never do and the state machine defines the order in which they must act, skills define how to do specific kinds of work well. Each skill is a YAML-fronted prompt module — a structured protocol for a domain like code review, debugging, or architectural documentation — that any agent can load on demand, regardless of its assigned role.

​

What Skills Are

Skills live in ~/.liza/skills/ and are installed there by liza setup. Each skill is a directory containing a SKILL.md — a structured protocol with phases, checklists, decision trees, and output formats tuned for a specific task domain.

Agents invoke a skill by name in their session. The behavioral contract’s Protocol References section specifies which skills are mandatory for which situations: the debugging skill must be read before any debugging work, the code review skill before any review, the testing skill before writing or analyzing tests. Other skills are invoked when the agent judges them relevant.

Skills are composable with roles — a coder who hits a bug loads the debugging skill; a reviewer who encounters structural concerns loads the architecture review skill. Roles define boundaries; skills define capabilities. This is intentional: 13 roles with 25 composable skills beat 60+ specialized roles with rigid, non-transferable capabilities.

The AGENT_TOOLS.md file in your ~/.liza/ directory documents which tools and skills are available in your specific environment. Agents read it at session start and adapt their behavior accordingly. See Customizing AGENT_TOOLS.md for details on removing skills you have not installed or adding references to custom tooling.

​

The 25 Skills

Skill	Purpose
adr-backfill	Archaeologically reconstruct missing Architecture Decision Records from git history
adversarial-pairing	Coordinate doer/reviewer sessions through a shared Markdown blackboard
architecture-planning	Produce structured architectural designs with component, interface, and dependency analysis
black-box-red-testing	Adversarial testing without internal code access — attack from the outside
checkpoint-summary	Produce a structured sprint or session summary for human review
clean-code	Language-specific style enforcement and readability improvement
code-quality-assessment	Complexity metrics, maintainability scoring, and refactoring recommendations
code-review	Risk-mitigating structured review with P0–P6 priority hierarchy and Sanity/Standard/Deep modes
code-spec-backfill	Backfill function-level contracts: docstrings, type annotations, and inline specifications
context-engineering	Audit prompt payload shape, context bloat, cacheability, and handoff fit
debugging	Structured root-cause analysis: Quick Wins → Fast Path → Normal Path
detailed-spec-writing	Transform requirements into precise, implementation-ready specifications
epic-writing	Transform a vision or goal into structured, reviewable epics
feynman	Explain complex ideas clearly — knowledge transfer without jargon
generic-subagent	Context-efficient delegation to subagents with structured handoff
have-you-considered	Surface alternatives, edge cases, and different approaches before committing
lesson-capture	Capture operational lessons from mistakes and discoveries into durable files
liza-logs	Cross-correlate agent logs to identify frictions, regressions, and token inefficiencies
software-architecture-review	Structural concern analysis: coupling, dependency, cohesion, and backward compatibility
spec-backfill	Backfill missing specifications and reconcile spec/code drift
spec-review	Structured specification review protocol
systemic-thinking	Systemic coherence and downstream risk analysis
testing	Test protocol: coverage strategy, edge case identification, and TDD enforcement
user-story-writing	Transform requirements into user stories with acceptance criteria
white-box-red-testing	Targeted adversarial testing with confirmed-bug/likely-bug/specification-gap classification

​

Highlighted Skills

code-review

Risk mitigation, not gatekeeping. The code review skill structures the reviewer’s attention across seven priority levels: P0 (security), P1 (correctness), P2 (data integrity), P3 (architecture and operability), P4 (performance), P5 (maintainability), and P6 (style). Reviewers spend 70% of their attention budget on P0–P2 — the categories responsible for most production incidents. The skill defines three review modes: Sanity (obvious issues, trivial changes), Standard (full P0–P3 checklist via targeted diffs), and Deep (source context plus data flow tracing for security-sensitive or architectural changes). Reviewers announce the mode and rationale before beginning, and escalate from Standard to Deep if unexpected complexity surfaces.

debugging

Certainty over speed. The debugging skill prevents the most costly debugging failure mode: trying random things. It defines three tiers. Quick Wins (30 seconds max) rules out typos, stale caches, wrong branches, and missing environment variables — the no-brainers. Fast Path applies when a stacktrace points directly to the fault, a single hypothesis survives first inspection, and the fix is self-evident. Normal Path applies to everything else: structured bug report intake, reproducibility confirmation, hypothesis formation with traced failure paths, and an escalation protocol when hypotheses fail. Fast Path has a single attempt; if the first fix fails, you undo and escalate to Normal Path immediately — no second tries.

adr-backfill

Archaeology, not documentation. The ADR backfill skill reconstructs Architecture Decision Records from a repository’s git history when they were never written at the time decisions were made. It classifies files by architectural significance (dependency manifests, infrastructure configs, domain boundaries, interface contracts), identifies commits with structural changes versus routine edits, clusters related commits into single decisions, and fills gaps from specs/ and docs/ that commits may not have captured. For each cluster, it generates a complete ADR: context, decision, rationale, alternatives considered, and consequences. The skill maintains chronological numbering and keeps the ADR index in sync throughout the process.

white-box-red-testing

Find bugs by writing tests that fail. White-box red testing takes a specific scope — a commit range, a set of files, or functions below a coverage threshold — and generates adversarial tests designed to reveal real bugs. The skill gathers contract evidence per target (docstrings, type annotations, existing tests, call sites), forms structured hypotheses as [code_path] × [defect_class] → [observable_symptom], generates one test per hypothesis, runs them, and classifies results as confirmed-bug (test fails, bug is real), likely-bug (test fails, contract ambiguous), or specification-gap (no contract evidence exists). It never modifies source code — only produces test files. A distinctness filter ensures findings are not shallow variations of the same bug.

​

Observability Skills

Two skills focus on the system’s own health rather than the code under development.

liza-logs cross-correlates agent logs across all running agents to identify frictions. Early in a project this surfaces misconfiguration — missing tools, wrong paths, contract misreads. In mature setups it catches regressions from provider CLI updates, token inefficiency patterns, and tool usage anomalies. Run it at sprint boundaries or when agent behavior feels degraded.

context-engineering audits the prompt payload that agents receive at session start: payload shape, context bloat, cacheability of repeated content, and whether handoff notes are structured for a fresh agent to resume effectively. It produces recommendations for reducing token cost without sacrificing context quality.

​

Customizing Your Skill Environment

liza setup installs all 25 skills to ~/.liza/skills/ and writes a default AGENT_TOOLS.md that references them. If you have not installed a tool that a skill depends on, or if your environment uses a different tool for the same purpose, update AGENT_TOOLS.md to reflect your actual setup.

1. Run liza setup

   liza setup
   

   This installs contracts and skills to ~/.liza/ and writes the default AGENT_TOOLS.md.

2. Review AGENT_TOOLS.md

   Open ~/.liza/AGENT_TOOLS.md. It lists every tool and skill available to agents, along with invocation patterns and notes on when to prefer each one.

3. Remove tools you have not installed

   If you are not using a tool like scip-search or semble, remove it from AGENT_TOOLS.md. Agents will not attempt to invoke tools that are not listed, which prevents failed tool calls and wasted tokens.

4. Add project-specific tools

   If your project uses tools not in the default list — a specific MCP server, a custom linter, a domain-specific search tool — add them to AGENT_TOOLS.md with a description and invocation pattern. Agents read this file at session start and adapt their tool preferences accordingly.

See Customizing AGENT_TOOLS.md for the full reference on field format, tool preference ordering, and environment-specific patterns.

Skills are independent of roles — there is no restriction on which role can load which skill. If you are pairing and want the agent to apply the have-you-considered skill before committing to an approach, just ask. If a code reviewer has structural concerns that go beyond the code review checklist, it loads software-architecture-review without leaving its reviewer role.