Formulation
Formulation in Cycle Intelligence turns the test specifications produced by Discovery into runnable Cycle tests. You point your AI coding agent at the folder of specifications, choose which ones to convert, and the agent authors a Feature File for each one. This is the Formulation phase of the Cycle Testing Process: specifications go in, CycleScript comes out.
Like Discovery, this flow runs through your coding agent using the Cycle MCP Server, so the agent does the authoring while you review and steer.
Why use it?
A folder of clean test specifications is not yet a test suite. Someone still has to read each specification, find the right Cycle steps, work out the locators and variables, and write the CycleScript. That is slow, and it is where detail gets lost.
Running the conversion through your agent gives you:
- Triage before effort: Every specification carries a readiness signal, so you convert the ones that are ready and set the thin ones aside instead of discovering the gaps halfway through authoring.
- One test per specification: Each specification maps to exactly one Feature File, so coverage stays traceable back to its source.
- No duplicated work: Each generated test records which specification it covers, so a later run skips anything already converted.
- Honest gaps: A specification too thin to convert produces a stub with the open questions written into it. The agent does not invent steps to fill a hole.
- A path to a passing test: A generated test can be validated against a sandbox, then finalized against a live environment, using the same execute-and-debug tooling Cycle already provides.
How it fits
The flow has four stages, and each one has its own page:
- Reviewing your test specs: Browse the specifications and triage them by readiness.
- Generating the tests: Select specifications and let the agent author a Feature File for each.
- Validating a generated test: Confirm a test parses, resolves, binds, and executes against a sandbox.
- Finalizing tests against a live environment: Run the converted tests against a live WMS to sign them off.
One guided prompt covers the first two stages.
Run generate-tests-from-specs without naming any specifications and the agent reviews the bundle with you, helps you choose, and then generates.
Name the specifications up front and it goes straight to generating.
The last two stages have no prompt of their own. Ask for them in plain language when you are ready, and the agent calls the tool that performs each one. The prompt does not move you on to them automatically, so treat validating as a deliberate next step rather than something that happens for you.
Stages 1 through 3 are the normal loop. Stage 4 applies when you have a live Blue Yonder environment to finalize against.
Prerequisites
- A supported AI coding agent wired up to the Cycle MCP Server. See the setup guide.
- A signed-in Cycle account. The Cycle step catalog and every other MCP capability except sign-in require an authenticated session, and the agent cannot resolve steps without it.
- A folder of test specifications on disk, produced by Discovery. This is the
Test-Specsfolder in your Cycle project. The MCP tools refer to it as the bundle root. - A Cycle project with a
Test Casesdirectory to write the generated tests into.
Validating and finalizing have additional requirements, because they execute tests rather than author them. Each of those pages lists what it needs.
This flow shares Discovery's current focus on Blue Yonder Warehouse Management System (WMS) documentation. Finalizing against a live environment is Blue Yonder only.
Outcomes
Once you have worked through the four stages, you have a set of Feature Files in your Cycle project that trace back to the source documentation, a record of which specifications are covered, and a clear list of the specifications that still need a human decision. From there the tests are ordinary Cycle tests: run them from the Cycle Testing Kit, add them to a playlist, or refine them in your editor.
Start with Reviewing your test specs.