Agent continuity
Privacy-first continuity notes for long-running AI coding sessions.
npx -y skills add sjh6229/agent-continuity --skill agent-continuityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when initializing, resuming, continuing, handing off, or closing a long-running AI coding project across sessions, especially for initialize continuity notes, set up handoff notes, create docs, resume work, continue later, handoff, next session, long-running project, session state, continuity notes, docs/START_HERE.md, docs/CURRENT_STATE.md, docs/PROGRESS.md, docs/DECISIONS.md, or the legacy keyword longwork.
SKILL.md
4.6 KB, as published. Nobody here has run it
Agent Continuity
Use this skill to keep long-running project work resumable through short, privacy-first continuity notes.
Initialize Workflow
Use this workflow when a user wants to start a long-running project, set up continuity notes, create handoff docs, or prepare work that will continue across sessions.
- Identify the actual target project folder. Do not create continuity notes in a scratch directory unless the scratch directory is the user's actual project.
- Read project instructions first, especially
AGENTS.md,CLAUDE.md, or nested instruction files. - If the target folder or tracked work is unclear, ask one concise question before creating files:
What long-running work should these notes track, and what is the first success criterion? - If
docs/or continuity files already exist, do not overwrite them. Read existing notes, then create only the missing files that are needed. - Create or update
docs/START_HERE.md,docs/CURRENT_STATE.md,docs/PROGRESS.md, anddocs/DECISIONS.mdusingreferences/state-notes.md. - Keep initial notes neutral and minimal when details are not yet known. Do not invent project history, decisions, blockers, or verification results.
- Verify the created files exist and contain only the minimum state needed to resume.
- Report the created files and the first recommended next action.
Start Workflow
- Identify the actual target project folder. Do not assume the current scratch directory is the project if the user names another folder.
- Read project instructions first, especially
AGENTS.md,CLAUDE.md, or nested instruction files. - If
docs/START_HERE.mdexists, read it before project notes. - If
docs/CURRENT_STATE.mdexists, read it before proposing or resuming work. - Read only the needed parts of
docs/PROGRESS.md; prefer recent entries or targeted search. - Read
docs/DECISIONS.mdwhen implementation direction, stack, data model, or operational policy matters. - State success criteria and verification method before editing when project instructions require it.
- If code or document edits need approval, show a short plan and wait.
During Work
- Keep every changed line tied to the user's request, success criteria, or verification.
- Treat continuity notes as project-local state, not public output, personal memory, or chat history.
- Never store credentials, environment values, API keys, tokens, passwords, private keys, private URLs, customer data, personal identifiers, absolute local home paths, raw chat transcripts, or raw logs that may contain secrets.
- If sensitive context matters, write a generic redaction such as
private service,local config file, orredacted credential. - If the user asks for a narrow one-off task, do not update continuity notes unless the task clearly changes the long-running project state.
- If unrelated problems appear, report them instead of folding them into the current scope.
Closeout Workflow
Use references/state-notes.md when updating continuity files.
- Decide whether continuity notes need an update.
- Update when the task changed project state, left unresolved next actions, made a durable decision, or affects the next session.
- Skip when the task was read-only, exploratory, unrelated, or too narrow to change project state.
- Update
docs/CURRENT_STATE.mdas a short current snapshot only. - Append one dated entry to
docs/PROGRESS.md; do not rewrite old log entries. - Add to
docs/DECISIONS.mdonly for durable design, stack, data, workflow, or operational decisions. - Verify changed note files contain only the minimum state needed to resume.
- In the final report, include changed files, verification run, remaining blockers, and next action when useful.
- When reporting resume instructions, point the next session to
docs/START_HERE.mdfirst, thendocs/CURRENT_STATE.md.
Output Rules
- Keep final answers concise and in the user's language.
- Do not put prompt, agent, instruction, security-review, compliance, or process language into public deliverables.
- If Git work was involved and project instructions ask for it, report
git status, changed files, and raw test output.