agentleFS
Sign inStart free
ffrolivaffroliva/gflow-cli/skills/optimize/SKILL.md

optimize

Skill396 starsChanged 2 months agoMITView on GitHub

Make gflow-cli's tests and CI fast without weakening them: measure the wall clock, find what dominates it, and apply the lever that fits the scenario (cut a per-test cost, -n workers, shards, rebalancing, profile clones for live e2e, cancelling superseded runs). Targets: CI in 3-5 minutes, the local offline suite in 3 minutes, live e2e as close to the slowest single generation as parallelism allows.

78 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use arrange, teach-impeccable and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • HK-hubSkill

    arrange

    Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.

    Also in 14 projects that use this

  • HK-hubSkill

    teach-impeccable

    One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.

    Also in 17 projects that use this

  • zwy123zwySkill

    normalize

    将用户随意输入的提示词规范化为结构清晰、便于大模型执行的标准化提示词。适用于需要整理、统一提示词格式时调用。

    Also in 19 projects that use this

  • open-coder-aiSkill

    policy-init

    Create conformant Chock policy from request. args(request, target_path,

    Also in 3 projects that use this

  • +8 more from HK-hub

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 75 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When a single test is itself slow, cut its cost first.

    line 36
  2. Very specific:

    Measure the wall clock and its critical path: Never guess, never --durations alone (it cannot tell setup from a wait from code under test).

    line 41
  3. Distinctive:

    Next step: after an optimisation lands, re-measure on the next 5 CI runs and announce whether the target holds.

    line 102

“Common” is measured: kept by at least 6 in 10 of the 75 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/gflow:optimize [ci | local | e2e] — test and CI speed

gflow reverse-engineers a black box, so its quality rests on running tests often: the offline suite on every commit and the live e2e suite on every change to a Flow surface. A slow loop is a quality problem, because slow tests get run less. This skill is how speed work is done here.

Targets (owner rules):

  • CI: 3-5 minutes wall time per run, on PRs and pushes to develop. Outside that range, optimise before other work.
  • Local offline suite: 3 minutes (the global test SLA).
  • Live e2e: as close to the slowest single generation as parallelism allows. An image takes about 1-2 minutes and a video 2-4 in Flow itself; that is the floor for a test that generates. Everything around it (browser launch, page load, fixed waits, running tests one after another) is ours to remove.

The rule that does not bend: never weaken

A speed change never skips, deselects, xfails or marks a test slow to get it out of the run; never loosens or deletes an assertion or shrinks a test's data; never raises a timeout to hide a wait. Every test that ran before still runs, and still checks the same thing.

What is allowed and expected here, unlike in a generic speed rule: adding workers (-n), adding shards, rebalancing shards, and cloning profiles for e2e. gflow's e2e time is mostly model latency we cannot remove, so running tests concurrently is the main lever, not a dodge. When a single test is itself slow, cut its cost first; parallelism hides a cost, it does not remove it.

The protocol

  1. Measure the wall clock and its critical path. Never guess, never --durations alone (it cannot tell setup from a wait from code under test).
    • CI: gh run list --workflow CI --json databaseId,createdAt,updatedAt,event -L 20 for wall time per run; gh run view <id> --json jobs for each job's start and end. Separate queue time (waiting for a runner) from run time.
    • Local / e2e: run with --junitxml=<dir>/report.xml, then rank files by share of their worker: python -m scripts.ci.pytest_speed rank <dir> --root . (config: pytest-speed.toml).
  2. Name what dominates, in one sentence, with the number: "the critical path is shard 2/3 at 2m40s, 70 s more than the others", "e2e is 106 tests x ~32 s run one at a time".
  3. Pick the lever from the table below that removes that cost. One lever per change.
  4. Prove it with a red test when the change is to a test or fixture (the speed fix must not change what the test checks), and A/B it: at least 3 runs before and 3 after on the same machine or runner class. One run each is noise.
  5. Record the before/after numbers and the decision in the PR body, and in the active plan's decision log when there is one.

Levers

LeverUse whenHow, hereWatch
Cancel superseded runsDevelop pushes queue behind each otherconcurrency: in .github/workflows/ci.yml (in place; never cancel on main)A burst of merges still queues; merge in sequence
Remove duplicate jobsTwo jobs run the same testsCompare job test lists; fold, keep one source of coverageRequired-check names in branch protection
Workers (-n)One process is CPU- or wait-bound and tests are independent-n auto --dist worksteal in CI; -n 8 --dist worksteal locallyA test that passes alone but fails under -n shares state: fix the state, never serialise it away
Rebalance (--dist, shard split)One worker or shard finishes far later than the restworksteal for tail; refresh tests/test_durations.json so scripts/ci/shard_tests.py splits whole files by measured timeOnly when the measured tail is past run-to-run noise in 2 of 3 runs
Shards (CI matrix)A balanced shard still exceeds ~2 minChange every value in test-313-shard.matrix.shard to the new N (1/3, 2/3, 3/3 becomes 1/4 … 4/4; GFLOW_TEST_SHARD=k/N), never append one: mixed denominators make files run twice or not at all. The count floor is checked over the sum in test-313Runner start-up (~20-30 s) is paid per shard; past ~4-5 shards it stops paying
Cut a per-test costA file or test is slow against its baselinepytest-speed: fixture timer (-p scripts.ci.pytest_speed.fixture_timer), first-cost, then remove the cost (share an expensive fixture at module scope, drop a fixed sleep for an awaited condition, fake a network call)Shared fixtures must not leak state between tests
Serial tailA job that runs after the tests dominates (SonarCloud needs combined coverage)Start what can start earlier; keep the merge-coverage step smallSonar's gate must still see all coverage
Profile clones (live e2e)e2e runs one test at a time because one Chrome profile cannot be shared (exit 11)One copy of a signed-in profile per xdist worker (the lock is keyed by directory), caches left out (~265 MB, ~4 s each); -n = number of clones. Measured working at 2 browsers per account (spike below). Prerequisite not built yet: the e2e fixtures read one GFLOW_CLI_E2E_PROFILE, so every xdist worker would open the same directory and the extras fail with exit 11; first add a worker→profile mapping (e.g. GFLOW_CLI_E2E_PROFILES=a,b,c indexed by PYTEST_XDIST_WORKER)Wider fan-out is not measured yet; daily image quota and credits are per account; WAF throttling
Exclusive resources (e2e)Two tests need the same project, quota or port@pytest.mark.xdist_group("<resource>") and --dist loadgroup for that run (worksteal ignores groups)Group only what truly conflicts, or the run goes serial again
Cut overhead around a generation (e2e)A generating test spends much more than the model's own timeFixture timer on one e2e file: browser launch, page load, fixed waits; reuse a warm page only where tests do not depend on fresh stateNever reuse state a test asserts on

Scenario recipes

  • ci: measure the last 20 runs (step 1). Order of levers: cancel superseded runs → remove duplicates → rebalance shards → add a shard → serial tail → per-test cost.
  • local: -n 8 --dist worksteal; then rank and cut per-test costs. The full suite OOMs on small machines: cap -n.
  • e2e: e2e runs only on a machine with live profiles (GFLOW_CLI_E2E_PROFILE), never in CI. Order: profile clones + -n → exclusive-resource groups → cut overhead around each generation. Join the agent registry and lease browser-session first (~/.agents/skills/multi-agent-dev); the A/B tool takes --lease-cmd / --release-cmd. Spend credits only under the standing e2e grant, and say what was spent.

Profile clones — status

The profile lock (profile_lease.py) is keyed by the profile directory, so a copy of a signed-in profile has its own lock. Measured on 2026-11-12 (spike, scripts/dev/spike_profile_clone_concurrency.py): one clone of denon82 drove flow.google.com at the same time as the original, and both stayed signed in. Before relying on a wide fan-out (4-12 workers), measure it the same way: Google throttling, the shared daily image quota and the shared credit balance are per account, not per clone.

Integration

  • Claude Code: /gflow:optimize [ci|local|e2e] (thin wrapper around this file).
  • Codex: $gflow:optimize. Cursor / Aider / agy: include this file in context.
  • Engineering discipline (measure first, a red test before a fix, one verifiable change per commit, a decision log) is the project's default for every change; see plan.
  • Next step: after an optimisation lands, re-measure on the next 5 CI runs and announce whether the target holds.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free