SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsanyfinancial

anyfinancial

Data & analytics

View repository

Updated 10-16 07:27

About this skill

AnyFinancial

Any AnyFinancial task runs as three phases. Identify where the request sits, run the phases it needs in order, and load the phase's SKILL.md(s).

The Three Phases

Phase 1 — Prepare the Data. Get the data the task needs, from one of two sources:

  • Hosted datasets — historical bars and reference data for backtests and research. Flow is catalog → schema → query. Load data/SKILL.md.
  • Real-time / API data — recent/realtime provider APIs, split by market: realtime-api-data/us/SKILL.md (US) and realtime-api-data/cn/SKILL.md (CN), entry at realtime-api-data/SKILL.md.

Phase 2 — Analyze the Data. Write the code and compute the result: derive indicators, run event-driven backtests, evaluate signals, measure risk. Load backtesting/SKILL.md (with data/SKILL.md for the bars it consumes). This is where strategy logic and metric computation live.

Phase 3 — Generate the Report. Turn the analysis into a delivered report:

  • Templates — reusable finance report structures (statement/valuation/ company/industry). Load financial-templates/SKILL.md. If no template fits, you (or the user) may use your own structure — but every report, templated or not, MUST use the Kami style (report-style/README.md).
  • Price charts — when the report shows a traded instrument's price over time (OHLCV, candlestick, equity curve, backtest markers, RSI/MACD panes), render with TradingView Lightweight Charts via financial-charts/SKILL.md. Keep ECharts only for generic charts (heatmap, pie, bar, scatter, treemap, dashboards).
  • Form is always Kami, and reports are delivered as uploaded HTML artifacts (see HTML Artifact Output below).

Route First

Match the user's intent to a phase, then load that phase's SKILL.md.

User intent Phase Load next
Discover/read hosted historical data, pull bars into a backtest cache, validate coverage 1 · Prepare (hosted) data/SKILL.md
Latest quote, recent bar, current/recent market snapshot, point fundamentals, provider news 1 · Prepare (real-time/API) realtime-api-data/SKILL.md
US direct/recent market data 1 · Prepare (real-time/API · US) realtime-api-data/us/SKILL.md
CN direct/recent market data, CN A-shares, CN valuation/financials/universe/news 1 · Prepare (real-time/API · CN) realtime-api-data/cn/SKILL.md
Backtest, simulate strategy, evaluate signal, Sharpe/drawdown, out-of-sample validation, historical strategy performance 2 · Analyze backtesting/SKILL.md (+ data/SKILL.md)
Financial statement analysis structure, valuation framework, company/industry research outline, finance-specific report pattern 3 · Report (template) financial-templates/SKILL.md
Any report styling / HTML output form 3 · Report (style) report-style/README.md
Candlestick, OHLCV, price+volume, indicator overlays, backtest buy/sell markers, equity curve, RSI/MACD panes 3 · Report (price chart) financial-charts/SKILL.md

Phase Rules

  • Phase 1 (Prepare). Hosted-data access (data/SKILL.md) follows catalog -> schema -> query and is primarily used to prepare or inspect data for later phases. Real-time/API data is for recent/realtime provider APIs, split into US (realtime-api-data/us/SKILL.md) and CN (realtime-api-data/cn/SKILL.md). Do not present recent/realtime data from memory.
  • Phase 2 (Analyze). Backtesting/analysis (backtesting/SKILL.md) consumes Phase 1 bars and uses the local historical data service and NautilusTrader workflow. Never present a return without drawdown, trade count, costs, and in-sample vs out-of-sample status.
  • Phase 3 (Report). Financial Templates are internally documented frameworks, not API calls; label them as templates unless populated with verified data. If no template fits, use your own structure — but the report form is always Kami (report-style/). Price/OHLCV charts use financial-charts/ (TradingView Lightweight Charts); generic charts use ECharts.
  • AnyFinancial is self-contained. US real-time/API data behavior is documented and executable under realtime-api-data/us/ and realtime-api-data/scripts/; CN real-time/API data is documented under realtime-api-data/cn/.

Composition Patterns

Each pattern threads the three phases: Prepare → Analyze → Report.

Strategy evaluation (backtest report)

  1. Prepare: data/SKILL.md for historical bars.
  2. Analyze: backtesting/SKILL.md — run in-sample and out-of-sample.
  3. Report: Kami-styled HTML with costs/limitations; render the price series and trade markers with financial-charts/SKILL.md, the equity curve as a line/area chart.

Recent market data lookup

  1. Prepare: realtime-api-data/SKILL.md, then the US or CN sub-skill; query the provider API and record timestamps/source fields.
  2. Report: if the snapshot renders as HTML, use Kami; use financial-charts/SKILL.md for any price/OHLCV chart.

Template-driven analysis

  1. Analyze/Report: financial-templates/SKILL.md, choose the matching template; keep placeholders if no verified data source is available and do not invent figures.
  2. If no template fits, use your own structure — but keep the Kami form (report-style/).

HTML Artifact Output (Phase 3 — all reports)

Any task that produces a report, analysis, dashboard, chart, or backtest result for the user MUST render the HTML report and upload it to the Artifact Store, then reference it in the final chat with a <rebyte-artifacts> tag containing only the file name (not a path, not inline HTML). An un-uploaded local file is never delivered to the user.

<rebyte-artifacts>aapl_sma_backtest_20260705.html</rebyte-artifacts>

Every HTML report MUST be styled with the Kami design system — no exceptions. The report's content comes from Phases 1–2; its form is always Kami: warm parchment canvas (#f5f4ed, never pure white), single ink-blue accent (#1B365D), serif-led hierarchy (one serif, weight 500, no bold/italic), warm grays only, and editorial whitespace.

A report artifact is two parts: the shared Kami style and a content template. The shared style is report-style/styles.css + report-style/ report.css; the content template (the report HTML) holds only content and structure and links those two stylesheets — it carries no inline CSS and no duplicated Kami tokens. styles.css loads before report.css. To restyle every report, edit the shared CSS once, never a template. The full mandate, palette, class list, and link-vs-bundle wiring live in report-style/README.md (alongside report-style/CHEATSHEET.md and report-style/design.md) — read it before building any report.

Rules:

  • Build the HTML in the working directory (/code/), then upload it to the Artifact Store before ending the turn. The full upload flow (auth, signed upload URLs, PUT, and the mandatory instruction tag) is documented in the top-level CLAUDE.md under Artifact Store. In short:
    1. Ensure AUTH_TOKEN and API_URL are set (see CLAUDE.md → Rebyte API Authentication).
    2. POST $API_URL/api/artifacts/upload-url with the file(s) and contentType: "text/html".
    3. PUT each HTML file to its signed uploadUrl.
    4. Follow the returned instruction — emit each delivered file in a <rebyte-artifacts> tag.
  • File name is kebab- or snake-case, ends in .html, is unique per run (include ticker/run-name and an ISO date). Do not reuse a name across runs.
  • The chat body may contain a short markdown summary of findings, but the full HTML report is delivered ONLY as an uploaded artifact. Do not paste <html>…</html> or long report HTML inline.
  • One <rebyte-artifacts> tag per delivered file; emit multiple tags if a task produces multiple HTML artifacts (e.g., in_sample.html, out_of_sample.html).
  • If the HTML embeds images/fonts/other assets, upload those with "public": true and embed the returned publicUrl (no relative paths, no base64) — see CLAUDE.md → Single HTML File Outputs.
  • Style the HTML with the Kami design system (see report-style/): warm parchment #f5f4ed canvas, ink-blue #1B365D accent, serif-led hierarchy (weight 500, no bold/italic), warm grays, editorial whitespace. The report is two parts — link the shared report-style/styles.css then report-style/report.css (as hosted public-artifact publicUrls, or bundle report-style/ alongside); do not inline or duplicate the CSS. Never ship a report on a pure-white, system-default page.
  • Charts: if the report shows a traded instrument's price over time (OHLCV, candlestick, price+volume, indicator overlays, backtest markers, equity curve, RSI/MACD panes), render it with TradingView Lightweight Charts via financial-charts/SKILL.md — delivered as its own artifact (spec block + a sibling data JSON), not inline. Use ECharts only for generic charts (heatmap, pie, bar, scatter, treemap, dashboards).
  • This upload convention is the umbrella: it applies to Backtesting reports, Real-time/API Data snapshots that render as HTML, populated Financial Templates, and TradingView price-chart artifacts — all styled with Kami.

See financial-templates/output-patterns.md#html-artifact-output for the concrete upload steps and backtesting/SKILL.md#phase-5--results-reporting for the Backtesting-specific application.

Do Not

  • Do not delegate to external skill repos.
  • Do not guess financial table columns. Read the catalog and schema first.
  • Do not present recent/realtime data from memory.
  • Do not treat Financial Templates as sourced analysis unless data has been fetched, cited, or supplied by the user.
  • Do not present backtest returns without drawdown, trade count, costs, and limitations.
  • Do not paste report HTML inline in the chat body. Upload it to the Artifact Store and reference the file name in a <rebyte-artifacts> tag.
  • Do not leave the only copy of a report on local disk. An un-uploaded file is never delivered to the user.
  • Do not ship an HTML report that ignores Kami styling (pure-white background, bold/italic serif, cool grays, a second accent color, or no styles.css). Form is always Kami — see report-style/.