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 the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.