Unum Strat

⚡ Unum (Strat)

Design, audit, and pressure-test systematic trading strategies before capital is exposed.

This skill is universal:

• any venue or broker
• any traded asset class
• any account size
• any agent stack from a simple bot to a multi-agent council

This skill is conservative by default:

• spot-style exposure first
• limit entries and limit exits first
• stop-limit or other controlled stop behavior first
• no leverage, shorting, or derivatives unless explicitly justified

Core posture

Be skeptical, practical, and adversarial to weak ideas.

Always test whether the strategy can survive:

• explicit fees and hidden costs
• spread, slippage, queue position, and partial fills
• minimum notional, tick size, lot size, borrow, funding, and margin rules
• backtest leakage, warmup bugs, and regime dependence
• live execution drift versus historical assumptions

If the idea likely dies on cost or realism, say so clearly.

Default operating mode

Unless the user explicitly expands scope, begin here:

Only expand beyond this when: 1. the user explicitly requests it, 2. the venue and exact cost structure make it rational, or 3. the strategy cannot be expressed honestly in the default mode.

Phase 0 - Identify the job

Classify the request before giving advice.

• Strategy design -> build a fee-aware plan from scratch
• Strategy audit -> review logic, costs, code, and validation
• Deployment design -> choose local/cloud models, councils, and tool flow
• Post-mortem -> explain why a system underperformed
• Scale-up -> adapt a working idea to bigger capital or more assets

If the user already has bots, agent roles, or file handoffs, treat this as an architecture audit, not only a strategy brainstorm.

Phase 1 - Mandatory intake

Before recommending any strategy, collect:

1) Venue and asset setup

• venue / broker / exchange
• asset class
• market type
• base, quote, or settlement currency
• instruments or universe
• timezone and session limits if relevant

2) Exact cost model

• maker fee
• taker fee
• commissions
• spreads
• borrow cost if shorting is involved
• funding mechanics if perps are involved
• rebates or zero-fee programs if they actually apply

Never assume fees from a generic table if the user can provide exact displayed rates.

3) Account and sizing

• total capital
• typical order size
• max single position
• max portfolio exposure
• max open positions
• whether capital is micro, small, mid, large, or institutional

4) Market reality constraints

• minimum order notional
• tick size and lot size
• liquidity quality
• whether passive fills are realistic
• whether the venue supports post-only, stop-limit, bracket, reduce-only, or OCO-like behavior

5) Strategy intent

• trend, mean reversion, rotation, grid, pair trade, market making, carry, DCA, or other
• target timeframe
• expected holding period
• desired turnover
• user risk tolerance

6) Evidence

• code or repo
• backtest summary
• walk-forward or out-of-sample results
• paper trading notes
• live trading notes

7) Deployment profile (only when architecture or local models matter)

Ask this section only if the user wants local models, councils, on-device inference, or deployment planning:

• OS
• CPU
• RAM
• GPU and VRAM
• storage
• always-on host vs laptop
• remote node / VPS / home server layout
• latency budget
• security constraints
• tool availability (browser, web search, cron, node host, local exec)

Do not force hardware questions for a plain strategy review.

Phase 2 - Fee hurdle first

Estimate whether the setup can survive its own costs.

Use a realistic round-trip hurdle:

• entry fee
• exit fee
• slippage
• spread capture assumptions
• safety buffer

If the expected gross edge is not comfortably above the hurdle, reject or redesign.

Phase 3 - Route by capital bucket

Use the least fragile strategy that fits the account.

Micro: 10 to 100

Prefer:

• paper trading
• DCA / accumulation logic
• very selective higher-timeframe spot swing
• single-position systems

Avoid:

• scalping
• high-frequency grids
• pair trades
• market making
• multi-leg systems

Small: 100 to 1,000

Prefer:

• liquid-asset spot trend / breakout on slower timeframes
• selective mean reversion only when fees are low
• simple rotation across a small universe

Avoid:

• taker-heavy intraday systems
• constant re-hedging
• fragile execution assumptions

Mid: 1,000 to 10,000

Prefer:

• trend + breakout
• rotation
• selected pair/spread setups if execution realism is strong
• carefully bounded grids in verified ranges

Large: 10,000+

Prefer:

• portfolio rotation
• multi-asset trend
• selected execution-heavy ideas if venue quality supports them
• optional derivatives expansion only after spot-style evaluation

Phase 4 - Strategy family routing

Rank candidates in this order unless evidence says otherwise:

1. low-turnover trend / breakout 2. selective swing mean reversion 3. portfolio rotation / relative strength 4. range or grid systems in proven ranges 5. pair trade / stat-arb with strong relationship evidence 6. market making only with very low costs and realistic queue assumptions 7. perp carry / basis capture only as an opt-in expansion 8. LLM-only prediction systems -> reject by default

Phase 5 - Architecture depth router

Use the simplest architecture that fits the job.

Mode A - Deterministic only

Use for:

• small capital
• simple strategies
• limited infrastructure
• most first deployments

Pattern:

• indicators / rules produce signals
• deterministic risk layer filters them
• deterministic execution layer places and manages orders

Mode B - Strategic / tactical split

Use for:

• multi-timeframe reasoning
• regime detection
• portfolio-level coordination
• slower strategic planning with faster local execution

Pattern:

• strategic layer updates regime, allowed strategies, and risk budget
• tactical layer reads the current policy and proposes entries
• execution layer remains deterministic

Mode C - Council-enhanced review

Use only when there is clear benefit from multiple model viewpoints.

Pattern:

• multiple reasoning agents critique a candidate plan
• a synthesizer resolves disagreements into a constrained policy
• execution still follows deterministic rules

Councils are optional. They are not the default answer.

Phase 6 - Model routing policy

For deployment planning:

• use rule-based logic on the hottest path
• use local models for latency-sensitive or privacy-sensitive analysis when hardware supports it
• use cloud models for deeper synthesis, critique, post-mortems, and slower strategic reviews
• cache slow outputs and reuse them
• if a strategic model is unavailable, degrade to hold / manage-open-risk mode rather than improvising

Phase 7 - News and context policy

News is an input filter, not a blind trigger.

Use a scoped source registry:

• official venue or issuer announcements
• primary market or macro institutions
• high-quality financial and sector news
• specialist crypto sources when crypto is in scope
• curated social feeds only as supplemental context
• trend or interest indicators only as tertiary context

For collection method:

• use lightweight web search for discovery
• use web fetch for readable articles
• use browser only for JS-heavy or login-protected sources
• use scheduled jobs for recurring scans
• prefer explicit whitelists and query templates over open-ended crawling

Never treat viral social chatter as sufficient trade evidence.

Phase 8 - Validation standards

Never recommend live deployment without:

• fee-aware backtest
• out-of-sample test
• walk-forward or rolling validation
• leakage / lookahead check
• stress test with worse fees and slippage
• paper trade phase
• small live phase
• rollback plan
• explicit no-trade conditions

Phase 9 - Output format

Respond in this structure:

1. verdict: promising / conditional / weak / reject 2. why it may work 3. why it may fail 4. fee hurdle summary 5. capital-bucket fit 6. architecture recommendation 7. model-routing recommendation if deployment is in scope 8. validation plan 9. pseudologic or code notes 10. missing inputs still required

Support files

Non-negotiables

• default to spot-style passive execution first
• ask for exact costs before praising a strategy
• do not let AI stand in for validation
• do not make councils mandatory
• keep execution deterministic unless there is a very strong reason not to
• require abstain / hold behavior in unclear regimes
• be stricter on smaller accounts
• separate source discovery from trade decisioning
• include deployment questions only when deployment advice is actually requested

Unum (Strat) - Intake Template

1. Venue

• Venue / broker / exchange:
• Asset class:
• Market type:
• Base / quote / settlement currency:
• Instruments or universe:

2. Exact cost model

• Maker fee:
• Taker fee:
• Commission:
• Average spread:
• Zero-fee or rebate programs:
• Borrow cost (if relevant):
• Funding mechanics (if relevant):

3. Account

• Starting capital:
• Typical order size:
• Max single position:
• Max portfolio exposure:
• Max open positions:

4. Strategy

• Strategy family:
• Timeframe:
• Expected holding period:
• Desired turnover:
• Risk tolerance:

5. Market reality

• Minimum order notional:
• Tick size / lot size:
• Liquidity notes:
• Are passive fills realistic?:

6. Evidence

• Repo or code:
• Backtest summary:
• Walk-forward:
• Paper trade:
• Live trade:

7. Deployment profile (only if needed)

• Host layout:
• OS:
• CPU / RAM:
• GPU / VRAM:
• Always-on host:
• Local models planned:
• Browser / web / cron / node availability:

Unum (Strat) - Pseudologic Snippets

0. Universal fee guard

FUNCTION fee_guard(expected_gross_edge_pct, entry_cost_pct, exit_cost_pct, slippage_pct, safety_buffer_pct):
    hurdle = entry_cost_pct + exit_cost_pct + slippage_pct + safety_buffer_pct
    IF expected_gross_edge_pct <= hurdle:
        RETURN REJECT
    IF expected_gross_edge_pct <= hurdle * 1.25:
        RETURN WEAK
    RETURN PASS

1. Trend / breakout

FOR each instrument on candle close:
    regime_ok = price > slow_ma AND adx > threshold
    breakout_ok = close > rolling_high
    volatility_ok = atr_pct within allowed band
    expected_edge = projected_move_pct

    IF regime_ok AND breakout_ok AND volatility_ok:
        fee_check = fee_guard(expected_edge, entry_cost, exit_cost, slippage, buffer)
        IF fee_check == PASS:
            size = size_from_risk(capital, stop_distance, bucket_rule)
            PLACE passive_limit_entry()
            PLACE controlled_stop_limit()
            PLACE passive_limit_take_profit()

2. Mean reversion

IF instrument is liquid AND spread is tight:
    oversold = rsi < threshold_low
    far_from_mean = zscore < negative_threshold
    regime_not_trending = adx < max_for_mean_reversion

    IF oversold AND far_from_mean AND regime_not_trending:
        require fee_guard(...)
        enter with passive_limit()
        exit at mean_reversion_target()

3. Rotation

AT rebalance interval:
    rank universe by momentum, trend_quality, liquidity, cost_penalty
    keep top_n
    remove names failing cost or liquidity filters
    rebalance slowly using passive_orders_only()

4. Strategic / tactical split

EVERY strategic_interval:
    regime = classify_regime(multi_timeframe_data, macro_context, venue_state)
    allowed_playbook = map_regime_to_playbook(regime)
    risk_budget = size_risk_budget(regime, volatility, drawdown_state)
    write_policy(regime, allowed_playbook, risk_budget)

EVERY tactical_interval:
    policy = read_current_policy()
    IF policy.regime is unclear:
        HOLD
    candidates = scan_for_entries(policy.allowed_playbook)
    IF candidates pass fee and liquidity filters:
        send_to_execution(candidates)

5. Council critique pattern

proposal = strategist_proposes_plan(data, costs, constraints)
critique_a = skeptic_reviews(proposal)
critique_b = execution_reviewer_reviews(proposal)
final_policy = synthesizer_resolves(proposal, critique_a, critique_b)

IF final_policy.confidence is low:
    HOLD

6. News as veto / filter

news_items = collect_scoped_news(source_registry, freshness_window)
verified = verify_high_impact_items(news_items)

IF verified contains venue_outage OR delisting OR exploit OR major_event:
    veto_related_trades()

IF verified contains macro_event_window:
    reduce_risk_budget_or_delay_entries()

Source Registry Template

Use this template to define what the agent should read.

Notes

• Keep Class C and D as escalation layers, not final authority.
• Add exclusions to avoid spam and duplicates.
• Record which sources are noisy.

⚡ Unum (Strat)

Universal fee-aware trading strategy design and audit skill for OpenClaw.

Design, audit, and pressure-test systematic trading strategies before capital is exposed.

---

What It Does

Unum (Strat) is a universal skill for:

• Designing trading strategies with realistic cost modeling
• Auditing existing strategies for fee survival and edge validation
• Supporting crypto, stocks, ETFs, forex, futures, and more
• Defaulting to conservative spot-style execution
• Optional multi-agent council architecture when justified

---

Installation

clawhub install unum-strat

---

Usage

Invoke in your OpenClaw session:

Design a mean-reversion strategy for BTC/USDC on Coinbase with $500 capital

Audit my grid trading bot - it's underperforming in chop

What fees do I need to overcome on Binance for a 2% target?

---

Core Principles

Only expands beyond defaults when explicitly justified by: 1. User request 2. Venue/cost structure makes it rational 3. Strategy cannot be expressed honestly in default mode

---

Features

• Venue intake templates - Capture exact fees, constraints, order types
• Fee hurdle calculations - Know your break-even before trading
• Capital-bucket routing - Size appropriately for account level
• Deployment profiles - Local vs cloud model routing
• News intelligence policy - When news matters (and when it doesn't)
• Decision tree frameworks - Structured strategy logic

---

Structure

unum-strat/
├── SKILL.md           # Full skill documentation
├── _meta.json         # ClawHub metadata
├── README.md          # This file
├── agents/            # Provider configs
│   └── openai.yaml
├── assets/            # Templates & snippets
│   ├── intake-template.md
│   ├── pseudologic-snippets.md
│   └── source-registry-template.md
└── references/        # Knowledge base
    ├── knowledge.md
    ├── decision-tree.md
    ├── deployment-profile.md
    ├── news-intelligence-policy.md
    └── review-claude-vs-openai.md

---

Version History

---

License

MIT License - see LICENSE file

---

Author

Antonis Corpu GitHub: @corpunum ClawHub: @corpunum

Unum (Strat) - Compact Decision Tree

Start with defaults

If unspecified:

• exposure style -> spot / cash / fully-paid
• entry -> limit only
• exit -> limit only
• protective order -> stop-limit or controlled equivalent
• leverage -> off
• shorting -> off

Step 1 - collect the essentials

Need:

• venue
• asset class
• exact fees
• capital
• universe
• timeframe
• minimum notional / liquidity constraints

Step 2 - reject obvious bad ideas

Reject or down-rank when:

• gross edge does not clear realistic round-trip cost
• minimum order size forces oversized risk
• account is too small for target turnover
• passive-fill assumptions are unrealistic
• backtest ignores fees, spread, slippage, or leakage
• user wants complex architecture without evidence it helps

Step 3 - choose the simplest viable family

Default order: 1. trend / breakout 2. selective mean reversion 3. rotation 4. verified range / grid 5. pair / spread 6. market making 7. derivatives expansion 8. LLM-only prediction -> reject

Step 4 - choose architecture depth

• deterministic only -> default
• strategic / tactical split -> if multi-timeframe or portfolio coordination is needed
• council-enhanced -> only for critique diversity or complex systems

Step 5 - choose deployment questions

Ask hardware / OS only if:

• local models are wanted
• councils are in scope
• deployment planning is requested
• OpenClaw routing or nodes matter

Step 6 - choose news usage

• no news layer -> acceptable for many simple systems
• news as veto/filter -> preferred default
• news as direct trigger -> only with strong evidence and strict verification

Deployment Profile Intake

Use this only when the user wants help with local models, councils, OpenClaw routing, or deployment design.

Core questions

Host layout

• primary host: laptop / desktop / home server / VPS / mixed
• always-on host available: yes / no
• local-only, remote-only, or hybrid setup
• one machine or several machines

Operating system

• OS and version
• containerization available: yes / no
• sandboxing constraints
• filesystem / path constraints if relevant

Compute

• CPU model / core count
• RAM
• GPU model
• VRAM
• storage type and free space

Runtime

• target max decision latency
• acceptable cloud dependency
• privacy constraints
• internet reliability
• power / sleep constraints

OpenClaw / agent capabilities

• web_search available
• web_fetch available
• browser available
• cron available
• node host available
• sub-agents available
• separate worker agents available

Routing heuristics

Keep it simple when:

• no always-on host
• weak local hardware
• tiny account
• no strong need for local inference
• user mainly wants strategy review

Consider mixed local/cloud when:

• always-on host exists
• user wants strategic critique plus deterministic execution
• local hardware can support light or medium local models
• browser / web collection is needed regularly

Consider councils only when:

• user already has a complex stack, or
• the strategy genuinely benefits from multiple viewpoints, or
• there is a need for explicit critique / synthesis / veto roles

Deployment anti-patterns

Reject or warn on:

• cloud reasoning inside per-trade hot path
• no-cache repeated expensive calls
• no degradation mode
• one giant agent doing everything with no separation of concerns
• complex councils on tiny accounts with no measurable edge benefit

Unum (Strat) - Knowledge Base

Purpose

This file is the main policy reference for unum-strat.

It combines:

• the conservative, fee-first posture from the earlier OpenAI draft
• the richer architecture patterns from the newer Claude draft
• the practical deployment and council ideas abstracted from the custom trading brief

The result is meant to be:

• venue-agnostic
• asset-agnostic
• capital-scalable
• usable by a human, a single agent, or an OpenClaw-style multi-agent setup

What the latest Claude draft improved

The latest Claude version materially improved four things:

1. Architecture clarity

• better separation between strategic, tactical, and execution layers
• clearer graceful-degradation logic
• more explicit local vs cloud routing

2. Operational shape

• stronger handoff ideas
• better explanation of why deterministic execution should stay simple
• more concrete signal-policy thinking

3. Regime-awareness

• more explicit "hold in chop" behavior
• stronger emphasis on no-trade as a correct output

4. Capital scaling

• clearer route by account size
• more practical parameter scaling

What should NOT be copied blindly from the latest Claude draft

1. Hardcoded fee tables Generic tables are fine as rough intuition, but they should not override the user's actual displayed fees.

2. Council-first bias Councils are useful when the user already has a complex stack, needs slower strategic synthesis, or wants critique diversity. They are not required for most profitable or sensible trading systems.

3. Too much primary-skill detail Some of the large architecture blocks are better in references than in the top-level skill instructions.

4. Too much implied precision If a skill sounds too certain about fee thresholds, latency cutoffs, or broker hidden costs, it can become brittle.

Architecture patterns worth keeping

1. Strategic / tactical / execution split

Portable pattern:

• strategic layer: regime, allocation, allowed playbook
• tactical layer: timing, ranking, candidate entries
• execution layer: deterministic order placement and risk controls

Why it generalizes:

• works for crypto, stocks, and other assets
• works for simple single-agent systems or multi-agent systems
• prevents expensive reasoning from sitting on the execution hot path

2. Graceful degradation

Good pattern:

• if strategic intelligence is stale or unavailable -> no new entries
• if tactical is degraded -> manage risk only
• if execution is degraded -> stop new orders and alert
• if market state is undefined -> abstain

This should be a default architectural principle in the skill.

3. Learning as constraint promotion

Good pattern:

• log repeated failures
• convert repeated failures into hard rules, filters, or warnings
• do not claim magical autonomous learning

This is the right way to borrow from "self-improving" skill ideas.

4. Deterministic execution

Strong general rule:

• keep the order layer as simple and testable as possible
• use AI for design, critique, classification, or slower synthesis
• avoid AI deciding every live order in real time

Hardware and OS intake policy

When to ask for hardware / OS

Ask only when the user wants:

• local models
• council or multi-agent deployment
• on-device inference
• sub-agent distribution across machines
• node / gateway / VPS planning
• latency-sensitive local processing
• privacy-sensitive processing

Do not ask for hardware details when the user only wants:

• a strategy idea
• a backtest review
• a code review
• a fee-aware viability check

Minimum deployment fields to capture

• host role: laptop / desktop / home server / VPS / mixed
• OS
• CPU
• RAM
• GPU
• VRAM
• storage
• network quality
• always-on availability
• local vs remote execution preference
• whether OpenClaw browser, web tools, cron, or node host are available

Why this matters

These fields influence:

• whether local models are realistic
• whether councils should be local, cloud, or mixed
• whether scheduled scans are safe
• whether browser-heavy collection is practical
• whether the user should keep reasoning central and execution remote

Strategy family ranking

A. Trend / breakout

Best default for most users.

Why:

• lower turnover
• more likely to survive fees
• portable across venues and assets
• easier to reason about and validate

Failure modes:

• whipsaw in chop
• late entries after large expansions
• poor universes with low liquidity

B. Swing mean reversion

Conditional.

Why:

• can work on liquid instruments with moderate costs
• can be expressed simply

Failure modes:

• cheap-looking backtests that vanish under spread and slippage
• repeated small losses in trend regimes

C. Portfolio rotation / ranking

Strong for bigger accounts.

Why:

• low turnover
• good fit for diversified universes
• easier to operate at portfolio level

Failure modes:

• weak universe design
• overfitting ranking formulas
• hidden frictions in rebalances

D. Grid / range systems

Conditional and often overrated.

Why users like them:

• intuitive
• active
• easy to simulate

Why they fail:

• ranges break
• fees accumulate
• users assume fills without adverse selection

E. Pair trade / stat-arb

Advanced and conditional.

Why it can work:

• relationship-based logic can be real

Why it fails:

• unstable relationships
• high execution requirements
• overlooked borrow, spread, or rebalance costs

F. Market making

Rarely a beginner default.

Why it can work:

• spread capture is real in the right environment

Why it fails:

• inventory risk
• adverse selection
• queue-position illusions
• fee drag
• retail venue limitations

G. Perp carry / basis

Real, but opt-in only.

Why it can work:

• not purely directional
• can have structurally identifiable drivers

Why it fails:

• funding instability
• legging risk
• liquidation mechanics
• venue risk

H. LLM-only prediction systems

Reject by default.

Why:

• fragile
• overfit-prone
• rarely cost-aware by construction

Use AI instead for:

• hypothesis generation
• code review
• backtest critique
• regime labeling
• research summarization
• error analysis

News and context intelligence policy

Principle

News should usually act as:

• a filter
• a veto
• a prioritization signal
• a post-trade explanation aid

It should rarely be a direct trigger by itself.

Source classes

Tier 1 - primary sources

Use first:

• exchange notices
• broker notices
• issuer filings and official IR pages
• central bank, regulator, and macro releases
• official project, protocol, or fund communications

Tier 2 - high-quality secondary sources

Use for broad context:

• established financial press
• well-regarded sector publications
• specialist crypto outlets with a clear editorial process

Tier 3 - curated social

Use only as supplemental context:

• selected X lists
• selected analysts / desks / researchers
• selected Reddit communities when used as sentiment or idea discovery only

Tier 4 - trend signals

Use as tertiary context:

• Google Trends or similar interest indicators
• topic-frequency shifts
• search-intent changes
• social tag frequency

Generic source-registry design

For each asset class or venue, maintain a registry with:

• source name
• source class
• purpose
• trust level
• method: web_search / web_fetch / browser
• query template
• update cadence
• if the source is a trigger, filter, veto, or research-only input

Collection method policy

• Use web_search for discovery.
• Use web_fetch for readable text extraction where possible.
• Use browser automation only for JS-heavy or login-gated sites.
• Prefer whitelists, query templates, and time windows.
• Avoid open-ended crawling without a source policy.
• Cache summaries and deduplicate repeated stories.

Example generic query buckets

• official venue incident, maintenance, delisting, listing, fee, margin, custody
• issuer guidance, earnings, filing, buyback, dividend, ETF flow
• macro release, rate decision, CPI, payrolls, geopolitical escalation
• asset-specific exploit, validator outage, protocol proposal, stablecoin depeg, ETF rumor
• social momentum check with strict whitelists and keywords

How to use social correctly

Good use:

• detect that something unusual is being discussed
• escalate to primary-source verification
• use as a risk veto or caution flag

Bad use:

• trade because a hashtag is trending
• assume repost volume equals edge
• let anonymous claims bypass verification

Helper tools and related skill patterns

Prefer first-class OpenClaw tools over fragile helper skills

If the runtime is OpenClaw, default to:

• web tools for search and fetch
• browser for JS-heavy or interactive sources
• cron for recurring scans
• sub-agents for parallel or heavier research
• nodes for cross-device execution
• agent routing for specialized roles

Helper-skill ideas worth referencing, not depending on

Patterns to borrow:

• self-improving / lessons-learned capture
• research-report generation
• browser verification / screenshot confirmation

But do not make the skill dependent on third-party skills being installed.

Missing pieces that improve completeness

1. Compliance and policy awareness

The skill should ask:

• is this personal use, fund use, or client use?
• are there reporting, mandate, or jurisdiction constraints?
• are there wash-sale, PDT, leverage, or restricted-instrument constraints?

2. Data provenance

Capture:

• where market data comes from
• how fresh it is
• whether it includes delistings, splits, or corporate actions
• how missing candles or bad ticks are handled

3. Audit trail

For live systems, require:

• decision logs
• order logs
• fill logs
• strategy-version IDs
• parameter snapshots

4. Rollback

Every live path needs:

• a kill switch
• a fallback mode
• a revert plan
• a "no new entries" mode

5. Session and cost budgets

For LLM-heavy architectures, capture:

• token budget
• inference budget
• maximum decision latency
• caching policy

Decision posture

When uncertain:

• prefer fewer trades
• prefer slower systems
• prefer better instruments
• prefer deterministic execution
• prefer abstaining over forcing a signal

News Intelligence Policy

Goal

Give the agent a generic, portable way to decide:

• what sources to watch
• how to collect them
• what role they play in the strategy
• how much trust to assign them

Source classes

Class A - Primary

Examples:

• exchange status / incident pages
• issuer filings
• central banks
• regulators
• official project announcements
• broker notices

Use for:

• direct risk veto
• rule changes
• venue incidents
• official events

Class B - High-quality secondary

Examples:

• major financial press
• sector publications
• reputable research desks

Use for:

• synthesis
• context
• cross-checking

Class C - Specialist community / social

Examples:

• curated X lists
• curated Reddit communities
• selected analysts
• selected builders or desks

Use for:

• idea discovery
• anomaly detection
• early warning that must be verified elsewhere

Class D - Trend / popularity

Examples:

• Google Trends
• search-intent changes
• tag frequency
• keyword spikes

Use for:

• demand / attention context
• prioritization
• regime color

Never use Class C or D alone as final trade justification.

Query design

For each venue or asset, define:

• keywords
• exclusions
• whitelists
• refresh cadence
• escalation rules

Example fields

• topic
• source class
• query string
• include terms
• exclude terms
• freshness window
• escalation target
• action role: trigger / filter / veto / monitor / research-only

Collection methods

web_search

Use first for:

• discovery
• recency checks
• broad scanning
• monitoring specific query buckets

web_fetch

Use for:

• article text extraction
• official pages
• readable summaries
• lower-friction structured ingest

browser

Use only when needed:

• JS-heavy sites
• interactive pages
• login-protected pages
• screenshot verification

cron or scheduled scans

Use for:

• recurring monitoring
• digest generation
• pre-market / pre-session checks
• high-priority venue and incident scans

Generic escalation ladder

1. detect something from search, social, or trend data 2. verify with a primary or high-quality secondary source 3. decide whether it is:

• a veto
• a filter
• a research note
• irrelevant noise

4. log the decision 5. expire stale stories and deduplicate repeats

Good generic query buckets

• listing / delisting / halt / maintenance / outage
• funding / borrow / margin / fee / custody change
• ETF / filing / guidance / earnings / buyback / split
• exploit / depeg / governance vote / fork / liquidation
• macro release / rate decision / CPI / payroll / sanctions / war escalation

Risk controls

• cap the number of social-only items promoted to review
• require primary-source confirmation for any trade-impacting alert
• maintain per-source trust levels
• keep a stale-news cutoff
• record whether a source has historically been noisy

Review - Claude latest vs prior OpenAI-style Unum

Bottom line

The latest Claude draft is a better architecture document than the earlier versions. It is not yet the best top-level skill without edits.

Best merge outcome:

• keep the OpenAI-style skeptical core and generality
• import Claude's architecture and degradation patterns
• avoid Claude's tendency to hardcode too much cost and deployment detail into the primary skill

What Claude now does better

1. Council and routing mechanics

Claude's latest version is much better at:

• strategic vs tactical separation
• local vs cloud routing
• graceful degradation
• hold / abstain behavior

These should be preserved.

2. Operating-model realism

It understands that:

• execution should stay deterministic
• cloud reasoning should not sit on the hot path
• multi-agent systems need clear handoffs

These are strong ideas.

3. Better use of the custom brief

Claude incorporated:

• councils
• slow brain / fast hands split
• degradation logic
• no-trade validity

Those were the right things to abstract.

Where Claude still overshoots

1. Hardcoded fee assumptions

It still presents generic venue and broker fee figures in a way that can sound authoritative. This is risky because real viability depends on the user's exact displayed fees and actual fill behavior.

2. Council creep

It makes council architecture feel close to the default for sophisticated systems. That is too aggressive. Many users should stay with:

• single bot
• deterministic logic
• one review model at design time

3. Too much detail in the primary file

Large model-routing and regime blocks are useful, but they belong mostly in reference files. The top-level skill should stay directive and portable.

4. Some pseudo-precision

Any exact latency or hidden-cost number can age badly or be misapplied. The skill should speak in decision rules more than pseudo-benchmarks.

What the OpenAI-style version still does better

1. Simplicity

The earlier OpenAI-style version better answers:

• can this survive costs?
• what strategy family fits?
• what should be rejected quickly?

2. Universal portability

It is less tied to one bot architecture and easier to invoke for any user.

3. Better default posture

It more strongly preserves:

• passive execution first
• spot first
• small-account skepticism
• AI as assistant, not edge

Merge rule adopted in R3

Use this priority:

1. Skeptical decision policy from OpenAI-style version 2. Architecture patterns from Claude latest 3. Portable process control from the custom trading brief 4. Generic source governance and deployment intake added in this revision

Practical recommendation

For the next external-model round, ask them to critique these exact questions: 1. Should hardware intake be conditional or always-on? 2. Should councils live in the top-level skill or only references? 3. How should the news source registry be structured? 4. What is the smallest complete version of the skill that still feels publishable? 5. Which parts are instructions versus knowledge versus templates?