About this skill

Problem

Long-running conversations can pollute a project’s working context. Chit-chat, cross-project ideas, rejected decisions, and old project memory can leak into the current development session, leading the model to treat temporary discussion as an architectural constraint or to lose track of completed changes. Relying only on chat history also makes it hard to separate real requirements from side conversations when resuming work.

How it works

This is a passive skill for opencode development sessions. The first layer performs lightweight detection: when command history, file changes, and keywords show enough development activity, it suggests entering dev-isolation but does not execute automatically. The second layer requires an explicit trigger, such as /dev-isolate start [project name], before creating an isolated context and starting to record.

Key capabilities:
- Memory isolation: reduces interference from previous chat memory while preserving project-relevant requirements, decisions, and code changes.
- State recovery: reads PROJECT_STATE.md first when entering a project, then uses chat context to restore progress.
- Architecture locking: records constraints with /dev-adr lock and blocks changes that conflict with the locked architecture.
- Progress tracking: uses commands such as /dev-todo, /dev-note, and /dev-sum to maintain tasks, notes, and status summaries.

Boundaries

It is not an automatic refactoring or dependency-upgrade tool. The skill excludes user emotions, casual conversation, unrelated technology debates, and unadopted proposals. Isolation and recovery are meaningful only when the project scope is clear and the user has confirmed the isolated development session. For ad-hoc debugging or one-off scripts, maintaining a separate state file may add more overhead than value.

Screenshots

Use Cases

After extended opencode debugging across modules, clear chit-chat and cross-project noise while retaining current project requirements and code changes.
Before starting a feature branch, confirm entering isolation and capture tasks, decisions, and next steps.
When returning to the same project, load the project state file to restore progress, pending tasks, and architecture constraints.
During development, write architecture decisions into the project record and block changes that conflict with the locked architecture.

Best For

Engineers using opencode for long-running feature work who want session context isolated from chit-chat and cross-project discussion.
Independent developers maintaining shared project state who need durable requirements, decisions, and task lists.
Software engineers working on refactors or new module integration who need architecture locking to prevent design drift.
AI-assisted programming users who want project state loaded first instead of relying on old chat history.