long-running-agent-workflow
Skill6 starsChanged 3 months agoMITView on GitHub
Structured protocol for AI agents working across many context windows: a .lra/ directory with an atomic feature list (id/priority/acceptance criteria/status) and a session progress log, plus a session protocol (read context → pick ONE feature → implement → test → checkpoint) and recovery from broken states. Based on Anthropic research on long-running agents. Triggers: 'lra', 'checkpoint', 'feature list', 'long running', 'продолжи работу', 'долгая сессия', 'план фич', 'статус проекта'.
In this repository59 other files it gives its agents.
- skills/chronos/references/AGENTS.mdAGENTS.md
- api-contract-testingSkill
- api-doc-generatorSkill
- canonSkill
- censorSkill
- changelog-generatorSkill
- chronosSkill
- code-reviewSkill
- commit-lintSkill
- commit-message-writerSkill
- coverage-analyzerSkill
- csv-proSkill
- data-analysisSkill
- deweySkill
- diagram-makerSkill
- doc-compareSkill
- docs-productSkill
- docs-projectSkill
- docs-systemSkill
- dsh-runnerSkill
- frontend-a11ySkill
- frontend-design-tasteSkill
- frontend-perfectionSkill
- frontend-performanceSkill
- frontend-testingSkill
- github-repo-hygieneSkill
- mermaid-to-imageSkill
- mobile-frontendSkill
- pdf-report-builderSkill
- plan-skillSkill
- prd-to-appSkill
- presentation-craftSkill
- presentation-engineeringSkill
- presentation-makerSkill
- raster-to-svgSkill
- reddit-karmaSkill
- repo-community-filesSkill
- repo-metadata-healthSkill
- repo-readme-assetsSkill
- repo-social-previewSkill
- secret-scannerSkill
- security-reviewSkill
- seo-auditSkill
- seo-contentSkill
- seo-crawlSkill
- seo-schemaSkill
- seo-toolkitSkill
- skill-feedbackSkill
- skill-forgeSkill
- skill-suggesterSkill
- sql-helperSkill
- systematic-debuggerSkill
- test-generatorSkill
- test-graphicsSkill
- velesSkill
- version-bumperSkill
- video-script-writerSkill
- web-replicationSkill
- web-scraperSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 49
If the task is small and finishes in one session, you do not need this skill — just do the work.
- Very specific: line 58
Run the CLI from the project root (it creates/reads .lra/ there).
- Very specific: line 76
Add atomic, testable features.
- Distinctive: line 104
Always checkpoint at the end of a session, even for partial work.
- Distinctive: line 119
Always leave the codebase working: No broken builds, no failing tests at a checkpoint.
- Very specific: line 131
Never start a feature without acceptance criteria: If none exist, write them first via add --criteria.
- Distinctive: line 168
Do not use for a short, single-turn task that does not need resumable state.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
Boundaries
- Do not use for a short, single-turn task that does not need resumable state.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

