SCEbyCroCoder

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

  • Install the sce CLI first.
  • 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.

Contents

Install the sce CLI first

Before you start the repo workflow, install the Shared Context Engineering CLI so the sce command is available in your shell. The current supported install channels are Nix, Cargo, and npm.

Choose one install method:

Nix

Use Nix when your environment already standardizes on reproducible developer tooling.

nix profile install github:crocoder-dev/shared-context-engineering

Cargo

Use Cargo when you already install Rust-based developer tools from your local Rust toolchain.

cargo install shared-context-engineering --locked

npm

Use npm when your team prefers a JavaScript-style global install path for local onboarding.

npm install -g @crocoder-dev/sce

Verify the CLI is available

After you install one of the supported distributions, confirm the command is on your path before continuing to repo setup.

sce --help
sce version

Once one install path is working and both verification commands run, return to this guide and continue with repository setup.

View install sources and releases

Run sce setup in the repo

Once the CLI is installed, use sce setup as your first repository command. This is the onboarding step that prepares the repo-local SCE assets before you start planning and task execution.

Run it inside an existing git repository. If the repo is not initialized yet, start with git init before running sce setup.

sce setup
  • installs the repo assets used by the supported agent workflows
  • bootstraps the repo-local .sce/config.json if it is missing
  • installs required git hooks during interactive setup

What success looks like

A successful setup reports Setup completed successfully., shows the selected target, and tells you how many files were installed into the destination directory.

Setup should also create or verify:

  • repo-local SCE config
  • checkout identity
  • agent trace database
  • installed harness assets for your selected integrations
  • required hooks, if you enabled them

Checkout identity tells SCE which local checkout produced trace data. SCE captures prompt, session, task, file, and review evidence so the team can later query how AI-assisted changes were produced. See Agent Traceability for how to inspect that work with sce trace.

After sce setup finishes successfully, continue with the validation steps below.

Check readiness with sce doctor

After setup, run sce doctor before you start planning or executing tasks. It reports whether your machine, repository, hooks, and installed repo assets are ready for the SCE workflow.

Check readiness

sce doctor

Use the default text report when you want a human-readable readiness summary before starting work.

What the readiness report checks

The default text report is grouped into the current check sections:Environment,Configuration,Repository,Git Hooks, andIntegrations.

  • Environmentcovers SCE state-root detection.
  • Configurationcovers global config path, repo-local config path, config validation, checkout identity, and agent trace database presence.
  • Repositorycovers repository-root detection and hooks-directory resolution.
  • Git Hookschecks required hook presence, executability, and canonical content.
  • Integrationschecks installed harness assets for OpenCode, Claude Code, or both depending on your setup, including agents, commands, skills, and plugin or content drift checks where supported.

Text markers and readiness

  • [PASS]means the checked item is present and healthy.
  • [FAIL]means the item was inspected and is not ready.
  • [MISS]means the expected item is missing or could not be detected.

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

1. Define the change (specify success criteria)
2. Draft implementation plan (create task stack)
3. Review and refine the plan

Run one agent session for each task in the implementation plan

4. Agent session (plan one task)
5. Agent session (implement that task)
6. Review and request changes
7. Run final tests and cleanup
8. Review final change and test results
Outer loop (review, adjust, plan a new change)

Legend

interactive stepsworkflow stepsouter loop

At this point your repository should be ready for SCE. The next step is running the workflow on a real change.

Continue with the SCE workflow tutorial to see how to turn a change request into a plan in context/plans/{plan_name}.md, run one task per agent session, capture validation evidence, and keep context/ synchronized with the codebase.

MotivationSCE Tutorial