v2.12.0

Sync to Forge plugin v2.12.0.

Changed

• A snoozed session is not asked again. After you snooze session tracking, Forge no longer asks every few turns whether to keep a record. A wake condition you chose is still checked, and you can ask Forge to track the session at any time.
• Approaches Forge works out start straight away. When Forge works out an approach for a request no workflow covers, it shows the approach and starts it in the same turn, without a separate Start question. You can stop it or change its steps at any time.

Diff: #43

v2.11.0

Sync to Forge plugin v2.11.0.

Changed

• Workflow authoring no longer proposes a per-workflow AI coding policy. The field was retired from the workflow-save format; workflows that already have one keep it.
• The marketplace version is 2.11.0, matching the plugin.

Diff: #42

v2.10.0

Sync to Forge plugin v2.10.0.

Changed

• Authored workflows can require the skills your project's own instructions require, on the step where those instructions require them, as well as the skills found in every repository.
• No team question when your plan has no team workflows. When your org's plan doesn't include team workflows, the authoring skill no longer asks where a new workflow lives: it saves it for the whole org and says so in one line. If the plan can't be checked, the question is asked as before. A team-scoped save the plan doesn't allow is explained plainly, with an offer to save for the whole org instead.
• The marketplace version is 2.10.0, matching the plugin.

Diff: #41

v2.8.0

Sync to Forge plugin v2.8.0.

Changed

• "Keep a record?" is asked at most once a session. After you decline it, Forge doesn't offer it again later in the same session. You can still ask Forge to track the session yourself, and the next session asks afresh. A snooze you chose ("remind me later") still comes back.
• Helper agents keep working while Forge waits for your answer. While a Forge question is open, an agent the main conversation started can still read, search and run checks. Its writes stay held until you answer, as the main conversation's are.
• Workflows you author no longer need a closing feedback step. Every run's recap already says how to send feedback, so the authoring skill doesn't add one. A baseline that has one keeps it unless you ask to drop it.
• Removing an org's workflow configuration says what really happens. Most built-in workflows stop running when their org configuration is removed, but a built-in that ships switched on keeps running, and the authoring skill now says so. A configuration that only switches a workflow on, renames it or limits who sees it is no longer treated as a broken override.
• The routing skill names GPT-6.1 Terra for balanced Codex steps, in its model-routing example.

Added

• README: how to have Claude Code ask before destructive commands. A settings snippet with ask rules for commands that are hard to take back, such as git push, git reset --hard and rm -rf. It only adds a confirmation; nothing is blocked.

Fixed

• A workflow started in the middle of another no longer strands the first one. The earlier run is held while the new one runs, with its own question and write lock, and it comes back when the new one ends. Previously it was refused until it was recovered.

Diff: #40

v2.7.0

Sync to Forge plugin v2.7.0.

Changed

• A documents step can save its approved document into the repository. When a step that writes documents routes an approved document into your repository, the agent may create or update that one document with Write or Edit, following the layout of the documents around it. It does not edit application code or configuration, and it does not commit, push or open a pull request to deliver it. A pointer on the ticket still needs the step's own tracker permission.
• Code-editing permission is described as covering application code and other repository edits beyond that single document.
• Question guidance for Codex was revised. The routing, workflow-authoring and feedback skills carry an updated rule for Codex's question tools; it does not apply on Claude Code, which keeps its built-in question tool.

The repository-document guidance takes effect once the matching Forge server update is live; until then, behaviour is unchanged.

Diff: #39

v2.6.0

Sync to Forge plugin v2.6.0.

Added

• Large workflow catalogs are read in full before Forge says nothing fits. When the list of workflows is too long for one reply, Forge sends it in pages or with shortened entries, and the routing skill tells the agent how to read the rest: the remaining pages, or the full detail of a few workflows. If a reply arrives cut short, the agent reads the catalog again before it reports that no workflow covers a request or offers to build one.

Changed

• Forge's questions use the host's own question controls when they are compatible and permitted. The routing, workflow-authoring and feedback skills now give one rule for asking: use a native control that fits the question, keep every choice, and show numbered choices when no such control can be used. On Claude Code this is still the built-in question tool.
• Saving or deleting a workflow, and sending feedback, follow only an explicit answer. The skills show the complete proposal or payload before they ask, act only on an explicit confirmation of what was shown, and ask again when it changes. A preselected default never counts as a yes.

Fixed

• A question that was only delivered, or a question call that failed, no longer counts as the user having been asked. Forge refuses an answer to one of its questions unless the question reached the user first, so an answer cannot be posted on their behalf. On Claude Code the built-in question tool already waits for the answer, so nothing changes in practice.

Reading large catalogs in pages needs the matching Forge server update; until it is live, behaviour is unchanged.

Diff: #38

v2.5.0

Sync to Forge plugin v2.5.0.

Added

• Workflow authoring starts from how your org works. When Forge has a picture of how your team defines, builds, reviews and releases work, the authoring skill starts from it: its first question or proposal cites what it found, and a team skill is required on a step only when every surveyed repository has it. Skills found in fewer repositories are named as "use when present".
• A request no workflow covers can still be worked out with Forge. Forge proposes steps that fit the request, and the agent shows them to you and asks before anything starts; it never confirms them on your behalf.

Changed

• The workflow-authoring skill follows the authoring rules the Forge server sends, so they can change without a plugin update.

These features need the matching Forge server update; until it is live, behaviour is unchanged.

Diff: #37

v2.4.0

Sync to Forge plugin v2.4.0. The marketplace version is 2.4.0 to match.

Added

• Authored skills say what they need to read. When an admin authors a workflow with a new skill, the proposal states what that skill must read before it runs (a linked ticket, the repository) and why. A capability that depends on one of those reads gets it added, and the check runs again before the save. On an older Forge server the existing settings are kept as they are.

Changed

• Workflow authoring asks its fixed-choice questions together. Where the workflow lives, who can run it, and whether the draft looks right go into one question widget instead of being asked one by one. Scope is always asked: when no teams are found, the skill says so and still asks.
• The model-routing example names gpt-6.1-sol.

Fixed

• A finished workflow is no longer left looking active. When two hooks wrote session state at the same moment, the one recording a workflow's completion could give up and lose it, leaving the finished run holding its write lock until the next re-sync. The tracker hook now waits for the other write to finish.

Diff: #36

v2.3.5

Sync to Forge plugin v2.3.5.

Changed

• Workflow authoring presents its proposal in plain language: each new step is described in a few sentences instead of having its instructions pasted in, internal field and payload shapes stay out of it, and it uses plain Markdown. The exact instruction text is still available on request.

Fixed

• Saving a brand-new workflow no longer warns that it will stop receiving Forge's updates. That warning now appears only when the save overrides an existing workflow.

Diff: #35

v2.3.4

Sync to Forge plugin v2.3.4. v2.3.3 was not released separately; its changes ship here. The marketplace and plugin manifests both report 2.3.4.

Fixed

• Resumed workflows keep their safeguards across long pauses and new sessions: a pending question still waits for your answer, and a step set to "Always asks" still holds writes until its plan is approved.
• A session no longer stays held on a workflow that has ended. The hold releases as soon as the server confirms the run is gone, with a bounded backstop of the run's idle window plus 12 hours.
• A new session that asks about an unknown or expired workflow no longer holds writes.
• A failed Forge update (a lost reply, a timeout, a server error) holds writes until the next state recovery. A deliberate server refusal does not.
• Failed Forge calls are now read from Claude Code's tool-failure hook, so the two fixes above also apply when a call fails.
• Stale session and recovery files are cleaned up even when one of them is corrupt.

Changed

• An agent started in a separate session recovers the workflow once before its first update.
• Works with servers that predate configurable workflow expiry; recovery metadata is used when the server provides it.

Diff: #34