Openmobius Skill

OpenMobius-skill — Multi-School Trading Knowledge Skill

A unified skill for four interaction intents with a curated multi-school knowledge base (726 concept cards + 1282 case cards) distilled from 300+ trading videos and live lessons across 12 curated source collections.

Core principle: every trading-analysis claim must be grounded in (a) visible chart evidence or (b) a retrieved knowledge-base rule. Capability claims must be grounded in the installed inventory and declared profile contract. No fabrication — when uncertain, state so explicitly.

Freshness mandate — NEVER answer market questions from memory

Any user message that mentions an asset + timeframe — even without the word "现在" / "now" — REQUIRES a fresh kb_klines.py indicators or kb_klines.py chart call in the current turn. Examples:

• "BTC 1h 怎么样" — yes, call API now
• "ETH 现在怎么样" — yes
• "茅台日线分析下" — yes
• "金子 4 小时" — yes
• "BTC 还在跌吗" — yes, even though no timeframe given (default to user's implied tf or ask), the freshness rule still applies

This live-fetch mandate applies to current-market requests. If the user explicitly asks to analyze OHLCV they supplied, preserve that snapshot instead of replacing it with live data; use the parsed-data provenance footer from workflows/klines.md and state that its freshness is not independently verified.

Control-plane exception: a question about which analysis model/School/mode the installed skill supports, or whether a named School can analyze a market, is capability discovery rather than a request to analyze that market. Route it to the Q&A capability-discovery branch before applying asset/timeframe rules; do not fetch market data even when the question names an asset or timeframe.

Capability-gate exception: first resolve the requested market-analysis route. If its required native analyzer/filter is unsupported, stop before any network call or artifact generation, report the capability gap, and do not add a fabricated freshness footer. The freshness requirements below apply only after a market route passes that gate.

Hard rules:

1. DO NOT cite prices, levels, swing pivots, BOS/CHoCH events, or structure from your training data ("BTC was around 60K-100K" → forbidden).
2. DO NOT reuse price data from earlier turns in the same conversation if more than 60 seconds have passed — refetch.
3. DO NOT invent timestamps, "data as of" labels, or "real-time" claims that are not literally in the API response's freshness block or the user-supplied dataset.
4. For API-backed current-market analysis, the only source of truth is a freshness block returned by an API call made in this turn. If you have not yet called the API in this turn, you must say: "我需要先拉一下最新数据" and call the API before answering.

Every market-analysis reply that proceeds past the capability gate MUST use the matching footer: API-backed analysis uses the freshness footer; analysis of user-pasted OHLCV uses the parsed-data provenance footer (see workflows/klines.md Step 5). A reply without the applicable footer is incomplete.

If the API response's freshness.is_stale == true (latest bar older than 2 × interval), explicitly tell the user the market may be closed or the API may be delayed — do not silently report stale data as live.

Data source disclosure (canonical answer)

When the user asks about data origin — any of: "数据从哪来 / 数据源 / data source / where is this data from / 你用什么数据 / 是实时吗 / real-time? / 怎么取的数据" — respond with the canonical disclosure below. Substitute the live values from the most recent API call's freshness block + any visible exchange/market/symbol fields.

Canonical answer template (bilingual)

**Data source / 数据来源**: Mobius Quant API (api.mobiusquant.ai)

Current request / 本次请求:
- exchange = `<exchange from response>`
- market   = `<market from response>` (spot / perp / cn / hk / us / forex)
- symbol   = `<symbol from response>`
- fetched_at (UTC)      = `<freshness.fetched_at>`
- last_bar_open (UTC)   = `<freshness.last_bar_open_time_utc>`
- last_bar_age_seconds  = `<freshness.last_bar_age_seconds>` (is_stale=<is_stale>)

**About upstream sources / 关于上游来源**: Mobius Quant exposes OHLCV,
technical indicators, and SMC structural signals as an aggregator. Which
underlying exchanges or data vendors it connects to upstream, and
whether direct-feed vs aggregated — **this skill cannot verify**. See
https://www.mobiusquant.ai/ for details.

Hard rules — what you must NOT say about the data source

• DO NOT name specific upstream vendors unless the exact string appears in the API response's exchange field. Allowed values are what symbols_search / klines / indicators literally return (e.g. binance, bybit, okx, hyperliquid for crypto; cn/hk/us for stocks).
• DO NOT name web data providers (新浪财经 / Yahoo Finance / TradingView / 东方财富 / 同花顺 / Bloomberg / etc.) — you cannot verify any of these.
• DO NOT describe the upstream pipeline ("Mobius pulls from Binance via WebSocket" / "tick-level feed" / "delayed 15 min") — you cannot verify any such claim.
• DO NOT make freshness claims beyond what freshness.is_stale reports. Use the literal last_bar_age_seconds number.

What you CAN say

• The API endpoint (api.mobiusquant.ai)
• The exact JSON fields returned (exchange / market / symbol / count / current_price / freshness.*)
• That the SMC structural indicator is computed server-side by Mobius
• A pointer to https://www.mobiusquant.ai/ for upstream details

Host-neutral runtime and artifact paths

Resolve these placeholders for the current host before running a workflow. They are documentation tokens, not literal paths or shell variables:

• <SKILL_ROOT> — the directory containing the loaded SKILL.md. Run all commands with this directory as the working directory so relative scripts/ paths resolve without depending on the user's current directory.
• <PYTHON> — the Python executable selected for this installed skill. Resolve it from the platform/installer-managed runtime; Windows and POSIX executable paths differ, and a managed host may expose its own runner. Do not assume python or python3 is available on PATH.
• <TEMP_DIR> — a writable, task-specific temporary directory created through the current host's temporary-directory facility. Do not assume a particular POSIX or Windows system path exists.
• <USER_OUTPUT_DIR> — a writable directory selected by the user or exposed by the host for durable artifacts that must be returned. Do not use a repository checkout or developer-machine path as the implicit output location.
• <INPUT_IMAGE> — the host-resolved path to the user's attached chart.

Never execute the angle-bracket placeholders literally. Quote each resolved path according to the current command runner when it contains spaces. Command blocks use logical argument lists and avoid shell-only pipes, heredocs, and continuation syntax. Create JSON/text inputs with the host's file-writing tool or a JSON serializer, then pass the resulting file path to the script.

For WorkBuddy packaging compatibility, a command line that begins with kb_retrieve.py is launcher-neutral shorthand only. Before execution it must be expanded to <PYTHON> scripts/kb_retrieve.py; never assume kb_retrieve.py is on PATH.

Always retrieve from the knowledge base first

The knowledge base contains rule-based identification criteria and documented pitfalls that generic training data lacks. Resolve the route and confirm its capabilities, then retrieve within that route before synthesizing — don't answer trading questions from memory alone and don't widen a selected school/source boundary silently.

The semantic-card retrieval mandate applies to trading-knowledge answers, not to control-plane capability discovery. Capability discovery inspects the installed School inventory and declared profile contract without running a normal query/top-K search; follow the special case in workflows/qna.md.

Analysis profile orchestration

First detect capability-discovery questions about the installed skill's available models/profiles, lenses, Schools, modes, supported intents, or a named School's market-analysis support. They remain intent=qna, but take priority over the default strict ICT/SMC route and any asset/timeframe or chart routing. Read both workflows/qna.md and workflows/analysis_profiles.md, inspect the installed inventory with kb_retrieve.py --layer school --list-schools --format json (expanded through the launcher-neutral rule above), then answer immediately from that inventory and the declared profile contract. This is an intentionally bounded, single-agent control-plane operation: do not delegate to a subagent/background task, recursively invoke this skill, run Git, scan source code/cards/manifests, or verify analyzer implementations. Do not construct or inherit an analytical School route for this branch, and stop after the capability response.

For all normal analysis and knowledge requests, resolve a route before retrieval, indicator calls, analysis, or drawing:

route = {intent, mode, primary_lens, secondary_lenses, schools, sources, capabilities}

• intent must be exactly one of qna, analyze, annotate, or klines. Do not emit aliases such as kline_analysis.
• capabilities must always be an object, never a list or string. Use the canonical fields and values defined in workflows/analysis_profiles.md.
• For the plain default route, set exact_primary_school_filter=true, source_filter=not_requested, intent_supported=true, and reason=null; set native_market_analyzer=not_required for Q&A or supported for a market intent. This default does not require loading the profile reference.
• lens (also called a profile) is an analytical methodology such as ict_smc or chanlun; source is a corpus/teacher collection such as Teach-Wuyuan. A source does not automatically select a lens.
• With no explicit lens, school, source, or composition selector, use mode=strict, primary_lens=ict_smc, and schools=[ICT, SMC]; retrieve with --layer school --schools ICT SMC.
• A single explicit selector is strict by default. In Phase 1, compare is supported for Q&A only; market-analysis, chart, and annotation comparisons fail closed before network or artifact work. augment gives one primary lens authority over bias and trade levels while secondary lenses only confirm, challenge, or add risk context.
• School-scoped grounding uses school_knowledge_v2, which omits cross-School fused rules that cannot be attributed. Any requested source uses source_evidence_v2 with --layer evidence --sources ...; combine it with --schools ... for an exact intersection. Never use the fused canonical layer to claim strict School/source isolation.
• School/evidence queries use hard-filtered hybrid retrieval by default (BM25 + semantic RRF over independently embedded scoped documents). Keep --search-mode auto unless diagnosing retrieval; exact terms/aliases stay first and the hard School/source boundary is never widened.
• Never silently fall back from an explicit lens/source to ict_smc or to an unfiltered search. Check capabilities before doing work and report an unsupported or empty route plainly.
• ChanLun knowledge Q&A is supported, but this skill currently has no native ChanLun market-structure analyzer or overlay. Never present SMC indicator output as ChanLun analysis.

Read workflows/analysis_profiles.md whenever the user names a lens/school/source, requests comparison or augmentation, excludes a profile, or the selected capability is uncertain. Plain default ict_smc requests can proceed directly to the intent workflow below.

Market-analysis output format is mandatory

The Analyze and Kline workflows end in a synthesis step with mandatory ## section headings. Those headings must appear verbatim and in the specified order. Q&A and Annotate use the output structures defined in their own workflow documents. A capability-gap response that stops before analysis is also exempt from the market-analysis template and freshness footer.

Scenario Router

Pick the right sub-workflow based on the user's input. Each workflow has detailed steps in its own document:

Chart output is part of the standard reply for the Analyze and Kline analysis workflows — render a PNG and include its path in the output. Skip the chart step ONLY when the user explicitly opts out ("只要文字" / "skip chart" / "no image" / "不用画图"). For user-pasted OHLCV, follow the Path B exception in workflows/klines.md and never fetch a different live series merely to satisfy chart output.

How to route:

1. Detect capability discovery first; if matched, follow its Q&A control-plane special case and stop without applying an analytical route
2. Otherwise resolve the route above; load analysis_profiles.md when its trigger applies
3. Identify the user's intent in the scenario table
4. Use the Read tool to load the relevant workflow document (relative to this SKILL.md: workflows/<name>.md)
5. Follow that workflow while preserving the route's lens/source boundaries

Important — Analyze workflow now auto-fetches data: If a chart is attached AND the asset/timeframe is identifiable from the chart, analyze.md will fetch real OHLCV from Mobius API to complement visual analysis with precise prices. This is on by default; user can opt out by saying "只看图不拉数据" / "skip data fetch".

Note: The Analyze workflow already auto-generates an annotated image as its final step. You do NOT need to separately invoke Annotate after Analyze unless the user wants to re-render with different parameters (different colors, new bbox, JSON-only output, etc.).

Two chart generation paths

When the user wants a visual chart, choose the right tool:

For path #2, the typical pipeline is:

# 1. Pull K-lines + auto-filled SMC structural overlay for an ict_smc route
<PYTHON> scripts/kb_klines.py chart --query "BTC" --interval 1h --limit 200 --output <TEMP_DIR>/chart.json

# 2. Optionally create a separate trade-setup JSON containing only entry/SL/
#    target hlines; do not duplicate the structural items already auto-filled.

# 3. Render PNG (add --trade-setup <TEMP_DIR>/setup.json only when one exists)
<PYTHON> scripts/kb_klines.py render --input <TEMP_DIR>/chart.json --output <USER_OUTPUT_DIR>/chart.png --theme dark --width 1400 --height 900

Indicator fetching