Install the CLI once on your machine.
Practice to playoffs
Give your coding agent
a real playbook.
mancode is a local-first workflow harness for the coding agent you already use. It adds project context, task intensity, durable artifacts, acceptance evidence, and review gates without replacing Claude Code, Cursor, Codex, Copilot, or ZCode.
You normally talk to your agent with solo, /manba, or /man. The installed adapter then uses mancode workflow to maintain the durable record. The CLI reference below explains that record; it is not a second workflow you must perform by hand.
Install & initialize
Node.js 20 or newer is required. Run the initializer inside an existing project or a safe empty directory, then choose one or more agent adapters. Windows CMD, PowerShell, and Git Bash are supported; Git is optional and only improves team-mode detection.
Open the project the agent should understand.
Scan project facts and install the selected adapter.
$ npm install -g mancode
$ cd your-project
$ mancode initNon-interactive or targeted initialization
--platform accepts a comma-separated adapter list. In automation, pair it with --yes; use --empty only when you intentionally want generic initialization in an empty directory.
$ mancode init --platform codex,cursor
$ mancode init --yes --platform codex --no-team
$ mancode init --empty --platform claude-code --lang en| Option | Use it when | Effect |
|---|---|---|
--force | Repair generated configuration | Reinstalls managed content while preserving detected style tokens and content outside managed blocks. |
--yes | CI or a non-interactive shell | Accepts safe defaults and skips generic-project confirmation; pair it with --platform. |
--platform LIST | You know the target agents | Installs one or more of claude-code, cursor, codex, copilot, and zcode. |
--empty | The directory is intentionally empty | Allows generic-project initialization without git init or a package manifest. |
--team / --no-team | Auto-detection is not the policy you want | Forces shared-memory mode on or off. |
--style NAME | You have a named visual preference | Saves it as the default style preference. |
--lang en|zh-CN | You need deterministic generated text | Sets the generated-content locale. |
Verify the installation
$ mancode status
$ mancode status --jsonThe human-readable result names the project, current mode, team state, installed adapters, and each adapter's ready or not ready status. JSON is the stable choice for scripts; mancode status --brief --json returns the compact public Continuity view used by coding agents. A ready adapter means its required generated files are present; it does not guarantee that an already-open agent session has reloaded them.
Restart or reload the coding agent after initialization. Then start a small request in solo. If an adapter remains not ready, repair it with mancode install <platform> --force.
Files & privacy
mancode works locally, scans only the current project, and sends no telemetry. It deliberately does not rewrite your project's .gitignore, so your team—not the installer—decides which generated context belongs in version control.
| Path | What it contains | Before committing |
|---|---|---|
.mancode/schema.json.mancode/shared/.mancode/local/ | Continuity authority, project policy, sessions, workflow metadata, and local runtime records. Legacy state.json exists only after explicit --legacy initialization. | Review workflow evidence and local records before sharing; raw host session keys are never persisted. |
.mancode/shared/context/project.json.mancode/local/cache/style-tokens.json | Detected stack, validation commands, and local UI tokens. | Inspect for internal project details and decide whether reproducibility justifies sharing. |
.mancode/local/workflows/.mancode/shared/workflows/ | Requirements, plans, review and verification ledgers, reports, checkpoints, and summaries. | Review carefully. Evidence and reports may contain sensitive data; shared workflows pass the Continuity privacy boundary. |
.mancode/shared/context/decisions/.mancode/shared/team/ | Confirmed decisions and durable coordination authority. | Commit only information intentionally written for the team. |
.claude/, .cursor/, .agents/, .github/, AGENTS.md | Adapter instructions, commands or prompts, skills, hooks, and managed blocks. | Share when the adapter is part of the team's development workflow. Content outside mancode's managed blocks remains yours. |
mancode manps scans and reports by default. Remediation is explicit. Irreversible project operations still require human confirmation; installing mancode does not grant the agent permission to publish, delete, or rewrite unrelated work.
Continue work across sessions
mancode stores goals, requirements, plans, validation results, and handoff notes under a stable TaskRef. A new chat window or supported CLI can resume the same task and load a purpose-specific Context Pack.
This is task continuity, not a copy of raw chat history. Sessions from different clients remain isolated; the new session must identify its own client and explicitly resume the existing TaskRef.
$ mancode status --brief --json
$ mancode context session new --client claude-code
$ mancode context resume <namespace:ULID> --session <id> --client claude-code
$ mancode context show --purpose orient --session <id> --client claude-codeThe generated /man, /manba, and /manteam entries use the same records. Use the CLI form for diagnostics, automation, or manual recovery.
Choose the smallest mode
Task length is not the deciding factor. Choose the lightest mode that leaves enough evidence and review for the cost of a wrong decision.
solo
A small feature, refactor, or UI tweak. Uses project context, narrow validation, and one bounded diff self-check without a separate reviewer loop.
/manba
Reproduces the failure, diagnoses the cause, validates a real user path, and runs regression checks.
/man
Freezes requirements and a versioned plan, then either hands off to solo or continues through governed implementation, verification, and review.
/manteam · /manps
Adds shared memory and handoff records, or runs deterministic health scans before maintenance work.
Use /man when a wrong choice would be expensive, hard to reverse, or difficult to inspect later—not simply because the task is large.
Invoke a mode
Mode names are portable, but invocation follows the extension model of each agent. Run them in the agent chat—not in your operating-system shell. /mansolo or $mansolo explicitly returns to the default solo mode.
| Mode | Best for | Behavior |
|---|---|---|
solo | Daily coding | Project context, lightweight rules, relevant validation, and one bounded diff self-check. |
manba | Diagnosis | Reproduction-first debugging with cause, user-path validation, and regression evidence. |
man | Requirements and governed delivery | Research, clarification, a versioned plan gate, verification, and risk-based review. |
manteam | Shared projects | Team memory, decisions, coordination, and handoff-friendly summaries. |
manps | Project maintenance | Deterministic dependency, security, dead-code, and configuration scans. |
Claude Code / Cursor
CommandsUse the generated slash commands in chat.
/manba
/man
/manteam
/manps
/mansoloCodex
SkillsUse explicit skill mentions in the app, CLI, or IDE.
$manba
$man
$manteam
$manps
$mansoloGitHub Copilot
PromptsSelect or invoke the generated prompt file by mode name in a client that supports repository prompt files.
man.prompt.md
manba.prompt.md
manteam.prompt.md
manps.prompt.md
mansolo.prompt.mdZCode
PreviewThe adapter installs project skills. Discovery and invocation depend on the current ZCode release, so verify them with mancode status.
$man
$manba
$manteamCLI reference
The CLI installs adapters and enforces durable workflow state. Run state-reading commands from an initialized project. Invalid transitions fail safely instead of silently editing workflow metadata.
mancode init
StartCreates .mancode/, detects the project, scans style tokens where relevant, and installs adapters.
- Options:
--force,--yes,--team,--no-team,--style <name>,--platform <list>,--empty,--lang <locale>.
mancode install [platform]
AdapterInstalls or repairs an adapter after initialization. Omit the platform for interactive selection.
--forceregenerates managed content.--minimalinstalls solo-mode essentials only.
mancode status [--json] [--brief]
InspectReports project facts, current mode and workflow, adapter readiness, and Claude hook registration where applicable. Combine --brief --json for the compact Continuity runtime view.
mancode list-platforms
DiscoverLists adapters known to the installed CLI and marks those already configured in the project.
mancode workflow <subcommand>
GovernCreates and validates Continuity requirements, plans, verification evidence, reviews, remediation, and completion.
- Inspect with
listandshow <namespace:ULID> [--json]. - Use
context compact --dry-runto inspect removable runtime records; Continuity workflow authority is not deleted byworkflow clean.
mancode manps [area]
ScanRuns a deterministic health scan for all, deps, security, dead-code, config.
--jsonemits machine-readable output.--remediateenters the explicit remediation path; the default is scan-only.
mancode refresh-project
RescanRefreshes project facts after adding Git, a manifest, a framework, or validation commands, then updates installed static adapters.
mancode refresh-style
DesignRefreshes the project profile and design tokens. Reinstall static adapters with --force afterward.
mancode uninstall [platform]
RemoveRemoves one Continuity adapter. Continuity protects authority from bulk removal; use context compact --dry-run for retention candidates. The --all form is legacy-only.
mancode version
VersionPrints the installed CLI version for upgrade checks and issue reports.
Study the /man workflow
/man is a progressive nine-step protocol. It first makes the decision inspectable, then lets the user choose between a lightweight handoff, a plan-only result, or governed execution. Every gate is backed by Continuity files under .mancode/<namespace>/workflows/<ULID>/.
The installed Continuity mode entry creates the task and reads its Context Pack. The commands below are the machine contract for studying, debugging, or integrating the process. Continuity identifies tasks with explicit namespace:ULID TaskRefs and does not use a legacy active pointer.
The nine steps and their gates
| Step | Agent work | Durable gate |
|---|---|---|
| 1 · Scout | Inspect the project profile, existing implementation, dependencies, risk, and unknowns. | Write scout-report.md. |
| 2 · Clarify | Resolve every decision-changing unknown; classify what is blocking, recommendable, or safely defaultable. | Finalize a complete requirements ledger. blockingUnknowns must be empty. |
| 3 · Plan | Write confirmed scope, choices and reasons, reuse, exclusions, behavior, risks, rollback, and real validation. | Write plan.md; first plan is v1, revisions increment planVersion. |
| 4 · Plan gate | Echo the plan and ask the user to choose solo handoff, governed execution, plan only, or revision. | No implementation is legal before an explicit decision. |
| 5 · Implement | Make the smallest change that satisfies the confirmed plan. | Stay inside scope; new decision-changing facts return to clarification or plan revision. |
| 6 · Verify | Run detected build, lint, typecheck, tests, smoke checks, and each required acceptance criterion. | Every required acceptance ID has current passing evidence. Manual checks require explicit user confirmation. |
| 7 · Quality review | Review only the changed diff and direct impact; record at most three new, evidenced findings. | Write the report and stable blocker IDs. Findings are recorded before fixes. |
| 8 · Security / boundary review | Full review only: inspect security, permissions, recovery, resources, and boundaries. Targeted review marks this domain not applicable. | The required review domains are complete; duplicate root causes stay deduplicated. |
| 9 · Remediate & finish | Resolve open blockers in one remediation round, reverify if anything changed, and summarize. | Zero blockers, current verification, summary.md, then status completed. |
Requirements ledger
The ledger prevents a polished plan from hiding unresolved assumptions. It needs a goal, non-empty confirmed scope, all seven coverage dimensions, and at least one required acceptance criterion. If the technical stack applies, technicalDecisions cannot be empty. Save input outside or inside the workflow directory; finalization writes canonical requirements.json and requirements.md.
{
"version": 1,
"goal": "Refactor authentication without changing login behavior",
"confirmedScope": ["Extract token validation into the existing auth service"],
"excludedScope": ["Changing the identity provider", "Redesigning login UI"],
"technicalDecisions": ["Keep the existing TypeScript and session stack"],
"defaults": ["Preserve current timeout values"],
"blockingUnknowns": [],
"coverage": [
{ "dimension": "platform", "status": "confirmed", "rationale": "Node service" },
{ "dimension": "core_scope", "status": "confirmed", "rationale": "Refactor only" },
{ "dimension": "technical_stack", "status": "confirmed", "rationale": "Existing stack retained" },
{ "dimension": "data_and_persistence", "status": "not_applicable", "rationale": "No schema change" },
{ "dimension": "performance", "status": "defaulted", "rationale": "No regression from baseline" },
{ "dimension": "compatibility", "status": "confirmed", "rationale": "Public behavior unchanged" },
{ "dimension": "security", "status": "confirmed", "rationale": "Token checks stay fail-closed" }
],
"acceptanceCriteria": [
{
"id": "AC-LOGIN",
"description": "Valid and expired tokens retain current behavior",
"required": true,
"method": "automated"
}
]
}$ mancode workflow requirements <local:ULID> finalize --file requirements-input.json --expected-revision <revision> --session <session-id>A successful result says ready. A result of needs_clarification is a hard stop: resolve blockingUnknowns, regenerate the input, and finalize again.
The Step 4 decision
Solo handoff
DeliverUse when the plan is settled but implementation risk is routine.
$ mancode workflow handoff <local:ULID> --to solo --expected-revision <revision> --session <session-id>
# after solo implements and verifies
$ mancode workflow handoff <local:ULID> --complete --expected-revision <revision> --session <session-id>Governed execution
ContinueUse when implementation, evidence, and independent review should remain inside the nine-step record.
$ mancode workflow plan <local:ULID> confirm --plan-decision governed_execution --expected-revision <revision> --session <session-id>Plan only
StopUse when the requested deliverable is the confirmed plan, not code.
$ mancode workflow plan <local:ULID> confirm --plan-decision plan_only --expected-revision <revision> --session <session-id>All three choices require an active man workflow, confirmed requirements, and plan.md. Revise the plan with workflow plan ... revise; every successful mutation returns the revision required by the next command.
A valid Continuity sequence
Continuity uses explicit TaskRefs and expected revisions. The CLI owns every durable mutation; do not edit metadata files or use the legacy --step protocol.
# Bootstrap an actor and explicit session
$ mancode team identity create --name "Your name"
$ mancode context session new --client codex --json
# Create, discover, and inspect a task
$ mancode workflow create man "refactor auth module" --session <session-id> --json
$ mancode workflow list --json
$ mancode workflow show <local:ULID> --json
# Requirements and plan gates (use the revision returned by each command)
$ mancode workflow requirements <local:ULID> finalize --file requirements-input.json --expected-revision <revision> --session <session-id>
$ mancode workflow plan <local:ULID> revise --file plan.md --expected-revision <revision> --session <session-id>
$ mancode workflow plan <local:ULID> confirm --plan-decision governed_execution --expected-revision <revision> --session <session-id>
# Record canonical review and verification ledgers
$ mancode workflow review <local:ULID> apply --file review-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow verify <local:ULID> apply --file verification-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow complete <local:ULID> --expected-revision <revision> --session <session-id>Verification, manual checks, and remediation
| Case | Required record | Gate behavior |
|---|---|---|
| Automated | The canonical verification ledger records the criterion, command, exit code, evidence summary, and result. | workflow verify ... apply rejects a ledger that does not satisfy the Continuity schema and current revision. |
| Manual | The ledger records why automation cannot decide and only changes to passed after explicit user confirmation. | Completion remains blocked while required manual evidence is pending. |
| Review finding | The canonical review ledger stores stable blocker IDs and their remediation state. | Applying a review ledger makes earlier verification stale; apply current verification after review and before completion. |
| User skips review | The review ledger records the explicit user decision and residual risk. | Completion still requires a valid summary and every remaining gate. |
# Update the canonical ledgers after a remediation
$ mancode workflow review <local:ULID> apply --file review-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow verify <local:ULID> apply --file verification-ledger.json --expected-revision <revision> --session <session-id>
$ mancode workflow complete <local:ULID> --expected-revision <revision> --session <session-id>Workflow subcommands
| Command | Purpose | Important options |
|---|---|---|
create | Start a man, manba, or manteam record. | --parent <TaskRef> links a diagnostic child; --json exposes the TaskRef. |
requirements | Finalize the structured requirements ledger. | finalize --file --expected-revision --session. |
plan | Revise a plan or confirm its execution decision. | revise --file; confirm --plan-decision; both require revision and session. |
update | Change lifecycle status or a blocking reason. | --status --expected-revision --session; governed fields use dedicated commands. |
handoff | Transfer a confirmed local plan to solo and later close it. | --to solo or --complete, with revision and session. |
verify / review | Apply canonical Continuity ledgers. | apply --file --expected-revision --session. |
list / show / clean | List or inspect Continuity TaskRefs. clean is not a Continuity authority deletion command. | show <namespace:ULID> --json; use context compact --dry-run for retention. |
Platforms & adapters
mancode adapts to the extension points each surface actually offers. A platform marked preview is installed, but its runtime discovery or invocation remains dependent on that platform's current release.
| Platform | Installed integration | How to use it |
|---|---|---|
| Claude Code | Hooks, skills, subagents, and commands under .claude/. | Full integration. Restart after installation so session and prompt hooks reload. |
| Cursor | .cursor/rules/*.mdc plus .cursor/commands/*.md. | Rules supply persistent context; invoke generated slash commands for explicit modes. |
| Codex | AGENTS.md plus .agents/skills/. | Use explicit $man* skill mentions in the app, CLI, and IDE. |
| GitHub Copilot | .github/copilot-instructions.md plus .github/prompts/*.prompt.md. | Persistent managed instructions plus repository prompt files; prompt-file support varies by client. |
| ZCode (preview) | AGENTS.md plus project skills in .agents/skills/. | Verify skill discovery and invocation in your installed ZCode release. |
Refresh project context
Use refresh-project when the stack or project structure changes. Use refresh-style after a design-system migration, a substantial UI change, or when a non-UI project gains an interface.
$ mancode refresh-project
$ mancode refresh-style
$ mancode install cursor --forcerefresh-projectupdates detected project facts and installed static adapters.- Claude Code reads refreshed context through hooks.
- Cursor, Codex, Copilot, and ZCode use static files; reinstall a specific adapter with
--forceif you need to repair or regenerate it. - Only UI projects receive design-token-specific guidance.
Uninstall safely
Uninstalling one adapter preserves user-authored rules, instructions, unrelated Claude settings, and Continuity workflow authority. Use context compact --dry-run to inspect eligible runtime retention records.
Remove one adapter
$ mancode uninstall cursor --forceReinstall one adapter
$ mancode uninstall claude-code --force
$ mancode install claude-codeRemove the CLI
$ npm uninstall -g mancodeTroubleshooting
mancode init rejects the directory
A safely empty directory is supported interactively, or explicitly with --empty. A non-empty directory still needs a recognized project marker or Git metadata so mancode does not initialize an arbitrary folder by accident.
The agent does not see a newly installed mode
Reload or restart the agent so it rereads repository instructions. Run mancode status; if the adapter is not ready, run mancode install <platform> --force. For ZCode and Copilot, also confirm that the installed client release supports repository skills or prompt files.
Claude Code hooks do not run
Restart Claude Code after initialization, then check mancode status for both hook files and registration in .claude/settings.json. Repair with mancode install claude-code --force. The hooks use Node.js and do not require Bash or jq.
Cursor rules do not trigger
Confirm that .cursor/rules/mancode-*.mdc and .cursor/commands/*.md exist. Core context and solo rules are persistent; higher-intensity rules are description-triggered, so invoke the generated mode command explicitly.
A workflow command is rejected
Treat the rejection as a gate, not a file-corruption problem. Use mancode workflow list --json to discover TaskRefs, then mancode workflow show <namespace:ULID> --json to inspect metadata, revision, aggregate, and blockers. Do not edit Continuity metadata manually.
Project facts became stale
After adding Git, a manifest, dependencies, or validation scripts, run mancode refresh-project. Use refresh-style for UI tokens. Then repair a static adapter only if its generated files need regeneration.
No documentation sections match your search.
