Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when designing or analysing an A/B test, computing power or sample size, testing whether a difference is real, or writing any statistical claim — effect sizes with intervals, SRM checks, multiple comparisons and causal caveats
インストールする前に、エージェントに与えられる指示の中身を確認できます。
A statistical claim is a decision under uncertainty. The analysis has to say how big the effect is, how sure we are, and what could make it wrong — not just whether p < 0.05. The statistics code is production code too: it gets tests.
Core principle: decide the design (metric, unit, sample size, stopping rule) before looking at results; report effect size with a confidence interval; treat every causal-sounding sentence as a claim that needs a design behind it.
Write these down, in the task or your closing message, before analysing anything:
| Item | Example |
|---|---|
| Hypothesis | New checkout raises conversion |
| Primary metric (one) | Orders / visitors, per user |
| Guardrails | Refund rate, page latency |
| Randomisation unit = analysis unit | User (not session, not page view) |
| Minimum detectable effect | +1.0 percentage point on a 10% baseline |
| α, power | 0.05 two-sided, 0.80 |
| Sample size and duration | Computed below; whole weeks to cover weekly cycles |
| Stopping rule | Analyse once at the planned sample size |
from statsmodels.stats.power import NormalIndPower
from statsmodels.stats.proportion import proportion_effectsize
effect = proportion_effectsize(0.11, 0.10)
n_per_arm = NormalIndPower().solve_power(effect_size=effect, alpha=0.05, power=0.8, ratio=1.0)
If the traffic cannot reach n_per_arm in a reasonable time, say so before the test runs — an underpowered test produces noise and exaggerated "wins".
scipy.stats.chisquare([n_a, n_b], f_exp=[expected_a, expected_b]). A very small p-value (below 0.001) means assignment or logging is broken — stop and report that instead of an effect.proportions_ztest(count=[x_b, x_a], nobs=[n_b, n_a]) and the interval for the difference with confint_proportions_2indep(x_b, n_b, x_a, n_a).scipy.stats.ttest_ind(b, a, equal_var=False).statsmodels.stats.multitest.multipletests(p_values, alpha=0.05, method="holm") (or "fdr_bh" for many exploratory comparisons), and report how many tests were run.Hand-computed cases pin the arithmetic; simulation pins the behaviour.
def test_ab_test_false_positive_rate_is_near_alpha() -> None:
rng = np.random.default_rng(0)
p_values = np.array([
two_proportion_test(rng.binomial(1, 0.10, 2_000), rng.binomial(1, 0.10, 2_000)).p_value
for _ in range(500)
])
assert 0.02 < (p_values < 0.05).mean() < 0.08
An A/A simulation like this catches a wrong variance formula, a one-sided test where two-sided was meant, and analysis at the wrong unit. A matching simulation with a true effect of the planned MDE should detect it at roughly the planned power.
Primary: conversion (per user), B vs A — planned n 14,745/arm, analysed once
A 10.02% (n=15,210) B 10.71% (n=15,188) SRM p=0.90
Difference +0.69 pp (95% CI +0.01 to +1.38), relative +6.9%, p=0.048
Planned MDE 1.0 pp: the point estimate is below it — weak practical evidence
Guardrails: refund rate +0.1 pp (CI −0.3 to +0.5), latency unchanged
Exploratory segments (Holm-corrected, 4 tests): none significant
Round to the precision the interval supports; "about 7%" is more honest than "6.93%".
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
日本語の概要は準備中です。原文の説明を表示しています。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
日本語の概要は準備中です。原文の説明を表示しています。
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
日本語の概要は準備中です。原文の説明を表示しています。
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
日本語の概要は準備中です。原文の説明を表示しています。
Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
日本語の概要は準備中です。原文の説明を表示しています。