daisy-financial-research

name	daisy-financial-research
description	Use when user asks for stock / company / sector deep-dive research, DCF or valuation, financial comparison, market-catalyst analysis, or stock screening across A-share, Hong Kong, or US markets. Plans, gathers data via Tushare and web search, validates numbers, and produces a sourced report.
license	MIT
homepage	https://github.com/Agents365-ai/daisy-financial-research
compatibility	Requires Python 3.9+ with `tushare`, `pandas`, `requests` for screening / Tushare scripts. TUSHARE_TOKEN env var required for any Tushare call. No external CLI tools needed for the core analysis workflow.
platforms	["macos","linux","windows"]
metadata	{"openclaw":{"requires":{"bins":"[Truncated]"},"emoji":"📈","os":["darwin","linux","win32"]},"hermes":{"tags":["finance","research","stocks","valuation","dcf","tushare","agent-workflow","screening"],"category":"research","related_skills":["tushare"]},"author":"https://space.bilibili.com/1107534197","version":"2.6.0"}

Daisy Financial Research

Autonomous stock / company / sector research workflow — plan, gather data, validate numbers, produce a sourced report. Inspired by the virattt/dexter design patterns (iterative agent loop, scratchpad, soft loop limits, numerical validation), packaged as a multi-platform skill.

Dexter’s key ideas:

1. Treat financial research as an iterative agent loop, not a one-shot answer.
2. First create a compact research plan, then execute data-gathering steps.
3. Use a scratchpad as the single source of truth for tool calls, results, assumptions, and partial conclusions.
4. Prefer high-level meta-queries to finance data tools, but fall back to specific interfaces when needed.
5. Use soft loop limits and repeat-query detection to avoid runaway tool use.
6. Validate numerical answers before finalizing.
7. For valuation, use an explicit DCF workflow with sensitivity analysis and sanity checks.
8. Output concise, sourced analysis with caveats; never present investment advice as certainty.

Python interpreter convention

Command examples in this skill use a bare python. Substitute it with whichever interpreter in the caller's environment has tushare, pandas, and requests installed — for example python3, ~/.hermes/venv/bin/python, ~\.hermes\venv\Scripts\python.exe, a conda env, uv run python, or a pyenv-managed version. The skill does not assume any specific install location and works on macOS, Linux, and Windows.

Agent-native CLI conventions

All scripts under scripts/ follow a uniform agent-native contract so an LLM agent can call them without parsing prose:

• Output format auto-detection. When stdout is not a TTY (e.g. captured by subprocess.run), scripts emit a single JSON envelope on stdout. When stdout is a TTY, scripts emit the legacy human table. Override with --format json|table.
• Stable success envelope: {"ok": true, "data": {...}, "meta": {"schema_version", "request_id", "latency_ms"}}.
• Stable error envelope: {"ok": false, "error": {"code", "message", "retryable", "context"}, "meta": {...}}. Error messages stay on stderr in table mode.
• Schema introspection. python <this-skill-dir>/scripts/<name>.py --schema returns parameter types, preset registries, upstream interfaces, and error codes as JSON. Agents should prefer over parsing .