The New ACT Core Skills

As of July 2026, the old /act-workflow-* skills are deprecated, and have been replaced by a new set of skills, which expand the capabilities of the ACT workflow.

The new workflow is not just a command rename. It changes how context moves through a project: clarify the request, write durable requirements, create bounded Work Items, then implement one Work Item at a time.

Deprecation notice

The old /act-workflow-* skills remain available for compatibility, and you can use them to complete any existing work. They will be removed in a future version of ACT.

Benefits of the New Workflow

Migrate if you want clearer requirements, local or GitHub-backed workflow storage, reduced workflow token overhead, and explicit Flutter/Dart guidance only when you need it.

Local or GitHub storage

The legacy workflow assumed local workflow files. The current workflow lets each project choose where Specs and Work Items live.

Run act-config once per project to create .act/config.yaml, then choose one storage mode:

Storage mode	What ACT writes
Local Markdown	Specs, Interview Ledgers, and Work Items under the configured local path
GitHub Issues	Specs and Work Items as GitHub Issues

ACT uses GitHub storage if the repo has a GitHub origin, and local Markdown files otherwise. This is configurable when act-config is called. Once a Spec is created (whether locally or on GitHub), the corresponding Work Items will be created in the same storage location.

GitHub mode is intentionally scoped to workflow artifacts. It does not add labels, Projects, issue closure, PR lifecycle, or merge automation.

See Project Setup for the storage configuration details.

Better requirements traceability

The old /act-workflow-spec skill combined clarification and spec writing in one large flow. The current workflow separates those jobs:

1. act-interview resolves intent, constraints, tradeoffs, and decision dependencies.
2. act-create-spec turns the conversation into a Spec and Interview Ledger.

A Spec is the requirements document: what should be built, what is out of scope, what constraints apply, and how success will be verified.

An Interview Ledger records the important Q&A that shaped the Spec. It is not a transcript and not a second Spec. It gives humans and agents a short trace of why key requirements exist.

This matters because later workflow stages can point back to the exact Spec sections and Interview Ledger decisions they cover, instead of relying on stale chat history.

Smaller, safer implementation slices

The old /act-workflow-plan was designed to create multi-phase plans that could be implemented by /act-workflow-work in one or multiple runs. But this approach had some drawbacks:

• unclear dependencies between phases
• hard to parallelize separate phases
• too much resulting complexity in the /act-workflow-work skill
• high token usage and implementation drift for large plans

To address these problems, the new workflow introduces a /act-create-issues skill that creates Work Items: independently executable implementation tasks with scope, acceptance criteria, dependencies, blockers, and verification steps.

Before writing Work Items, the agent proposes the breakdown so you can review granularity, order, dependencies, and coverage. After approval, each Work Item carries enough context to be handed to an agent or human without reopening the whole planning conversation.

act-implement then focuses on one Work Item per run. This keeps coding sessions smaller, reduces scope drift, and makes verification easier to review.

Core skills and Flutter variants

The current workflow separates platform-agnostic behavior from Flutter/Dart-specific behavior.

Use the plain skills for general work. Use the -flutter variants when the project or task is Flutter/Dart:

Stage	General	Flutter/Dart
Interview	/act-interview	/act-interview-flutter
Create Spec	/act-create-spec	/act-create-spec-flutter
Refine Spec	/act-refine-spec	/act-refine-spec-flutter
Create Work Items	/act-create-issues	/act-create-issues-flutter
Implement	/act-implement	/act-implement-flutter

This keeps the default workflow lighter for non-Flutter projects. For Flutter/Dart work, the wrapper skills add attention to user-visible states, navigation, platform behavior, state management, testing seams, and Flutter verification defaults.

Token savings

The current workflow also reduces fixed skill-source size. Smaller skill files mean less workflow text is loaded before the agent even starts reading your project or task context.

A count of fixed skill-source files shows these savings:

Workflow set	Savings
Old Workflow vs new Core skills	49.0%
Old Workflow vs new Core + Flutter wrapper skills	33.4%

The largest reductions are in implementation and Work Item creation:

Replacement	Savings
/act-workflow-work to /act-implement	95.8%
/act-workflow-plan to /act-create-issues	65.1%

The Spec path is intentionally larger because interview and spec writing are now separate, and because the workflow preserves the Interview Ledger. That tradeoff adds structure before implementation, while the later stages become much smaller.

In real sessions, additional savings come from progressive disclosure, because many of the new skills only load additional guidance from reference files when needed.

Token savings disclaimer

These are static skill-source counts, not a guarantee that every end-to-end session will use exactly this many fewer tokens. Real session usage still depends on task size, codebase context, and how much clarification is needed.

Updated Workflow

The new workflow pipeline is:

Interview -> Create Spec -> Refine Spec -> Create Work Items -> Implement

For all the details, see the Workflow Overview.

Why migrate now

Use the current workflow for new work because it gives you:

• Durable context from Specs, Interview Ledgers, and Work Items.
• Clear review points before writing requirements, creating Work Items, and implementing code.
• Smaller implementation sessions that focus on one bounded task at a time.
• Storage choice between local Markdown and GitHub Issues.
• Flutter-specific behavior on demand through explicit -flutter variants.
• Lower fixed workflow overhead from smaller current skill files.

Legacy Workflow Migration

Deprecated skill	Use instead
/act-workflow-spec	/act-interview followed by /act-create-spec
/act-workflow-refine-spec	/act-refine-spec
/act-workflow-plan	/act-create-issues
/act-workflow-work	/act-implement
/act-workflow-compound	No current replacement. Deprecated and retained for compatibility only.

For Flutter/Dart projects, use the matching -flutter variants such as /act-create-spec-flutter, /act-create-issues-flutter, and /act-implement-flutter.