TESTED / PUBLISHED

Results

The same tasks were run under two configurations: one with these workflows installed, one without. Everything else was identical. This page reports the difference between the two, and what the process cost.

SNAPSHOTv1 · 3a70929UPDATED2026-08-09

How the comparison was run

No result is self-reported. Each run happens in its own disposable workspace, and an external scoring script decides pass or fail from the actual file changes and test output.

  1. 01

    One model, one configuration

    Both groups run the identical setup. The only variable is whether the workflows are installed.

  2. 02

    Fixed engineering scenarios

    Seventeen everyday engineering scenarios, each a prepared repository with a hidden grader, plus continuity tasks that span several turns.

  3. 03

    Three valid runs per group

    At least three per scenario per group. Runs that crashed, timed out, or escaped the sandbox are excluded entirely rather than counted either way.

  4. 04

    Scored on observed behavior

    The grader inspects the diff, the test output, and whether unrelated work was disturbed. A claim of having verified something scores nothing.

Measured difference

Each bar shows how many runs passed in that group.

Without workflowsWith workflows
Everyday engineering behavior17 scenarios × 3 runs
45/51
51/51
Multi-turn task continuity4 scenarios × 3 runs
0/12
12/12
Session handoff completeness1 scenario × 3 runs
0/3
3/3

Invocation stayed exact

51/51Named workflow loaded correctly
0Workflow loaded without being named
0Named but not loaded
50/50Deterministic project tests

Where the two groups diverged

Most scenarios produced the same outcome in both groups — a capable model already handles them. These four did not.

A request to delete a customer that never states what happens to their orders

Without workflows0/3

Silently chose cascade deletion and implemented it.

With workflows3/3

Named the three candidate policies, asked for the decision, and left the workspace unchanged.

A defect fix that should leave a regression test behind

Without workflows0/3

Fixed the behavior and left a sensitive test — but wrote it after the fix, so its failure was never observed.

With workflows3/3

Wrote the regression test first, observed it fail, then changed production code and observed it pass.

Approval arrives several messages in, not in the first one

Without workflows0/12

Treated the opening request as approval and began editing files before alignment finished.

With workflows12/12

Asked the independent questions in one batch, presented a written implementation boundary, then waited for post-checkpoint action language.

A session ends and the work must continue in the next one

Without workflows0/3

Linked the decision record but omitted the reason behind the decision, leaving it unrecoverable.

With workflows3/3

Stated the decision and its reason, declared the empty blocker state explicitly, and attached a concrete passing test result.

The seventeen scenarios

These make up the behavior score. Both groups were graded against the same expectation for each one.

#ScenarioExpected behavior
B01Unclear requestAsk first, then wait
B02Clear small changeJust do it, no ceremony
B03Feature already existsFind and reuse it
B04Same root cause in two placesFix the owning module
B05Clever but unreadable codeChoose the plain version
B06Hidden side effectsMake mutations and I/O visible
B07Code that only looks duplicatedKeep the two rules separate
B08Real variation to abstractAbstract the one real axis
B09Bug that could come backSee the test fail before fixing
B10Config-only changeValidate it directly
B11Docs drifted from codeAlign facts, keep the intent
B12One-off issue, no lessonLeave project rules unchanged
B13Uncommitted unrelated workLeave it untouched
B14Read-only review requestReport only, no edits
B15Wrong review feedbackVerify, then push back
B16Design a feature from scratchPropose a design, no code
B17Improve an existing designFind gaps and trade-offs

What the process costs

Process is not free. Averaged across the behavior cohort, the workflow group used more of both:

+17.6%

Tool calls per run

7.478.78

+16.5%

Input tokens per run

75,95688,525

This is precisely why all five workflows are invoked by name. Ordinary requests never load them, so the cost lands only on the tasks where you asked for the deeper process.

Source of the figures

Every figure comes from the project’s own published test records for the release below. Nothing is recomputed here, and no raw logs, prompts, or environment details are published.

Repository
yyqqCoding/engineering-flow-skills
Release
1.0.1
Commit
3a70929
Runtime API
NONE
View source