THE SHORT FIELD GUIDE · CURRENT SOURCE, 28 SEPTEMBER 2026

A method your next session can pick up.

Lintel gives a coding agent reusable ways to understand, plan, build, review and remember work. The model, tools and permissions still come from your coding app.

0.12.0 unreleased · 49f2d152 · Follow the six-part story · Open the file-by-file reference

Three words first.

Session

The current working conversation. A new session may load project instructions, but it does not automatically inherit the full previous conversation. Useful context needs a durable place to live.

Skill

A reusable method for a particular job: inputs, steps, expected output and checks. “Review this architecture” becomes a repeatable procedure rather than an improvised request.

Harness

The structure around the agent: workflows, context, handoffs and verification. Lintel supplies these as repository files and helpers. It does not run a hosted Lintel service.

The useful distinction

What are we building? How do we work and check it? Why did we choose this? Keep the answers available when the chat ends.

Six parts. A small working set.

PartWhat it contributes
Skills96 canonical methods. Load the ones the task needs.
Agent roles69 focused role definitions for bounded work and independent challenge; execution depends on the host.
Packs and profileCompany, team and project knowledge; constraints that should change the plan, checks and handoff.
ScaffoldingPlaces for plans, decisions, lessons and recovery records in your project.
Hooks and helpersExecutable checks and state handling. A script only runs where the host or workflow actually invokes it.
Client adaptersA shared kit with discovery files for the selected coding app.

Recent consolidation removes overlapping entrypoints while keeping useful methods. There is no need to memorize 96 commands. Start with the cycle; reach for inspect, verify, diagnose or cross-check when the work calls for them.

Skill catalogue · Current workflow migration

Four families. Different surfaces.

The current adapter catalogue names GitHub Copilot, Claude, Codex and Cursor: 13 named surfaces, plus an explicit manual other route.

FamilyNamed surfacesTypical discovery root
GitHub CopilotCLI, App, VS Code, cloud agent.github/skills/
ClaudeCode CLI, Desktop Code local.claude/skills/
CodexCLI, desktop, IDE, cloud.agents/skills/; cloud uses explicit file handoff
CursorCLI, editor, cloud.cursor/skills/

The portable kit delivers 15 starter wrappers: welcome, cycle, the nine phases, resume, spec-kit, swarm and mars. Other canonical skills remain available by explicit file reading.

Delivered is not the same as observed. Current records are mostly not_run, with partial Copilot App observations. A CLI route does not prove desktop or cloud parity. The portable adapter installs no hook bundle; compatible Claude Code hook registration is a separate mechanism. Mandatory controls belong in verified host permissions and CI.

Adapter guide · Exact surface and observation matrix

What lives where?

PlaceBelongs hereWhat travels?
Your setup
~/.lintel/
Installed packs, registries and personal preferences; configurable with LINTEL_HOME.Not automatically part of a project clone.
Installed kit
.github/lintel/ + client discovery root
Shared workflows and the selected host wrappers. The .github name is retained for compatibility.Managed repository files, according to the installation route.
Project knowledge
.claude/memory/, decisions/, plans/
Reviewed lessons, rationale, scope, task IDs and handoffs. This storage convention does not require Claude.Commit intentionally shared knowledge so the next clone can read it.
Local run state
.claude/runtime/
Checkpoints, local evidence and execution records.Ignored runtime is not recovered by an ordinary clone. Preserve required review evidence deliberately.

A client’s own home directory and chat history are another boundary. ~/.claude/ is Claude-specific, not a universal store. Some portable routes default to a repository-local Lintel home under runtime; inspect the resolved installation rather than assuming a personal home.

profile.yaml supplies role and mode preferences. Active pack selection and repository-required policy are separate. A missing mandatory pack must remain visible; it cannot quietly become a neutral profile.

Architecture and storage · Required profile context

Agree the work. Then build it.

SENSE → SCOPE → DEFINE → DISCOVER → PLAN → BUILD → REVIEW → SHIP → CAPTURE.

Understand the request and its boundaries. Resolve the unknowns. Leave an approved plan with acceptance criteria. Build in coherent packages, verify the result, deliver within authority, and capture what should change next time.

Plans keep short, checkable leaf tasks; execution and review operate on coherent work packages. A checkbox is a useful index. It is not evidence that a test ran.

One authoritative work map

Nine phases are a map, not a tax.

A typo needs a proportionate correction and check. A cross-repository feature with policy or architecture changes needs more context, explicit decisions and stronger evidence. Keep the mandatory constraints; scale the work around the actual risk.

NeedUseful entrypointExpected result
Understand an ambiguous requestdefineA clear intent and bounded scope.
Challenge a plan or repositoryinspectFindings through the appropriate engineering, design or developer-experience lens.
Check current behaviorverifyRead-only evidence by default; repair requires explicit scope.
Find a failure’s causediagnoseA source-backed explanation and bounded next action.
Get an independent second lookcross-checkActual independent review, with unavailable capabilities disclosed.
Continue in a fresh sessionpause → resumeThe same work, original IDs, verified profile and next unmet action.

“Looks good” needs a receipt.

The shared Review Method defines the bounded input, applicable obligations, coverage, findings and remaining uncertainty. Review evidence must describe the content actually inspected. Changed content or a later applicable rejection invalidates an earlier pass.

MARS — Multi-Model Adversarial Review & Screening — is an optional panel over that same method. Distinct models review the same packet independently; contested claims may get a challenge round. The coordinator resolves claims against evidence, not a vote.

Use it only with operator consent and host-verifiable model selection. An incomplete panel stays incomplete. Its verdict is advisory, with release_clearance: false; REVIEW, QA and SHIP retain their own gates.

Swarm is different: parallel implementation lanes under one coordinator and one accountable plan. It needs disjoint scopes, attributable isolation and reviewed integration. If the host cannot provide those, use serial work. Self-review is not an independent reviewer.

Review Method · MARS · Swarming

Try one useful session.

For a read-only survey, use the research method: /li:research where native skills are exposed, or read .github/lintel/skills/research/SKILL.md in the repository kit. It routes SENSE → DEFINE → DISCOVER; its findings do not approve implementation.

Use a small non-production repository. Select the exact client surface, install the reviewed kit using the current adapter guide, and verify discovery. For the explicit manual route, begin with:

Read .github/lintel/START.md.
Plan a health endpoint with a focused acceptance test.
Inspect existing routes and conventions.
Do not implement until the plan is authorized.

Inspect what the agent actually loaded, the proposed scope and the acceptance check. Authorize the bounded build, review its result, then pause and resume in a fresh session. Judge the complete loop, including effort and waiting time.

Kitchen protocol v2 is a larger evaluation design, not a published victory lap. The current evidence contains no completed controlled three-arm comparison. Start with the small team pilot before scaling.

Current setup and first-session instructions · Sources and evidence boundaries