Introduction
Getting started with Shared Context Engineering
This is a practical guide for running Shared Context Engineering (SCE) in this repository. If you want the strategic background first, read Why SCE Exists.
TL;DR
- Get agent / plugins from
Shared Context Engineeringrepo. - You define the change, constraints, and success criteria.
- The agent proposes and executes one scoped task at a time.
- You review outputs, request adjustments, and close the change.
Start simple (recommended)
If you want the quickest setup, just use the Shared Context agent:
- OpenCode -
Shared Context - Claude -
shared-context - Cursor - Coming soon
- Codex CLI - Coming soon
This is enough to run the full workflow. Commands and skills are convenience wrappers around that same behavior.
How SCE works in practice
In Shared Context Engineering, you own strategy. You define what needs to change, what done means, and how strict quality should be. The agent executes scoped work inside that strategy. The workflow looks something like this:
Shared Context Engineering Workflow
Run one agent session for each task in the implementation plan
Legend
Define the change
Everything starts with a change: the input prompt written by the software engineer, without using AI, that explains what should change and why (requirements, bugs, constraints, domain rules).
Specify success criteria up front so the agent can execute with clear boundaries and a concrete definition of done.
Draft the implementation plan
Now it's time for the agent to take your change and draft an implementation plan. Open you preffered AI harness and let's give SCE agent your written change request.
From that change, the agent creates an implementation plan in context/plan/{plan_name}.md. Every plan has multiple tasks that break the change into smaller, testable units. Last task is always a final validation task that runs tests and cleanup after all other tasks are done.
A task is the smallest testable delivery unit (for example: a new endpoint, refactor, schema update, write unit tests, etc.). Keep tasks scoped so each agent session can complete a single unit cleanly.
Important: If your repo is missing context/ directory, the SCE agent will prompt you do you want to bootstrap context. context/ dir is where the agent stores implementation plans, tasks, and test results. It also serves as the shared context for the agent's work. It's important for you to commit this shared context everytime agent updates it.
Review and refine the plan
Before implementation, review the agent-created plan and refine it. Often if your change is missing details or constraints, the agent will prompt you with questions to clarify the plan. This is your chance to improve ambiguous steps, add missing constraints, and confirm task ordering.
This is the quality gate that keeps implementation aligned with your intent before code changes begin.
Run one task session
Now open a new session, and prompt SCE agent to implement the next task in the plan. SCE agent will pull in relevant context from the repo and potentially prompt you back to clarify some issues that relate to the next task. After that, the agent will ask you to start implementing the task. Don't forget to review the code SCE agent produced.
Repeat this loop for each task created in the implementation plan. Multi-task sessions are possible, but one task per session usually gives better control and traceability.
Validate and close
After all tasks are complete, the agent runs tests and cleanup tasks for final validation of the full change.
Then perform a manual review of the final change and test results before you close out the change.
Congratulations, you just ran Shared Context Engineering! Now you are ready for the next Change request!