Skip to content
Back to skills

Add Score Modifier

ASecurity

Use when adding a ±0.X score modifier to scanner Stage 3 (PO3/bear_phase/HMM-style). Triggers on tasks like "add a setup-score adjustment based on regime X", "boost score when condition Y".

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 27, 2026
data-aipython

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add anvilfilbert/Auto-Crypto-Tradingjournal --skill add-score-modifier --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Add Score Modifier?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Add Score Modifier
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/anvilfilbert-add-score-modifier/badge)](https://www.skillsdirectory.com/skills/anvilfilbert-add-score-modifier)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: add-score-modifier
description: Use when adding a ±0.X score modifier to scanner Stage 3 (PO3/bear_phase/HMM-style). Triggers on tasks like "add a setup-score adjustment based on regime X", "boost score when condition Y".
---

# Add a Score Modifier to Scanner Stage 3

A *score modifier* is a ±0.X adjustment applied to `setup_score` in `ai_scanner.py` Stage 3, based on some context signal (regime, time-of-day, structural pattern). It's the standard pattern used by `bear_phase`, `HMM`, `PO3 range`, `PO3 FVG`, `kill_zone`.

## When to use this pattern vs a confluence signal

- **Score modifier** (this skill): a single ±0.X bump applied AFTER the 15-signal confluence is computed. For *contextual* adjustments (regime, time, structural state).
- **Confluence signal** (see `add-confluence-signal`): one of the 15 signals summed into the base score. For *directional* technical signals.

If the signal answers "does this setup belong in this market regime?" → modifier.
If it answers "is the chart bullish or bearish?" → confluence signal.

## Reference implementations

| Modifier | File | Pattern function |
|---|---|---|
| Bear-phase alignment | `bear_phase.py` | `phase_alignment_weight(phase, direction) → (float, str)` |
| HMM regime alignment | `market_regime.py` | `hmm_alignment_weight(regime, direction) → (float, str)` |
| PO3 range | `chart_confluence.py` | `directional_range_weight(...) → (float, str)` |
| Kill-zone session | `scanner_criteria.py` | `_apply_kill_zone_modifier(score) → (float, [warnings])` |

## Checklist

### 1. Implement the weight function
- Location: extend an existing module (e.g., `chart_wyckoff.py`) or create a new one.
- Signature: `<feature>_alignment_weight(state, direction) → (weight: float, reason: str)`
- Magnitude: ±0.2 (small, additive) or ±0.3 (standalone, distinct from existing signals). NEVER exceed ±0.3 — stacking risk.
- Return `(0.0, "")` on missing data or low confidence; never raise.
- Add unit tests in `tests/test_<feature>_alignment.py` covering: positive case, negative case, both directions, edge cases (None inputs, missing fields, confidence threshold).

### 2. Wire into Stage 3
- File: `ai_scanner.py` around line 295 (after `bear_phase`, before personal-bad-hour cap)
- Pattern:
  ```python
  feature_label = ""
  try:
      from <module> import <feature>_alignment_weight, <state_fetcher>
      state = <state_fetcher>(...)
      w, reason = <feature>_alignment_weight(state, direction)
      if w != 0:
          score = max(0.0, min(10.0, score + w))
          feature_label = reason
          logger.info("<feature> mod applied to %s: %s", sym, feature_label)
      elif reason:
          feature_label = reason
  except Exception as e:
      logger.debug("<feature> modifier error on %s: %s", sym, e)
  ```
- The `try/except` is mandatory — modifiers must never crash Stage 3.
- Re-apply personal-bad-hour cap AFTER (line ~329, already in place).

### 3. Surface in setup dict (for Sonnet visibility)
- Add to setup dict: `"_<feature>": feature_label,`
- Add to PO3 summary line in `ai_scanner.py` around line 421:
  ```python
  if feature_label:   _po3_bits.append(feature_label.replace("<Prefix>: ", "<short>:"))
  ```

### 4. Surface in consensus log payload
- File: `trading/signal_consensus.py` around line 290
- Add: `"<feature>": setup.get("_<feature>"),`
- Without this, the modifier fires but the field is invisible in `futures_ai_log` payloads (lesson from 2026-05-24 HMM wiring gap).

### 5. Walk-forward validation
- Walk-forward A/B test: keep the modifier OFF for run 1, ON for run 2, compare test_sharpe.
- If `test_sharpe(ON) ≤ test_sharpe(OFF) × 0.95`, the modifier is noise — revert.

### 6. Deploy
- Sync via `/tmp/deploy_audit.exp`
- If only Stage 3 logic changed: `restart_pi.exp` (no snapshot/config touch).
- Verify via post-deploy log: next `consensus_rejected` event should contain the new field.

## Red flags

- "I'll just stack 5 modifiers all at ±0.3" → stop. Total modifier stack should not exceed ±0.6 net. Anything more = score inflation, calibration breaks.
- "I'll add the modifier with no walk-forward" → stop. Every modifier must justify itself via OOS Sharpe delta.
- "I'll skip the consensus payload step" → stop. Without it, the calibration data has a blind spot.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…