使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/emiliodominguez/flow-skills --skill flow-benchmark開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Benchmark
Define what "better" means before measuring. Keep raw results and compare like with like; never report a single attractive timing.
Process
- State metric, workload, target and the decision it informs. Define the timing boundary and
cache/process state: cold startup includes initialization; steady-state throughput may warm up. Keep cold and warm experiments separate.
- Record baseline revision, runtime/build settings, hardware/environment, fixtures,
concurrency, sample unit and tool/version. Time setup only when it is part of the metric; never warm away the behavior under investigation.
- Run baseline and candidate under controlled conditions, changing one variable per
experiment. Interleave A/B samples when drift matters; isolate data/state between samples.
- Collect enough observations for the claim. Report median, tails such as p95/p99 only when
sample size supports them, variance, outliers and known noise. No false precision, no unexplained outlier removal.
- Check tradeoffs in memory, CPU, responsiveness, bundle size and complexity. Profile when the
result needs an explanation. A lower score is not automatically a better user experience.
- Save the harness or command, raw results and comparison so others can rerun it. State
whether the effect is large relative to noise.
Anti-patterns
- Warming a cold-start benchmark or excluding the initialization under investigation.
- Comparing development and production builds as if only the implementation changed.
- Reporting a best run or p99 from a handful of samples.
- Claiming causation from timing alone.
Done when
- Baseline and candidate share a relevant reproducible workload and timing boundary.
- Raw results, uncertainty and meaningful regressions are visible.
- The evidence supports an optimization decision or names what better measurement is needed.
Use flow-work or flow-refactor only for an optimization the evidence justifies.
