ICode — AI Coding Workflow for Claude Code, Codex, CodeBuddy and WorkBuddy

6-step workflow: Plan → Review → Finalize → Code → Deep Check → Audit. Run all at once, or step-by-step and switch models between steps.

Website & workflow diagrams · 中文官网 · 中文说明 · Installation

ICode is an open-source AI coding workflow Skill for Claude Code, Codex, CodeBuddy and WorkBuddy. Ticket-based development connects requirements, design, implementation, code review and evidence-based verification, with saved state for resuming interrupted work across sessions.

For multi-model code review, switch agents or models yourself, then run /icode crosscheck on a completed ticket; ICODE does not automatically switch models. The optional /icode ui provides a local ticket workspace. Use ICODE only when you name ICODE or resume a bound ICODE ticket; it does not take over unrelated requests.

Why ICode?

The bilingual public site can be built locally. See site preview and opt-in publishing for GitHub Pages, RSS and optional search notifications. Publication is disabled by default; once enabled, each push to main updates the site automatically. Formal Release and manual runs remain available, but only the latest commit on the default branch may publish; stale runs are rejected. Other branches and PRs do not publish. The site never reads your tickets and does not replace the installer or local UI.

Concern	Vanilla Claude Code	ICode
Process discipline	Depends on your prompt	Hard 6-step gates + L1–L4 blocking matrix
Review quality	Single-perspective self-review	Independent skeptic sub-agents with adversarial verification (self-delegation forbidden)
Post-completion review	Ad-hoc review may alter ticket context	/icode crosscheck records isolated, repeatable review rounds without writing the ticket or code
Review scope and evidence	A file list or plausible line number can hide omissions	Native inspection worklists derive scoped changes, jointly review related files and verify finding excerpts/hashes; incomplete reads remain explicit debt
Laziness resistance	None	39 hard anti-laziness rules + mandatory Read confirmation lines + file:line evidence
Reusing past decisions	Every ticket starts cold	Cross-project history retrieval with a global index + verdict-based anti-misleading injection (disproved tickets inject the trap, not the ADR)
Project knowledge	None	/icode doc generates a global per-project/branch knowledge base, auto-injected at phase zero
DOCX delivery	Manual conversion and host-dependent tools	/icode docx creates traceable Word deliverables using an ICODE-managed runtime and ABI-checked renderer contract
Crash recovery	Restart from scratch	.ico_metadata.json status + round counters enable resumable runs at any step
Cost control	Depends on host configuration and task	Optional cheap-research offloads eligible low-risk extraction/compression tasks; /icode fast trims the review flow. Actual time and cost depend on the task, model and review rounds; no fixed savings are promised.
Model freedom	Manual	Every step is a separate command, so you can switch models between steps

Find the right workflow

What you need	ICODE entry	Boundary
AI coding workflow / ticket-based development	/icode start or /icode plan	A plan-only request stops before code changes.
Design review / code review across models	/icode review or /icode crosscheck	Switch models yourself; crosscheck re-reviews a completed ticket without modifying it.
Debugging / log root-cause analysis	/icode log	Check source and runtime provenance before claiming a cause.
Evidence-based verification	/icode verify --listen or /icode verify --test <target>	These standalone stages use the device's existing version; no implicit build/deploy.
Resumable tickets / local ticket manager	Resume a bound ICODE ticket or /icode ui	Existing host chat remains supported; UI runners currently support Claude/Codex.

Directory login is not listing, and listing is not a recommendation or a complete installation. See the current discovery and distribution boundaries; use the source installer, not a downloaded SKILL.md alone.

Quick Start

# 1) Clone the open-source installer
git clone https://github.com/ayukyo/icode-skill ~/icode-skill
cd ~/icode-skill

# 2) Install ICODE, shared skills, and MCPs for Claude Code + Codex
./install.sh --client all

# 3) Run a full flow
/icode start Implement a feature module

You can also name ICODE and describe the goal in plain language. The current host agent routes to the existing steps and gates; no extra model service is needed:

Use ICODE to design retries for this module. Stop at the plan; do not change code.
Use ICODE to test the version already on the device. Do not build or deploy.
使用 ICODE 把当前工单做成 PPT，给测试同事看。
/icode 帮我查看当前工单还有哪些验证没完成

See the complete natural-language guide for every capability, combined requests, constraints, and resuming a ticket. /icode help also exposes these examples. Automatic discovery depends on the host loading the installed skill; if it does not, explicitly select the ICODE skill or use /icode. Existing commands remain supported.

Or run step by step (switch models between steps anytime):

/icode plan Implement a feature module   # Step 1: Draft plan
/icode review                                       # Step 2: Review plan (soft cap 3 rounds; auto-extends if issues remain)
/icode merge                                        # Step 3: Merge & finalize
/icode code                                         # Step 4: Code implementation
/icode deepcheck                                    # Step 5: Iterative re-review
/icode audit                                        # Step 6: Final audit & fix

Other entry points:

# Local global ticket manager (defaults to 127.0.0.1:8765; auto-falls back if occupied)
/icode ui

# Trimmed full flow (fast mode: single-file/small changes; not a fixed cost guarantee)
/icode fast "Add isqrt function to calc.c"          # plan→review(1 round, no adversarial)→merge→code→deepcheck(Reverse only)→audit

# Requirement unclear? Draft it in conversation first
/icode init Record sensor data re-bag                # Step 0: kick-off draft + dialogue
# After the init analysis and discussion, turn the latest eligible draft into a beginner-facing guide
/icode init --guide                                  # Refreshes deliverables/guide.md; does not create another ticket

# From a bug log: analyze root cause first, then fix
/icode log ~/work/log/service-anomaly "no response after startup"   # Entry: log root-cause analysis → fix requirement

# Project-level knowledge base (standalone step, runs anytime)
/icode doc myproject                                 # Generate/update this project's knowledge base chapters

# DOCX delivery (standalone; preserves `/icode doc` knowledge-base semantics)
/icode docx docs/release-guide.md                    # P0: faithful DOCX beside the Markdown source
/icode docx current bug delivery Word                # P1: latest unique ICODE ticket → .icode_output/docx/

# Backup all work orders before deleting a project (safety net — run BEFORE deleting)
/icode bak                                           # Snapshot current project's entire .icode_output/ to ~/.claude/icode_data/project_backup/
/icode bak --project ~/work/myproj                   # Backup a specified project
# Repeatable: each run creates a new timestamp snapshot (rsync --link-dest hardlink dedup).
# After the project is deleted, history retrieval still finds full work orders from the backup (project-first, backup fallback).

# Opt-in worktree isolation (any of the entry points above)
/icode start --worktree Implement a feature module   # Full flow + isolated branch/dir
/icode fast --worktree  "Add isqrt function to calc.c"         # Fast mode + isolated branch/dir
/icode plan --worktree  Implement a feature module    # Step 1 only + isolated branch/dir
/icode init --worktree  Record sensor data re-bag              # Step 0 + isolated branch/dir
/icode log --worktree   ~/work/log/service-anomaly "no response"  # Log + isolated branch/dir
# Without --worktree, tickets are created in-place by default — no prompt.
# Triggers also accept natural language ("use worktree isolation"), with reverse declarations taking precedence; AI shows a status line on entry. Projects can block via `/icode limit worktree 强制禁止`.
# New worktrees are created on the current remote-tracking baseline (@{u}) with upstream tracking, so git status/pull/merge stay correct.
# Worktree lifecycle (after creation):
/icode worktree --update    # Move the active implementation to a new checkout on the latest remote baseline (tracked upstream)
/icode worktree --close     # After you committed/pushed/merged: verify online evidence + safe cleanup + record baseline
/icode worktree --reopen    # Restore a closed ticket's active checkout on the latest baseline (then /icode patch)
/icode worktree --merge         # Fetch online targets, preflight conflicts, merge safely, then recheck; never commits or pushes

The Workflow

  /icode log (optional)        /icode init (optional)
  log root-cause analysis ─┐    requirement draft ─┐
                           └──────────┬────────────┘
                                      ▼
  ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐
  │ Plan   │ → │ Review │ → │ Merge  │ → │ Code   │ → │ Deep   │ → │ Audit  │
  │ Step 1 │   │ Step 2 │   │ Step 3 │   │ Step 4 │   │ Check  │   │ Step 6 │
  └────────┘   └────────┘   └────────┘   └────────┘   │ Step 5 │   └────────┘
                                                       └────────┘
       /icode start = steps 1→6 chained  |  /icode fast = trimmed chain

Every main ticket step produces a real artifact in .icode_output/.icode_output_N/ (plan → review → final plan → code → deep-check report → audit report), tracked by .ico_metadata.json for cross-session recovery and resumable runs. Detached deliverables and crosscheck rounds use their documented sibling directories and do not pretend to be tickets.

Features

• Closed-loop delivery: (optional) Requirement Draft → Plan → Review → Finalize → Code → Deep Check → Audit; each step callable independently, runs in the main session without model switching
• Dual modes: /icode start full flow (multi-round review + adversarial verification) / /icode fast trimmed (1 round, no adversarial). Actual time and cost vary with workload, model and required rechecks.
• Anti-laziness quality gates: triple-phase deepcheck (Reverse/Fixed/Free), plan assertion verification, ADR decision records, adversarial verification (independent skeptics — insufficient evidence is never confirmed, honest downgrade over fake consensus)
• Cross-project history retrieval: init/log/plan/start auto-search similar past tickets and inject by command; references stay in-session, never pollute project artifacts. Verdict-based injection prevents disproved/superseded tickets from misleading new work
• Project-level knowledge base (/icode doc): global per-project/per-branch knowledge base (module docs generated once and reused across projects), auto-retrieved and injected by phase-zero search
• DOCX delivery (/icode docx): faithful Markdown conversion, source-grounded technical authoring and existing Word revision. The workflow covers topic-specific chapters, readable prose, source/call-chain review, complex flow/sequence/coordinate diagrams, shared module colors and layout. A pinned private runtime provides hash/source-map checks, scoped revision comparison and rendering of the final saved file; actual page review is recorded separately from rendering success. Only an ICODE-owned OS/CPU/glibc-compatible renderer is used, never host LibreOffice. Supported Linux x86_64/glibc≥2.35/x86-64-v2 hosts reuse the managed renderer registry; other platforms remain pending. See the DOCX workflow and tools.
• Project work-order backup (/icode bak): snapshot the project's entire .icode_output/ (tickets + debug twins + isolated crosscheck rounds + limit.local + ppt) to global ~/.claude/icode_data/project_backup/, repeatable with hardlink dedup. Run it before deleting a project — once deleted, history retrieval still reads full work orders from the backup (project-first, backup fallback), and /icode list marks them [path_gone→backup]. For closed worktree tickets whose project_path is gone but whose archive_path is valid, /icode list marks them [path_gone→archive] (or [path_gone→archive+backup] when both archive and backup exist)
• Anti-duplicate injection: history retrieval and project-doc retrieval share an injection cache, avoiding repeated injection within one dev chain
• Decision anchors: steps pass concise decision summaries (.decision_anchors.json) downstream — saves tokens, keeps reasoning continuity
• Resumable runs: .ico_metadata.json status + round counters support crash recovery at steps 2/4/5
• Two optional entries: /icode log log root-cause analysis (baseline check first, then adversarial analysis; domain-agnostic) → fix requirement, plus a cross-audience brief at completion — log_problem_brief.md, with a <ticket> prefix (DEMO-26_log_problem_brief.md) when the source is a TB ticket (no icode terminology); /icode init multi-turn requirement draft → 00_init.md
• Project constraint red lines (/icode limit): define this project's forbidden zones / constraints; the plan step treats them as a hard baseline (plan → implementation → audit convergence)

Installation

One public installer

Clone the source into a neutral directory, then use the root installer. It installs ICODE, every shared skill declared by skill-packs/manifest.json, host command adapters, and the MCP servers. The installer keeps default: claude (--client claude); use --client all for Claude Code and Codex together. Use --client codebuddy for CodeBuddy and --client workbuddy for WorkBuddy. With all, CodeBuddy is added only when ~/.codebuddy/ is detected and WorkBuddy only when ~/.workbuddy/ is detected, preserving the historical two-host behavior.

git clone https://github.com/ayukyo/icode-skill ~/icode-skill
cd ~/icode-skill
./install.sh --client all

Use ./install.sh --dry-run --client all for a zero-write preflight, or --skip-mcp when only ICODE and the shared skills are required. ICODE is installed as <skills-root>/icode/; each shared skill is generated from its source template at <skills-root>/<skill-name>/SKILL.md. Source templates cannot be discovered as nested skills.

CodeBuddy scans ~/.claude/skills/, so it reuses that ICODE copy rather than creating a third one. The installer atomically publishes the versioned integrations/codebuddy/commands/icode.md template as ~/.codebuddy/commands/icode.md, providing /icode ...; a separate ownership marker permits identical-file adoption and rejects conflicting unmanaged commands before any Skill root is changed. CodeBuddy MCP entries remain isolated in ~/.codebuddy/mcp.json.

WorkBuddy uses its own skill root ~/.workbuddy/skills/ and its own command bridge ~/.workbuddy/commands/icode.md (same template, ownership marker artifact workbuddy-command); its MCP entries are registered into ~/.workbuddy/mcp.json. --client workbuddy installs all of these; WorkBuddy-specific tool syntax in-session follows the current host's exposed capabilities.

The installer writes an ownership marker into managed skills. An identical unmanaged same-name skill is adopted safely; a different unmanaged same-name skill is refused before either host is modified. Runtime configuration and caches are preserved.

Evidence intake, email export intake (tools/email_intake.py), technical-document intake (tools/document_intake.py), media routing/evidence (tools/media_router.py), the project-local debug catalog, runtime baseline resolution, verification debt, the multi-repo handoff matrix, and /icode learn are bundled ICODE tools/steps. They are copied with the ICODE directory to Claude Code and Codex by --client all; CodeBuddy reuses the Claude skill root. They are not standalone entries in skill-packs/manifest.json. The sixteen reusable cross-project Skills—including email-evidence-intake, technical-document-intake, hardware-spec-contract-audit, schematic-interface-audit, mcu-hardware-software-contract-audit, and the embedded/camera capabilities—remain separately installed from that manifest with the same ownership/hash collision protection.

The historical direct-Claude clone remains supported as a compatibility path. After Claude Code discovers ICODE, run the same unified command:

git clone https://github.com/ayukyo/icode-skill ~/.claude/skills/icode
/icode install --client all

Read-only discovery before installation

To list the root skill from GitHub without installing it into a host, use the Skills CLI discovery command with telemetry disabled:

DISABLE_TELEMETRY=1 npx skills add ayukyo/icode-skill --list

This read-only discovery may download the CLI and repository into temporary/cache directories; a download or a listed skill does not mean installation is complete. Skills CLI parsing does not cover the shared skills, MCP registration, DOCX runtime or CodeBuddy command bridge. Use the official ./install.sh --client all for the full installation described above. A discovery result is not proof of skills.sh indexing; do not repeat installs to inflate counts. See the dated discovery assessment.

Developer update command

Repository contributors can preview and publish the current checkout without running MCP installation:

./scripts/sync-to-global.sh --dry-run --client all
./scripts/sync-to-global.sh --apply --client all

mcp/workflow-gate/skill-routes.json maps ICODE triggers to shared-skill input/output contracts. Optional MCPs still degrade gracefully when unavailable, but the installer reports their installation failure honestly.

Embedded, camera, email, technical-document, schematic, and MCU contract work uses the same public workflow commands. A local PDF/Office/image/text/7z corpus is first checked for real format, structure, archive risks, duplicates/variants, and extraction coverage, then routed to scoped spec, schematic, or MCU auditing. Baseline/document/email/SDK/package content is never executed; protected exports and hardware mutation, measurement, or destructive fault injection retain their authorization boundaries.

Optional Data Source: Read-only Email Evidence

When an existing init, log, plan, doc, deepcheck, audit, or verify request includes bounded webmail links, a thread, .eml, or .msg, email-evidence-intake builds batch acquisition, message/thread identity, quoted-history coverage, resource preflight, attachment routes, analysis, and a bounded verdict. Explicit webmail links use an already logged-in browser by default: log in once, provide the exact links, and ICODE scopes capture to each target mail reading pane, downloads the original message and requested attachments into a managed evidence root, then reuses the existing media, spreadsheet, technical-document, evidence/timeline, schematic, cross-layer, provenance, and field-verification capabilities. No extra public command or IMAP configuration is required.

icode-mail-observe is an optional unattended mailbox adapter for server-side search or runs without a browser; it is not the prerequisite for normal webmail-link analysis. Its IMAP surface selects only allowlisted folders with readonly=True, fetches with BODY.PEEK[], and has no send/reply/delete/move/copy/mark/read/raw-command surface. Its sole managed write saves one selected attachment under the configured evidence root after path, size, hash, and executable checks. If no logged-in browser is available, export .eml/.msg; tools/email_intake.py handles deterministic offline intake, with Outlook .msg reporting an honest optional-parser boundary when extract-msg is not user-installed. Remote images and links are never fetched during intake. Corporate email and derived content are not sent to cheap-research remote capabilities by default.

Optional Data Source: Pull from DingTalk Docs

When an entry command (/icode init / log / plan / start) or the patch step (phase 0, insertable anytime) receives a DingTalk share link (alidocs.dingtalk.com / /i/nodes/{token}), it can auto-pull the doc/drive files into dingtalk_source/ as requirement/reference input. Pull-only, never writes back to DingTalk; native-format docs (.axls/.doci) require the user to export first in the DingTalk UI. Prerequisites: logged into DingTalk docs in Chrome + pip install browser_cookie3. See SKILL.md「方式 H」 and ~/.claude/skills/icode/tools/dingtalk/README.md.

Optional Data Source: Pull from Teambition Bug Tickets

When /icode log receives a Teambition project URL or a <LIB>-<NUM> ticket ref (e.g. DEMO-26) in its scattered input, it can optionally pull the ticket's title / description / comments / log attachments into tb_source/<ID>/ as analysis input — replacing local logs when the ticket carries attachments. Pull-only for analysis, never writes back to Teambition; with no TB reference, /icode log falls back to the pure local-log path (behavior unchanged). Config (optional; multi-project shortcuts + cookie) and the cookie helper: see ~/.claude/skills/icode/tools/tb/README.md and tools/tb/scripts/tb_cookie.py --domain <domain>. Re-running the same ticket (new comments/attachments on TB) prompts "reuse old ticket / create new" — reuse re-pulls the latest and re-runs incremental adversarial analysis. A batch mode also analyzes every "open / unfinished" ticket in a project (triggered by an "analyze all TB" intent; filtered by the real taskflow status name, not isDone) — see SKILL.md「方式 D2 / D3」.

Scheduled incremental monitoring (tools/tb/scripts/tb_watch.py): periodically polls one or more projects' "open / unfinished" tickets (newest ticket number first), and when a ticket gains new comments/attachments/status changes it auto-launches a headless claude session for full /icode log --debug deep analysis (downloads & extracts TB log attachments; artifacts under {project}/.icode_output/.debug/, never touching the global index; first-run tickets are auto-baselined one per round). Config is a JSON file listing projects — the minimal entry is just the project URL; every round it writes a searchable "latest analysis status" report to {project}/.icode_output/tb_watch_report.md, and refreshes it immediately after each triggered analysis completes; tb_watch_ctl.sh start also brings up a read-only web viewer (config web section, default :8000, markdown rendered as HTML) so teammates can browse the report and per-ticket briefs over the LAN without SMB credentials. Config / start / stop / risks: see tools/tb/README.md「定时增量监控」section.

Optional Agent Runtime and Local UI (v0.4)

Run /icode ui (advanced equivalent: python3 tools/icode_agent.py ui) to open the dependency-free local ICODE workbench. It prefers 127.0.0.1:8765, falls back to another loopback port when the default is occupied, opens the browser, and requires no ticket path. Repeating the simple command reuses the live global instance instead of allocating more random ports. The v0.4 dashboard adds status filtering, beginner-friendly action names, a control-plane-backed ticket cockpit, bounded live job events, and restart recovery that marks unfinished work as outcome-unknown without replay. It still offers manual refresh plus configurable automatic refresh (30 seconds by default, 5–300 seconds), stores no prompt or raw output in its recovery file, and can invoke approved ICODE steps through the installed Codex or Claude Code CLI. It does not replace either host's normal chat workflow: every launch is guarded by a current event-chain revision, a control-plane action policy, a validated execution root, persistent Agent spawn/result receipts, and a cross-process per-ticket lock. It accepts no API key, arbitrary path, or shell command, and never automatically commits, deploys, closes tickets, or deletes workspaces. Existing status, run, and ui --dir <ticket_dir> modes remain compatible. See agent_runtime/.

Optional Enhancements

Both are platform-agnostic: point them at any OpenAI Chat Completions-compatible endpoint (OpenAI / Claude / Gemini / Chinese vendors / self-hosted / OpenRouter / local Ollama). Not installing either doesn't affect the main workflow.

Image/Video Understanding (vision-bridge)

cd ~/.claude/skills/icode/mcp/vision-bridge
./install.sh                          # auto: venv + install deps + register to ~/.claude.json
# edit the generated config.json with your base_url / api_key / model
# restart Claude Code to take effect

ICODE uses capability-aware routing rather than forcing every image through vision-bridge. Deterministic text/structure extraction runs first. A host-attested strong multimodal session uses native vision; a text-only or unknown session can use the MCP/CLI bridge; high-risk evidence can use independent dual review, where disagreements remain unresolved. Unknown native capability is never probed by trial image injection. Multi-image inputs, video frames, and page tiles obey a per-message hard limit; overflow is processed in serial batches and only text is aggregated afterward. See references/media_routing.md; bridge profiles may declare only capabilities actually evaluated locally.

Cheap LLM Inference (cheap-research)

cd ~/.claude/skills/icode/mcp/cheap-research
./install.sh                          # auto: venv + install deps + register to ~/.claude.json
# edit the generated config.json with your base_url / api_key / model
# restart Claude Code to take effect

Provides 15 low-risk tools (6 deterministic local tools, 1 untrusted remote fetcher, and 8 optional LLM transforms) for compression, navigation, extraction, and mechanical validation. It never takes over decisions — 3-skeptic adversarial verification, architecture decisions, final audit, and fix proposals stay on the main session (zero gray area). Corporate email text, addresses, images, tables, attachments, logs, and derived summaries are excluded from its remote fetch/LLM capabilities by default; only a separately stated public topic may be researched without explicit provider-and-disclosure approval.

Coverage check (execution gates): each cheap-research call site has a machine-readable gate (mcp/cheap-research/gates.json) and a per-ticket trace ({ICODE_OUT_DIR}/.mcp_gate_trace.jsonl). Run the validator to confirm every eligible gate was actually fulfilled (or legitimately skipped with structured evidence):

python3 tools/lint_mcp_coverage.py <out_dir>              # markdown report, exit 0/1/2
python3 tools/lint_mcp_coverage.py <out_dir> --json       # machine-readable report
python3 tools/lint_mcp_coverage.py <out_dir> --step review --strict

The Other 11 MCPs (4 general + 7 ICODE-local services)

Besides vision-bridge and cheap-research, /icode install installs 4 general workflow utilities and 7 API-key-free ICODE-local services:

• sequential-thinking — the L2/L3 carrier of the tiered reasoning gate: structured 3~5-step thinking before complex / refactor / redesign tasks (L0/L1 steps do not call it; each step lists its required MCPs first, then calls them)
• memory — cross-project knowledge graph (mcp__memory__read_graph), recalled during search/injection so past tickets and project docs resurface across sessions
• context7 — live library-doc lookup during init/plan/code when the requirement touches third-party libraries
• playwright — browser automation during deepcheck/audit for front-end projects
• icode-evidence — SHA-256 identity, line-addressable reads, log timelines, and document-corpus manifests
• icode-workspace — safe unique nested-root resolution, bounded large-repository profiling, static build-entry risk hints, plus multi-Git-root/worktree/build-input/artifact provenance; never executes project build scripts or merge/commit/push
• icode-device-observe — fixed read-only checks through named SSH/ADB/fixture profiles; no arbitrary commands or device writes
• icode-mcp-health — install/upgrade/CI checks for manifests, Python entrypoints, and sensitive fields
• icode-mcp-policy — default-deny step-to-server/tool/operation routing source of truth
• icode-local-index — rebuildable SQLite full-text index for large local corpora; every hit must be verified against the source file
• icode-mail-observe — optional unattended read-only IMAP message/thread intake; ordinary explicit webmail links use the already logged-in browser instead

The seven local services add no public /icode commands; their machine-readable routing source is mcp/icode-mcp-policy/policy.json. Each MCP has an explicit strong-evidence trigger and a declared graceful-downgrade path (see SKILL.md「MCP 工具集」); none blocks the workflow when missing.

Commands

Command	Description
/icode help	Help: commands, natural-language examples, combinations and continuation
/icode log [scattered info...]	Optional entry: deterministic evidence manifest + project-local debug reuse + per-repo runtime baseline → root-cause analysis → fix requirement 00_init.md; auto-generates a bounded cross-audience brief
/icode init [--guide] [<rough req or guide constraints>]	Normal: new Step 0 ticket and multi-turn draft; --guide: reuse the latest eligible init and refresh deliverables/guide.md plus its internal evidence audit
/icode start <req>	Full flow: create/reuse dir → steps 1–6
/icode fast <req>	Trimmed full flow: plan→review(1 round, no adversarial)→merge→code→deepcheck(Reverse only)→audit; no fixed cost guarantee
/icode plan <req>	Step 1 only: draft project plan
/icode review [N]	Step 2 only: review the plan (N=soft cap rounds, default 3)
/icode merge	Step 3 only: merge reviews & finalize
/icode code	Step 4 only: implement code
/icode deepcheck	Step 5 only: three-phase progressive check (Reverse → Fixed → Free)
/icode audit	Step 6 only: final audit + fix (produces 06_audit.md)
/icode readme	Optional Step 7: one call, two docs — full report (for yourself) + _brief.md (concise, for other modules' dev/test/PM, key changed code included)
/icode patch [issue or new need]	Follow-up modification (standalone step): keep modifying an existing ticket after/between main steps — test findings / new needs. Lightweight 4-phase (re-survey → incremental plan → minimal change → reverse re-check), context reloaded from disk artifacts (continuable across sessions), appended to 08_patch.md; optional --listen auto-monitors an on-device deployment; configure ~/.claude/icode_data/device_config/<project_id>.json (template templates/device_config.json.template, single-file multi-conn adb/ssh/serial)
/icode crosscheck [--ticket <id>|<ticket path>]	After switching Agent/model yourself, independently re-review a completed ticket. Appends project-local rounds under .icode_output/.crosscheck/; never writes the target ticket/code or auto-runs patch
/icode verify [--build] [--deploy] [--listen|--test <target>] [natural language] / /icode verify --plan [--ticket <id>]	Explicit stages run in build → deploy → listen/test order; each standalone flag runs only its stage. No flags means interpret natural language before acting. Each executed stage records a verification run; plan writes only a plan. No mode auto-upgrades delivery_verdict.
/icode learn [--project <path>] [--ticket <id>] [--since <ISO-8601>]	Project-scoped learning report from real skill-run observations; classifies reuse/composition/improvement/new-skill/tooling/no-action and never edits or publishes a Skill in this step
/icode study [--ticket <id>] [--library <dir>] [topic]	Turn a ticket's real code changes into self-contained technical chapters with diagrams or tables; save to each user's configured knowledge library (config template), with private source records outside it; never commits or pushes
/icode doc [natural language]	Project-level knowledge base (standalone step), auto-injected at phase zero
/icode docx [natural language]	Standalone faithful Markdown conversion, source-grounded Word authoring or existing Word revision; chapter/prose/diagram/layout work, source verification, scoped comparisons and final page review; explicit output locations take precedence
/icode limit [natural language]	Project constraint red lines (standalone step); hard baseline for the plan step
/icode ppt [natural language]	PPT generation (standalone deliverable step): natural language → real .pptx for project / module / current feature dev / current bug fix; content sourced from icode artifacts & knowledge base (no fabrication), 8 built-in templates (tools/ppt/templates/, the AI shortlists 2-3 style-matched candidates and the user picks; user may also name a template directly), editable edits.json for re-run; outputs to <project_root>/.icode_output/ppt/ (outside any ticket dir); needs pip install python-pptx (LibreOffice+poppler optional for PNG preview). Built-in templates are non-commercial (see tools/ppt/NOTICE)
/icode status [--pending]	Query current ticket status or generate a read-only cross-ticket verification debt report (--verdict remains the explicit annotation mode)
/icode list [keywords]	Cross-project ticket search (pure read-only)
/icode worktree --update [--target <ref>]	Worktree lifecycle (standalone): controlled migration of the active implementation checkout to a new one on the latest/specified baseline — 11-phase state machine, failure keeps the old active root, interrupt-recoverable & idempotent. Switching baselines must go through this command (no silent pointer changes); multi-subrepo handled as one transaction
/icode worktree --close	Worktree lifecycle (standalone): after you've committed/pushed/merged — verify online evidence → mark submitted → safely clean up checkouts → record submitted_baseline. Never commits/pushes for you; never deletes unique uncommitted code or unarchived artifacts; idempotent
/icode worktree --reopen [--target <ref>]	Worktree lifecycle (standalone): explicit restore for a closed completed ticket — create a new active checkout on the latest online baseline (no new ticket, patch history kept). Closed tickets must reopen before patch
/icode worktree --merge	Worktree lifecycle (standalone): fetch every contracted online target, preflight all repositories, safely fast-forward or leave a conflict-free uncommitted merge, then recheck; never commits or pushes

Full command details (incl. "Creates Dir?" column + reuse rules + --verdict/--scan flags): see the SKILL.md Commands section.

Execution / Directory Structure / Workflow

Execution (main session + no automatic model switching) + Directory Structure (.icode_output_N/ output layout) + Workflow (Steps 1→6 data-flow + fast-mode branch + reuse rules): see the SKILL.md General Rules section.

Demo

demo/ is a minimal C calculator project (calc.h / calc.c / main.c / Makefile), purpose-built for end-to-end testing of the icode workflow — all five invocation modes (A full-flow / B step-by-step / C init→start / D log→start / E fast trimmed) can be run against it.

cd demo && make && ./calc_demo   # confirm the baseline builds and runs

Example test requirements:

• Mode A: cd demo && /icode start add modulo and power operations to the calculator, plus integer overflow checks
• Mode B (step-by-step): cd demo && /icode plan add isqrt to calc.c then /icode review /icode merge /icode code /icode deepcheck /icode audit
• Mode C (init then start): cd demo && /icode init add new feature to calculator (multi-turn dialogue to clarify) → /icode start
• Mode D (log then start): cd demo && /icode log <log_path> "symptom" → outputs root cause + fix requirement → /icode start
• Mode E (fast trimmed): cd demo && /icode fast add isqrt to calc.c (time depends on the task and required rechecks)

License

MIT — see LICENSE.

---

中文文档