terrylica/cc-skills/plugins/crucible/skills/a-research-foundations/SKILL.md
crucible-research-foundations
Validate findings, design shuffled nulls, check label leakage, review causal features. TRIGGERS - shuffled null, label leakage
- Source repository stars
- 61
- Declared platforms
- 0
- Static risk flags
- 1
- Last source update
- 2026-08-26
- Source checked
- 2026-08-28
Decision brief
What it does: where it fits
Self-Evolving Skill: This skill improves through use. If a discipline's guidance fails in practice or a new trap emerges, update the relevant section AND append to references/evolution-log.md. Don't defer.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/terrylica/cc-skills --skill "plugins/crucible/skills/a-research-foundations"Inspect the Agent Skill "crucible-research-foundations" from https://github.com/terrylica/cc-skills/blob/05f53c5b24a445c1895e9b0590212e66cd70f39e/plugins/crucible/skills/a-research-foundations/SKILL.md at commit 05f53c5b24a445c1895e9b0590212e66cd70f39e. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
1. Causal-feature invariant (bars[:i])
Every feature f[i] used at trigger/decision bar i must be computable using only bars[0:i] — never bars[i], never bars[i+1:]. Violation produces look-ahead bias; findings silently become worthless.
Every feature f[i] used at trigger/decision bar i must be computable using only bars[0:i] — never bars[i], never bars[i+1:]. Violation produces look-ahead bias; findings silently become worthless.Note lo:i (exclusive), not lo:i+1. This discipline "feels off by one" but is correct.Verification test (add to every new feature function): - 02
2. Label-leakage (bar-local scaling kills window leakage)
Forward labels must be scaled to the triggering bar's own range, NEVER to a window-wide scale. Window-relative labels are tautological.
Forward labels must be scaled to the triggering bar's own range, NEVER to a window-wide scale. Window-relative labels are tautological.Trap: If you label fwd+H = UP when close[i+H] - close[i] window.span/20, then when close[i] is near window.min (loc=B), fwd=UP is near-automatic. Agents will report spurious "signals".Fix: use bar-local triple-barrier labels: - 03
walk forward, exit at first tp/sl/expiry
findings/ ├── evolution/ │ ├── evolution.jsonl append-only ledger │ └── audits/ │ └── YYYY-MM-DD-slug/ │ ├── CLAUDE.md navigator │ ├── verdict.md plain-English conclusion │ ├── CHRONICLE.md narrative (for major findings) │ ├── .py script that regenerates headline numbers │ └── .…
Run the signal across full history; collect N trade outcomesCompute 20-30 causal features at each trigger barEmit per-trade parquet + CSV (one row per trade) - 04
3. Shuffled-null design (3 null types — get the right one)
Shuffled-null tests are mandatory before trust, but the choice of what to shuffle is a design decision.
Using feature-shuffle when testing a trigger pattern → destroys temporal structure the pattern depends on → real signal looks worse than shuffled noiseUnder-tight null (null std huge relative to observed effect) → no statistical powerOver-tight null (too few permutations) → unreliable z-estimates; use ≥100 for z<3, ≥1000 for z<2 - 05
4. Agent significance corrections (z-scores are overstated 2-3×)
LLM agents systematically overstate z-scores. Treat agent-reported p-values as upper bounds.
Ignored multiple-testing burden: agent tests 25 variants, reports z=2.43 vs nominal 1.96 threshold. True Bonferroni threshold is sqrt(2 ln(N)) — for N=25 that's z2.8.Confused sample-mean z with binomial-proportion z: 53.5% vs 50% on N=840 gives z≈2.0 not 4.2.Extremum-of-K treated as single test: "top combo from 17,280" has expected null-max nullmean + nullstd × sqrt(2 ln K) ≈ nullmean + 4.5σ. An observed tw that's below that expectation is not a finding.
Permission review
Static risk signals and limitations
Writes files
The documentation asks the agent to create, modify, or delete local files.
*The supersedes pattern**: when a later finding replaces an earlier one, ADD a new entry with `supersedes: "OLD-ID"`; UPDATE the old entry with `superseded_by: "NEW-ID"`. **Do NOT delete** the older audit folder.Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 61 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- terrylica/cc-skills
- Skill path
- plugins/crucible/skills/a-research-foundations/SKILL.md
- Commit
- 05f53c5b24a445c1895e9b0590212e66cd70f39e
- License
- MIT
- Collected
- 2026-08-28
- Default branch
- main
View the original SKILL.md
Research Foundations — 6 epistemic disciplines
Self-Evolving Skill: This skill improves through use. If a discipline's guidance fails in practice or a new trap emerges, update the relevant section AND append to
references/evolution-log.md. Don't defer.
Read these in order. The first three (causal, labels, nulls) are the hardest prerequisites — violating any of them silently invalidates every downstream result.
1. Causal-feature invariant (bars[:i])
Every feature f[i] used at trigger/decision bar i must be computable using only bars[0:i] — never bars[i], never bars[i+1:]. Violation produces look-ahead bias; findings silently become worthless.
Canonical pattern:
for i in range(n):
lo = max(0, i - window)
wind = values[lo:i] # EXCLUSIVE upper bound — no peeking
f[i] = compute(wind)
Note lo:i (exclusive), not lo:i+1. This discipline "feels off by one" but is correct.
Verification test (add to every new feature function):
def test_causality(fn, n=1000):
bars = generate_test_bars(n)
f_orig = fn(bars)
bars_mod = bars.copy()
bars_mod[500:] *= 2 # perturb the FUTURE
f_mod = fn(bars_mod)
assert np.array_equal(f_orig[:500], f_mod[:500]), "look-ahead detected"
Silent-bug signature: impossibly clean results (tw > 10 bps on FX, win rate > 70%, OOS matches IS perfectly).
Full reference: findings/methodology/10-causal-feature-invariant.md.
2. Label-leakage (bar-local scaling kills window leakage)
Forward labels must be scaled to the triggering bar's own range, NEVER to a window-wide scale. Window-relative labels are tautological.
Trap: If you label fwd+H = UP when close[i+H] - close[i] > window.span/20, then when close[i] is near window.min (loc=B), fwd=UP is near-automatic. Agents will report spurious "signals".
Fix: use bar-local triple-barrier labels:
r = high[i] - low[i] # THIS bar's range, not window's
tp_level = close[i] + tp_mult * r
sl_level = close[i] - sl_mult * r
# walk forward, exit at first tp/sl/expiry
Symptom that you fell into the trap: apparent signal strengthens monotonically with loc quintile; collapses when you test adjacent cells.
Full reference: findings/methodology/02-label-leakage-bar-local-scaling.md.
3. Shuffled-null design (3 null types — get the right one)
Shuffled-null tests are mandatory before trust, but the choice of what to shuffle is a design decision.
| Hypothesis class | Shuffle WHAT | Session example |
|---|---|---|
| "Feature X predicts outcomes" | Shuffle the feature values | Phase F-B (used wrong null, "falsified" a real signal) |
| "Trigger pattern fires at informative times" | Shuffle the trigger mask (preserve fire-rate, move locations) | Phase C (validated ngram_triple_fast_up at z=+5.74) |
| "Filter improves selection" | Shuffle which trades pass the filter | Phase L-C (evaluated filters against N-size random draws) |
Rule: ask "what is the alternative hypothesis, in one sentence?" If you can't state it, you don't know what you're testing.
Common mistakes:
- Using feature-shuffle when testing a trigger pattern → destroys temporal structure the pattern depends on → real signal looks worse than shuffled noise
- Under-tight null (null std huge relative to observed effect) → no statistical power
- Over-tight null (too few permutations) → unreliable z-estimates; use ≥100 for z<3, ≥1000 for z<2
Full reference: findings/methodology/03-shuffled-null-design.md.
4. Agent significance corrections (z-scores are overstated 2-3×)
LLM agents systematically overstate z-scores. Treat agent-reported p-values as upper bounds.
Three overstatement patterns:
- Ignored multiple-testing burden: agent tests 25 variants, reports z=2.43 vs nominal 1.96 threshold. True Bonferroni threshold is
sqrt(2 * ln(N))— for N=25 that's z>2.8. - Confused sample-mean z with binomial-proportion z: 53.5% vs 50% on N=840 gives z≈2.0 not 4.2.
- Extremum-of-K treated as single test: "top combo from 17,280" has expected null-max
null_mean + null_std × sqrt(2 ln K)≈ null_mean + 4.5σ. An observed tw that's below that expectation is not a finding.
Always verify:
- How many implicit tests did the agent run?
- Re-derive z yourself:
(real - null.mean) / null.std - Bonferroni threshold for K tests:
z > sqrt(2 * ln K)
Trust thresholds:
- z > 5, N > 500: likely real, test further
- z in [3, 5]: promising, mandatory gate validation
- z in [2, 3]: suspect, require adjacent-cell gradient + null test
- z < 2: treat as null
Full reference: findings/methodology/09-agent-significance-corrections.md.
5. Record-keeping discipline (append-only ledger + audit folders)
Every investigation — positive or null — must produce a permanent, discoverable record.
3-layer architecture:
findings/
├── evolution/
│ ├── evolution.jsonl # append-only ledger
│ └── audits/
│ └── YYYY-MM-DD-slug/
│ ├── CLAUDE.md # navigator
│ ├── verdict.md # plain-English conclusion
│ ├── CHRONICLE.md # narrative (for major findings)
│ ├── <reproducer>.py # script that regenerates headline numbers
│ └── <artifact>.json # raw telemetry
└── methodology/ # universal principles
Ledger entry fields: id, date, status, supersedes, superseded_by, headline, key_numbers, evidence (file paths), sha256_results.
The supersedes pattern: when a later finding replaces an earlier one, ADD a new entry with supersedes: "OLD-ID"; UPDATE the old entry with superseded_by: "NEW-ID". Do NOT delete the older audit folder.
Full reference: findings/methodology/07-record-keeping-discipline.md.
6. Post-mortem-before-abandon
Before declaring a signal dead, enrich every trade with causal pre-entry features and hunt filters on individual losses. A "sometimes works" signal is often a filterable signal in disguise.
Pipeline:
- Run the signal across full history; collect N trade outcomes
- Compute ~20-30 causal features at each trigger bar
- Emit per-trade parquet + CSV (one row per trade)
- Ship to multi-lens agents (see Skill B)
- Each agent hunts filters that separate winners from losers
- Evaluate filters against shuffled-null (see §3)
Kill-selectivity metric: losers_killed / max(1, winners_killed). < 1.0 = harmful; 1.0-1.2 = marginal; 1.2-1.5 = useful; > 1.5 = strong.
Session example: +0.178 bps baseline → +0.514 bps after Phase-L filter. 2.9× lift from enrichment-driven filter hunt.
Full reference: findings/methodology/06-per-trade-enrichment-postmortem.md.
Confirmation counts (provisional, as of session ca9d7ffa)
| Principle | Confirmed | Notes |
|---|---|---|
| 1. causal-feature-invariant | 18+ (every phase) | Fundamental; drop only with proof |
| 2. label-leakage | 2 | Directly caught spurious "lower-rejection-at-bottom" |
| 3. shuffled-null-design | 4 | Phase F-B wrong-null, Phase C right-null, Phase L filter-null, Phase M mgmt-null |
| 4. agent-sig-corrections | 5+ | Combinatorialist, transition-asymmetry, trade-mgmt agents all overstated |
| 5. record-keeping | 5 ledger entries | Full chain for NGRAM3FU-STRADDLE |
| 6. post-mortem | 1 | Phase L delivered the filter; needs re-confirmation on other campaigns |
Higher confirmed = more trustworthy. Principle 6 has only one confirmation and should be treated as provisional.
Post-Execution Reflection
After invoking this skill:
- Did applying a principle catch a bug or false positive? Increment its
confirmedcount in the table above; note the session where it fired inreferences/evolution-log.md. - Did a principle fail (bad guidance)? Demote it in the table; add a
superseded_bypointer inreferences/archive/withresurrect_if:conditions. - New trap that isn't covered? Draft a new section here and append to the evolution log.
- Never silently move on. This skill's value compounds only if reality-corrections flow back.
Frequently asked questions
What to verify before installation and use
What does the crucible-research-foundations source document cover?
Self-Evolving Skill: This skill improves through use. If a discipline's guidance fails in practice or a new trap emerges, update the relevant section AND append to references/evolution-log.md. Don't defer.
How do I install crucible-research-foundations?
The source record exposes this install command: npx skills add https://github.com/terrylica/cc-skills --skill "plugins/crucible/skills/a-research-foundations". Inspect the command and pinned source before running it.
Which permission-related actions were detected?
Static rules flagged write-files in the source; the page lists the matching lines and excerpts.
Alternatives
Compare before choosing
coreyhaines31/marketingskills
ab-testing
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program
coreyhaines31/marketingskills
churn-prevention
When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers o
prowler-cloud/prowler
postgresql-indexing
PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance
narrative-io/narrative-skills-marketplace
design-analysis
Translate a fuzzy analytical question into a rigorous investigation plan. Interrogates the ask, grounds the plan in the available data dictionary, applies analytical best practices, and produces a structured brief of query specifications for a downstream query-writing skill. Plans, does not write SQL. Use when: "why did X drop", "is there a relationship between A and B", "who are our highest-value customers", "what's driving the change in Y", "investigate this trend", "design an analysis for", "