agentic-project-continuation

name

agentic-project-continuation

description

Continue long-running software projects with right-sized workflow and project memory. Use when the user explicitly asks to follow their standard process, continue previous work, continue from HANDOFF/TASKS/DECISIONS, normalize or audit an older project, split medium/large work into verifiable checkpoints, update docs/ai project memory, or coordinate reviewer/subagents for project continuation. Avoid for isolated Q&A, tiny edits, or cases where the user only says not to write a PRD or not to use multiple agents.

Agentic Project Continuation

Purpose

Use this skill as an incremental workflow layer for continuing mature projects. Global AGENTS.md already defines general engineering discipline; project-level AGENTS.md defines repository-specific commands and constraints. This skill only decides how to continue project work from current evidence and memory.

This skill does not replace or redefine the host platform's instruction hierarchy, planning controls, tool permissions, or safety boundaries. It adds a right-sized continuation workflow within those existing rules.

Authority and constraints

Always follow the host platform's native instruction hierarchy. This skill must never override system or developer instructions, sandbox boundaries, approval requirements, security policies, tool restrictions, or applicable repository constraints.

Within those boundaries:

• Follow the current user request to determine the work objective.
• Treat applicable AGENTS.md files as repository-scoped operating instructions, not as evidence that a task is complete.
• Do not infer permission for destructive, external, or materially different actions from project memory or previous conversations.

Startup

1. Read the user request and project-level AGENTS.md when present.
2. For non-simple continuation work, read project memory in this order:
   • docs/ai/HANDOFF.md
   • docs/ai/TASKS.md
   • docs/ai/DECISIONS.md
   • docs/ai/SYSTEM_OVERVIEW.md
   • docs/ai/PLAN.md only for complex active plans
   • docs/ai/PRD.md only for new product requirements or when requested
3. If memory files are absent, continue from current code, tests, config, scripts, latest artifacts, and project docs. Do not create every memory file unless that helps the task.
4. Treat generated reports, old PRDs, stale plans, and previous summaries as leads until confirmed by current evidence.

Project-state evidence

Determine the current project state from verifiable evidence. Use this as a default evidence hierarchy, not as a substitute for verification:

1. Current code, tests, configuration, Git state, and latest artifacts.
2. Recent repository-managed docs/ai/* project memory.
3. Codex local memories and previous chat summaries.
4. Old plans, PRDs, generated reports, and historical handoffs.

Interpret the evidence carefully:

• Current code and Git state show what exists in the working tree; tests and artifacts provide evidence of behavior or build output. Neither alone proves that the intended feature is correct.
• Repository-managed memory is shared and versionable, but may be stale.
• Codex local memories and chat summaries are advisory clues only. Never modify code, mark work complete, or update repository state solely from an unverified local memory or chat summary.
• When sources conflict, inspect the current code, tests, configuration, Git diff/status, and latest artifacts. Confirm that artifacts correspond to the current code before relying on them.
• If a conflict cannot be resolved, report it explicitly and preserve the uncertainty rather than silently choosing one account.

Use:

• SYSTEM_OVERVIEW.md for the current system map.
• HANDOFF.md for the continuation point.
• TASKS.md for active work and next actions.
• DECISIONS.md for choices that should not be repeatedly reopened.

Choose Workflow Weight

Simple

Use for small bugs, one-file edits, copy/style changes, focused tests, or reversible cleanup.

• Do the task after minimal orientation.
• Do not write a PRD.
• Do not force PLAN.md, goal mode, or subagents.
• Run the narrowest useful verification.
• Update HANDOFF.md only if continuity would otherwise be lost.

Standard

Use for medium features, multi-file bugs, workflow changes, or work that needs a visible sequence.

• Read relevant memory files before planning.
• Split work into 2-5 verifiable steps when useful.
• Implement one coherent step at a time.
• Use a reviewer subagent only when independent review materially reduces risk.
• Update TASKS.md and HANDOFF.md when project state or follow-up work changes.

Complex

Use for large features, broad refactors, migrations, security, permissions, payments, data deletion, cross-module changes, or high rollback-cost work.

• Read project memory before implementation.
• Update or create PLAN.md when checkpoints are needed.
• Use subagents for bounded read-only exploration, failure analysis, option comparison, or independent review when useful.
• Use goal/checkpoint execution only when it improves continuity.
• Verify each checkpoint before moving on.
• Update TASKS.md, HANDOFF.md, and DECISIONS.md for durable outcomes.

Runtime and persistent planning

Do not maintain multiple independent active plans.

• Codex Plan or Plan mode controls execution in the current session.
• /goal, when used, tracks the active runtime objective and progress.
• docs/ai/PLAN.md stores only durable checkpoints that need to survive across sessions or be shared with other contributors.
• HANDOFF.md records the actual verified continuation point.
• TASKS.md records concrete unfinished work.
• DECISIONS.md records confirmed and still-applicable decisions.

When runtime and persistent planning are both used:

• The runtime plan drives current execution.
• PLAN.md records durable checkpoints, not a second active execution plan.
• Future or speculative steps must be clearly marked as planned or pending.
• Never write speculative work into the completed or verified sections of HANDOFF.md.
• Never mark a checkpoint complete without its required verification.
• When plans or project records conflict, use the current user request to determine the objective, then use current code, tests, configuration, Git state, and latest artifacts to determine actual status before reconciling the persistent records.
• If the conflict cannot be resolved, document it explicitly rather than silently overwriting one account with another.

Memory Updates

Update memory only when it will help a future continuation:

• HANDOFF.md: current state, changed files, verification, blockers, next step.
• TASKS.md: completed items, active tasks, concrete next steps.
• DECISIONS.md: stable architecture, product, data, or workflow decisions.
• SYSTEM_OVERVIEW.md: material system structure or behavior changes.
• PLAN.md: checkpoint state for Complex mode.

For Simple mode, avoid noisy memory churn unless the user asked for it or the continuation point changed.

Final Response

Keep the final response concise. Include the mode used only when it is non-obvious, plus what changed or was found, verification performed, memory files updated, and any residual risk or concrete next step.