Opendevbrowser Continuity Ledger

OpenDevBrowser Continuity Ledger

Use this guide to maintain compaction-safe project state in CONTINUITY.md.

Validation helper:

• scripts/validate-skill-assets.sh

When to Use This Skill

Use this skill when any of these are true:

• Work is multi-step or long-running.
• Context compaction or session handoff is likely.
• Multiple agents are coordinating the same task.

Start with opendevbrowser-best-practices quick start for execution. Switch here once continuity tracking is required.

Ownership Rules

Apply these rules exactly:

• Allow only the main orchestrator agent to edit CONTINUITY.md.
• Instruct sub-agents to never edit CONTINUITY.md.
• Require sub-agents to append their outcomes to sub_continuity.md.
• If CONTINUITY.md is modified incorrectly by another agent, restore it immediately and continue.

Start-of-Turn Protocol

Run this sequence at the beginning of each turn:

1. Read CONTINUITY.md.
2. Read sub_continuity.md.
3. Update CONTINUITY.md to reflect the current goal, constraints, decisions, and execution state.
4. Proceed with implementation.

If recall is incomplete, rebuild from visible context, mark gaps UNCONFIRMED, then continue.

Required Ledger Template

Maintain these headings and sections:

Goal (incl. success criteria):
- Constraints/Assumptions:
- Key decisions:
- State:
  - Done:
  - Now:
  - Next: at least 4 next tasks/subtasks each with a brief description. must be detailed with a clear action item and expected outcome and files to be impacted
- Open questions (UNCONFIRMED if needed):
  - When you have open questions, do your research in the codebase (and on the internet for best practices) to understand the existing patterns and constraints. Choose answers that are consistent with the existing patterns and constraints and best-practice and research all synchronized into logical recommendations. You must research codebase + external sources first, state the recommended option with brief rationale, and explicitly list any items that still require user input.
- Working set (files/ids/commands):
- Key learnings: what worked; what didn't work, best approach identified for next time

Update Triggers

Update CONTINUITY.md whenever one of these changes:

• Goal or success criteria
• Constraints or assumptions
• Key decisions
• Progress state (Done, Now, Next)
• Important command/tool outcomes

Keep entries factual and concise. Avoid transcript-style logging.

Validator Contract

The validator must confirm all of these remain documented:

• CONTINUITY.md and sub_continuity.md ownership boundaries
• start-of-turn read and update protocol
• required ledger headings and UNCONFIRMED handling
• reply pattern with a short ledger snapshot before the main answer

Handling Open Questions

When uncertainty exists:

1. Research codebase patterns first.
2. Research external best practices where relevant.
3. Recommend a preferred option with rationale.
4. List only unresolved user-input decisions.
5. Mark unknown facts as UNCONFIRMED.

Reply Pattern

Start response messages with a short ledger snapshot:

• Goal
• Now/Next
• Open questions + recommended option

Print the full ledger only when it materially changes or when requested.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.