Use coding agents on real projects without rebuilding context every time.
Start with the project problem you recognize. Each workflow shows what to ask your agent, what Skopos maintains, and what you should review.
01Existing codebases
02Everyday agent work
03Solo builders and teams
Bring an existing repository into Skopos.
Your project already has code, docs, conventions, and commands. A tool that rewrites them before understanding the repository can destroy useful truth.
Skopos discovers what exists, proposes how it should fit the Memory standard, and waits for approval before material documentation changes.
“Set up Skopos in this existing repository. Preserve its current docs and commands as project truth. Explain what you find, show me one consolidated recommendation, and ask before applying material changes.”
Plan and build one feature without losing the intent.
A productive conversation can still drift into extra work, miss a constraint, or leave the next session unable to explain why the implementation looks this way.
The agreed result becomes a bounded Task with relevant Memory, acceptance, ownership, constraints, and the checks that matter.
“Help me plan and build [feature]. First recover the relevant project context, clarify decisions that change scope, then create a bounded Task with acceptance criteria and owned paths before implementation.”
Come back after days or weeks.
You remember the project, but not every open decision, unfinished Task, failed check, or reason a piece of work stopped.
Skopos gives the agent a compact view of live work and material project truth instead of forcing you to replay old chats.
“Bring me back up to speed on this project. Show active Tasks, material decisions, recent Evidence, and what needs attention next—without dumping the whole repository.”
Continue in a fresh coding-agent session.
A new chat has no reliable understanding of the work in progress, even when the previous session was excellent.
The fresh session recovers the current Task, relevant Scope Memory, owned paths, Evidence, and remaining blockers from the project.
“Continue the active [task] in this fresh session. Recover its Scope, relevant Project Memory, acceptance, ownership, Evidence, and remaining blockers before making changes.”
Split independent work without losing the reviewer.
Parallel agents move quickly, but overlapping paths, hidden dependencies, and disconnected conclusions can make the final integration harder than the original work.
Independent child Tasks receive explicit acceptance and ownership while the originating conversation remains responsible for reviewing the combined result.
Automated delivery is host-dependent; Skopos keeps a manual fallback when native delivery is not verified.
“Split this work only where the parts are genuinely independent. Give each child Task explicit acceptance criteria and owned paths, and keep this conversation as reviewer for the combined result.”
Require the right checks before calling work done.
A generic green check can miss the requirement that actually matters, and an old passing result can silently outlive the source it proved.
Project-approved checks produce source-bound Evidence, and Readiness explains exactly what still prevents closure.
“Before calling this Task complete, select the focused project-approved checks for its changed paths, run them, and explain any missing or stale Evidence.”
Keep project knowledge current as the code grows.
Architecture, decisions, and operating rules gradually fall behind when documentation updates depend on someone remembering to do them later.
Before closure, durable impact is reviewed. Canonical Memory is updated when truth changed—or explicitly left alone when it did not.
“Before closing, review whether this work changed architecture, decisions, patterns, or operating rules. Update canonical Project Memory if needed; otherwise record why no change is required.”
Start with the workflow that costs you the most context.
Add Skopos to one real repository and let the project carry the important parts forward.