Skip to content

Context Circuit CLI 2.6.0

Latest

Choose a tag to compare

@github-actions github-actions released this 11 Nov 05:17
· 11 commits to main since this release
1720ba4

Context Circuit CLI 2.6.0

A minor release. The workspace schema stays at 3, and nothing is renumbered.

Upgrade notes

Nothing to do unless you use extensions: a workspace without extensions.yaml behaves as before. An extension's scripts run only after each member allows them on their own machine with extension allow --id ID, and an override changes nothing until a person allows it with extension override. (#235, #236, #238)

Run agent setup after pulling a workspace whose extensions add roles or skills, and add the new x-* skill paths from the template's .gitignore. (#237, #239)

Added

Agents now write intents, plans, approval and completion notes, and the chat around them from one new skill, cc-writing, so they open with the point, connect their ideas, and in Bahasa Indonesia compose rather than translate. Each member can pick a tone with member tone --preset colleague, casual, formal, or non-technical, and member presets lists them with the line each records. A member with no tone is written for as colleague. A tone never reaches context/ notes, the catalog, or the glossary, which stay English. Existing workspaces need no migration, and a tone you already wrote keeps working. (#228)

Type /ff to bring your local base branches up to date: the agent fast-forwards every bound repository and the workspace, or only the ones you name (/ff api, /ff workspace), and reports what moved and what it left alone and why. The workspace is skipped when it holds any uncommitted file, and the code repositories are still updated. When you tell the agent your merge or pull request was merged, it now offers in one reply to update those repositories' base branches and to mark the delivered plans completed; one yes does both, and saying "merged" alone changes nothing. In Codex, ask in words instead of typing /ff. (#231)

repo sync and workspace sync bring this machine's base branches up to date after a merge. repo sync fetches, then fast-forwards the base branch of each repository you name with --id, or of every bound one, and reports one status per repository: updated, current, ahead, diverged, blocked by uncommitted changes, checked out in another worktree, or why nothing moved: no local base branch, no remote or upstream, not bound here, or a failed fetch. It never switches the branch you have checked out, and never merges, rebases, resets, stashes, or discards. workspace sync does the same for the workspace's own repository, but only when it has no uncommitted file at all; once it moves, it says to run check and names a pinned CLI version that moved with it. (#231)

Workspaces can now use extensions: folders of instructions that add work before and after each stage — writing an intent, approval, planning, preparing a worktree, implementing, review, delivery, completion, and archiving — for the whole workspace or for chosen repositories, without changing the template. List them in extensions.yaml with extension add, from a folder in the workspace or a Git repository pinned to the commit its tag or branch names; each member can switch one off unless its author made it required. The agent runs extension hooks at the stages it carries out, record approve, worktree prepare, record complete, and record archive return the instructions for their own stage, and dispatched planners, workers, and reviewers receive theirs in their brief. Every hook that does not apply is reported with its reason, and no extension can authorize a push, a merge, or anything else that needs your say. status counts the extensions on for you and check validates them. (#235)

Extensions can now run scripts at their hook points, not only give the agent instructions. A script runs only after you ran extension allow --id ID on your machine for that exact version — the commit of a remote extension, or the contents of a folder in the workspace — and any change to it asks again; allow shows each script, what happens when it fails, and what it does beyond your machine, and runs nothing. extension list shows whether each extension is allowed, not allowed, or changed since you allowed it. Each hook declares whether a failure stops the stage or is only reported, and whether it needs your consent: standing scripts take the one action their manifest names once you have allowed them, and each-time scripts wait for your yes every time. record approve, worktree prepare, record complete, and record archive run their own stage's scripts without holding the workspace lock, and a failing before script with on_failure: stop leaves the command undone. On Windows a hook runs its run_windows command, and a hook without one is skipped there. (#236)

Extensions can now add agent roles and add to the shipped ones. A manifest's roles declare a role with its description, read-only or edit access, the stages it serves, the shipped role it is like for model and effort, its instructions, and the headings it returns. agent setup installs each role of an extension on for you beside the shipped four, as cc-x-<extension>-<role>, and agent dispatch --role x-<extension>-<role> briefs it like a shipped role, with limits no instruction lifts. role_additions add instructions and return headings to the explorer, planner, worker, or reviewer through their brief, without changing their definition or access. After an extension change, extension add, update, remove, enable, disable, sync, and status return setup_required until agent setup runs again; setup removes a definition whose extension is gone or off unless you edited it, and its result now lists the files written, removed, and kept. check reports a role or addition that is not valid, and two extensions adding the same heading to one role. (#237)

status now lists, under each of your open plans in my_work, the worktrees this machine prepared for it: the repository, the worktree's path, and its branch. A plan's branch lives in the repository the plan names, not in the workspace's own, so this tells an agent where to look for a plan's work. (#237)

An extension can now ask to change one of four core defaults, and a person can allow it for their workspace: repair-loop (implement, verify, and fix until clean or a round limit), verify-during-execution (a read-only role checks each implementation once), risk-review (the reviewer runs when the extension's instructions say a change warrants it), and delegation (a stage always goes to a named role). A manifest declares the overrides it wants under overrides, and extension override --id ID --allow NAME [--rounds N] allows one, or --revoke NAME takes it back; --rounds can lower a repair loop's limit but never raise it. An allowed override comes back from extension hooks under overrides, status lists each one and whether it is on for you, and agent dispatch --override NAME [--round N] accepts the verifier, the fixing worker, or the reviewer it needs and refuses any other use. Approving an intent, authorizing pushes and merges, starting planning and execution, leaving the plan record alone, no attribution, no secrets, and read-only borrowed knowledge stay fixed: a manifest naming any of them is invalid. check reports an allowance the manifest does not declare, rounds out of range, a verifier that is not read-only, and two extensions delegating one stage to different roles. .context-circuit/docs/customization.md describes the overrides and the repair loop. (#238)

Extensions can now ship skills. A manifest's skills names each skill's folder, which holds a SKILL.md with name and description, and agent setup installs each skill of an extension on for you as x-<extension>-<skill>: a copy under .agents/skills/, which Codex reads, and a one-line wrapper under .claude/skills/ and .cursor/skills/. These are gitignored and regenerated on each machine, never replace a shipped skill, and are never touched by a template update; setup keeps a copy you edited and removes one whose extension is gone or off. A skill runs on your request, or when a core hook instruction names it, never on its own. A skill may declare a named stage, which other extensions hook as before|after <extension>/<stage> and the skill runs with extension hooks --stage <extension>/<stage>; a stage whose extension is not listed or is off for you is skipped with that reason, and named stages never join the core lifecycle. status lists extension_skills and named_stages, extension list names each extension's skills and stages, and check reports a skill that is not valid and a hook at a named stage no listed extension declares. (#239)

Changed

An approval or completion note is now written in the record's language, English unless the author's member entry says otherwise, and states the decision: what was approved, the answers to open questions, conditions, and extra asks. It no longer pastes the person's reply, which may be in the language of the conversation. The conversation itself is unchanged: replies, approval confirmations, and summaries stay in the language the person is using. (#226)

Contributors

@hallode, @kaotypr


Built at commit 1720ba41f54f9993db50e90d0df3d7bd83e41b86.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.