사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
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.
