Long-Running Agent (LRA) Workflow
Load this skill when you are about to work on a large project that will span multiple sessions / context windows and you need continuity, atomic handoffs, and recovery from broken states.
The skill gives you a tiny CLI (scripts/lra_cli.py) that maintains a .lra/
directory: a machine-readable feature-list.json (atomic features with
acceptance criteria and status) and a human/agent-readable progress.txt
(session log). The protocol turns "one big vague task" into a sequence of
small, fully-tested, check-pointed features.
Overview — the problem
AI agents working across many context windows hit three failure modes:
- Context amnesia — each new session has no memory of prior work.
- One-shot tendency — trying to do too much at once, leaving half-done features.
- Incomplete features — work spans sessions with no clear acceptance gate, so "done" is never verified.
LRA fixes this with: structured init, one atomic feature per session, an
explicit test gate before done, and a checkpoint after every feature so the
next session can recover.
When to use
- Long, multi-session projects (hours/days, many context windows).
- Any task where you might lose context between runs.
- Triggers:
lra,checkpoint,feature list,long running,продолжи работу над проектом,долгая сессия,план фич,статус проекта.
If the task is small and finishes in one session, you do not need this skill — just do the work.
Prerequisites
- A git repository (so checkpoints can be committed and recovered).
- Python 3 on
PATH(the CLI is pure stdlib, no dependencies). - Run the CLI from the project root (it creates/reads
.lra/there).
Instructions
Phase 1 — Init
python3 scripts/lra_cli.py init "Short project description"
Creates .lra/feature-list.json ({"project": ..., "features": [], "created": <date>})
and .lra/progress.txt with a header. Refuses (exit 1) if .lra/ already
exists, so you never clobber an in-progress project.
Phase 2 — Plan features
Add atomic, testable features. Each gets an id (f1, f2, …), a name,
a priority (high/medium/low), and criteria (acceptance criteria).
python3 scripts/lra_cli.py add "User registration endpoint" --priority high \
--criteria "POST /api/auth/register accepts email+password; validates email; hashes password; returns JWT"
Rule: a feature must be completable in one session and have concrete acceptance criteria. "Build the user system" is too big — split it.
Phase 3 — Session protocol (repeat every session)
- Read context —
statusand read.lra/progress.txtto see where you are. - Pick ONE feature — the highest-priority
todo(orwipyou abandoned). - Implement it.
- Test it against its acceptance criteria (unit + integration + manual).
- Mark done —
mark f<N> doneonly after verification passes. - Checkpoint —
checkpoint "Implemented X and Y; tests green".
python3 scripts/lra_cli.py mark f1 done
python3 scripts/lra_cli.py checkpoint "User registration: endpoint + validation + tests"
Phase 4 — Checkpoint / recover
checkpoint "<message>"appends a timestamped line toprogress.txt. Always checkpoint at the end of a session, even for partial work.recoverprints the last 10 progress lines plus a summary ofwipfeatures — use it at the start of a session or after a broken state to see what was in flight.
Phase 5 — Status
status prints a table of all features (id, name, priority, status) sorted
todo → wip → done, so you always know the current state at a glance.
Best practices
- One feature per session. Finish it fully (code + tests) before moving on.
- Always leave the codebase working. No broken builds, no failing tests at a checkpoint.
- Commit after each feature. A checkpoint is a clean git state the next session can trust.
- Update
feature-list.jsonbefore closing the session — mark status, add notes, add newly discovered sub-features withadd. - Atomic features only. Small, testable, single-purpose.
Constraints and warnings
- Never start a feature without acceptance criteria. If none exist, write
them first via
add --criteria. - Never skip tests. A feature is not
doneuntil its criteria are verified end-to-end. - Don't mark
donewithout verification. Markingdoneon unverified work poisons the next session's context. - Don't clobber
.lra/.initrefuses if it exists; recover from the log instead of recreating.
Files
SKILL.md— this fileskill.json— manifestscripts/lra_cli.py— the stdlib CLI (init,add,mark,checkpoint,status,recover)references/lra-workflow.md— full reference:.lra/file structure, JSON schemas, a worked example, the session checklist, and troubleshooting
Installation
# For opencode
cp -r skills/long-running-agent-workflow ~/.config/opencode/skills/
# For other agents: copy the folder to your skills directory; requires Python 3.
Key principle: leave the codebase in a testable, working state at the end of every session. The next session (and the next agent) picks up from the last checkpoint, not from amnesia.