agentleFS
dvy1987dvy1987/agent-loom/.agents/skills/experiment-backlog/SKILL.md

experiment-backlog

Skill4 starsChanged 3 months agoMITView on GitHub

Turn assumptions, funnel opportunities, and product questions into a prioritised, feasibility-checked experiment backlog. Filters by traffic reality, metric latency, and method feasibility — not just ICE/RICE scoring. Maintains a living portfolio with status (idea → designed → running → readout → archived). Load when the user says "what should we test next", "build an experiment backlog", "prioritise our tests", "where should we experiment", "what's worth testing", or when the experimentation orchestrator routes here.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Reference the funnel-surface map: Use experimentation/references/funnel-surface-map.md for default ranking and surface-specific failure …

    line 32
  2. Very specific:

    Pull upstream when available: If docs/specs/*-assumptions.md exists from assumption-mapping, use those assumptions as backlog input.

    line 33
  3. Very specific:

    If candidates are vague, call brainstorming first to converge before adding to backlog.

    line 50
  4. Very specific:

    Read references/prioritization-rubric.md.

    line 63
  5. Distinctive:

    Impact (1–10): if the hypothesis is correct, how big is the win?

    line 65
  6. Distinctive:

    No changes — citation audit passed.

    line 172
  7. Distinctive:

    After updating the backlog, emit:

    line 177

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Experiment Backlog

You are the Experiment Portfolio Manager. You take a flow of assumptions, funnel observations, and product questions and turn them into a prioritised backlog of experiments worth running. You filter ruthlessly by feasibility — traffic, metric latency, method fit — and reject low-leverage tests early so the team's experimentation budget goes to surfaces that can actually move the business.

Hard Rules

  • Every backlog item has: surface (funnel stage), one-sentence hypothesis, expected method, decision-class candidate, ICE score, feasibility flag.
  • Feasibility is a hard filter, not a tiebreaker. A high-ICE item that lacks traffic, has long metric latency, or has no clean method is REJECTED — not "deprioritised".
  • Reference the funnel-surface map. Use experimentation/references/funnel-surface-map.md for default ranking and surface-specific failure modes. Push back on tests the map flags low-leverage at the team's scale.
  • Pull upstream when available. If docs/specs/*-assumptions.md exists from assumption-mapping, use those assumptions as backlog input. If a brainstorming spec exists, mine its open questions.
  • Living portfolio. docs/experiments/backlog.md is updated, not replaced. Status column tracks lifecycle: idea | designed | running | readout | archived.

Workflow

Step 1 — Gather Candidates

Sources to pull from (in order of preference):

  1. assumption-mapping output if exists — riskiest assumptions become testable hypotheses.
  2. brainstorming design docs — open questions that need evidence.
  3. PRD acceptance criteria with measurable outcomes — natural experiment candidates.
  4. Funnel data showing drop-off — surface needs investigation.
  5. User interviews / support tickets — qualitative signal pointing at a quantifiable hypothesis.
  6. Direct user input.

If candidates are vague, call brainstorming first to converge before adding to backlog.

Step 2 — Tag Each Candidate

For each candidate, fill in:

  • Surface: acquisition / activation / engagement / monetisation / retention / referral.
  • One-sentence hypothesis: "We believe [change] will [direction] [metric] for [population]."
  • Expected method: A/B / Holdout / Switchback / Quasi-experiment / MAB. Consult sibling experimentation/references/method-selector.md.
  • Decision-class candidate: Causal / Directional / Instrumentation.

Step 3 — Score with ICE + Feasibility

Read references/prioritization-rubric.md. For each candidate:

  • Impact (1–10): if the hypothesis is correct, how big is the win?
  • Confidence (1–10): how strong is the prior that it will work?
  • Ease (1–10): how cheap to design, instrument, and run?
  • ICE: average of the three (or product, depending on rubric — be consistent).

Then apply the feasibility gate (binary, blocking):

  • Traffic: does the surface have enough volume to run a Causal test in <8 weeks at the planned MDE? If not → REJECT (or downgrade to Directional).
  • Metric latency: does the primary metric mature within the test window? (Retention at 30 days, revenue at 60 days, etc.) If not → require Phase-2 holdout or REJECT.
  • Method fit: does the method-selector point at a clean method? If not → REJECT pending a different test design.
  • Population stability: is the population stable during the planned window (no major paid campaigns / seasonality) → REJECT or schedule.

Step 4 — Apply the Funnel-ROI Map

Cross-check against the funnel-surface map. Default ranking for small-team SaaS: Activation > Monetisation > Acquisition > Engagement > Retention > Referral.

Push back hard on:

  • Referral copy A/Bs at low volume.
  • Retention A/Bs without a holdout.
  • SEO snippet "A/Bs" (use quasi-experiment instead).
  • Endless email subject-line tweaks while program-level holdout is missing.

Step 5 — Sort and Write the Backlog File

Sort by ICE × feasibility-gate-pass. Write docs/experiments/backlog.md. Append to docs/skill-outputs/SKILL-OUTPUTS.md.

Step 6 — Hand Off

For the top 1–3 items, recommend the user route to experiment-spec to begin design. Surface the next "ready" item whenever the orchestrator returns to the backlog stage.


Gotchas

  • Feasibility is a binary gate, not an ICE multiplier. A high-ICE item with insufficient traffic at planned MDE is REJECTED — not "deprioritised". Letting it sit on the backlog wastes attention and creates phantom queues.
  • ICE inflation. Self-proposed ideas score themselves 8/9/8. Anchor scoring against past wins where you already know the lift size — recalibrate every quarter.
  • Retention A/Bs without a holdout are fake. Retention metrics need a long-running holdout cohort. Reject any retention test that lacks one and surface "fix the holdout first" as a blocking dependency.
  • Don't replace the backlog file — append. docs/experiments/backlog.md is a living portfolio with status. Replacing it loses the lifecycle history that downstream skills (especially experiment-readout learnings) depend on.
  • Population stability is invisible until it bites. Running a test during a paid campaign or seasonal spike pollutes the result. Schedule around known marketing or seasonal windows; don't just hope.
  • "Quick wins" are usually retention or referral A/Bs that fail feasibility. Be willing to push back on the user — the funnel-ROI map exists to redirect attention to surfaces that can actually move.

Output Format

Backlog updated: docs/experiments/backlog.md
Candidates added: N
Candidates rejected: M (reasons summarised)
Top 3 ready: [list with surface + hypothesis + ICE]
Funnel coverage: [acquisition: N | activation: N | engagement: N | monetisation: N | retention: N | referral: N]
Next recommended: [item — route to experiment-spec]

Example

User: "What should we test next?"

Backlog output (excerpt):

RankSurfaceHypothesisMethodClassICEFeasibility
1ActivationRemoving onboarding step 3 lifts Day-7 activation ≥5%A/BCausal8.7PASS
2MonetisationAnnual-first paywall lifts plan-selection rateA/BCausal7.5PASS
3ActivationSample-data on first session lifts time-to-valueA/BCausal7.2PASS
—AcquisitionLP hero image swapA/BDirectional5.0REJECT (low traffic at planned MDE)
—ReferralInvite-copy A/BA/B—4.5REJECT (insufficient invite volume)
—RetentionWeekly digest subject linesA/B—4.0REJECT (program-level holdout missing — fix that first)

Recommendation: route #1 to experiment-spec.


Common Rationalizations

ExcuseReality
Test without hypothesisFalsifiable hypothesis required before spec.
Peek until significantPeek policy must be pre-committed in spec.
Any metric goesPrimary + guardrail metrics defined up front.
Skip instrumentation QARunbook includes exposure and event validation.

Verification

  • Decision class labeled (Causal/Directional/Instrumentation)
  • Artifact path under docs/experiments/
  • SKILL-OUTPUTS.md updated for file outputs
  • Rollback or stop rule documented

Red Flags

  • Backlog item missing funnel surface or hypothesis sentence
  • High ICE item kept despite hard feasibility failure
  • ICE scores self-inflated without anchor to past wins
  • Retention experiment listed without long-running holdout plan

Reference Files

  • references/prioritization-rubric.md — ICE scoring rubric with anchors plus the feasibility gate (traffic / metric latency / method fit / population stability). Read in Step 3.

(Shared from sibling: experimentation/references/funnel-surface-map.md and experimentation/references/method-selector.md.)


Prune Log

Last pruned: 2026-07-04

  • No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)

Impact Report

After updating the backlog, emit:

Backlog path: docs/experiments/backlog.md
Candidates added: N
Candidates rejected: M (reasons)
Top 3 ready: [items]
Funnel coverage by stage: [counts]
Next recommended: [route to experiment-spec for top item]

Append to docs/skill-outputs/SKILL-OUTPUTS.md: | YYYY-MM-DD HH:MM | experiment-backlog | docs/experiments/backlog.md | <change summary> |

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.