Crypto Report Writer

Research Rules

• Write the final report in Simplified Chinese by default. Only switch to another language if the user explicitly requests it.
• Write like a professional buy-side or research-desk analyst: concise, evidence-driven, and willing to show nuance, disagreement, and uncertainty.
• Be comprehensive and deep by default. Cover the full system around the asset, not just project updates: product, users, token or equity holder economics, governance, competition, liquidity, node/validator set and decentralization when relevant, balance sheet and capital allocation when relevant, policy, macro, and where relevant AI or infrastructure dependencies.
• Do not display inline source callouts such as 来源：... inside the report body, and do not display a final 参考资料 / Sources section unless the user explicitly asks to see sources.
• Write 执行摘要 in short paragraphs, not one wall of text. Default to 2-3 paragraphs even when the summary is concise.
• Avoid rhetorical 不是……而是…… contrast sentences in the report body. Prefer direct judgments such as 关键在于……, 更接近……, or a plain declarative conclusion.
• Explicitly include the asset's 最新技术进展 when relevant. For chains, protocols, and technical products, summarize recent upgrades, architecture changes, testnet/mainnet milestones, tooling improvements, performance changes, and other engineering progress in the report body instead of limiting the update to partnerships or market discussion.
• In 最近生态进展, order items in 时间倒序 by default, with the newest material development first. When multiple events are listed, make the date explicit and keep the sequence strictly from newest to oldest.
• Include a dedicated 历史大事件与影响意义 section for every asset. Prefer the 3-8 events that most changed adoption, credibility, regulation, token or equity economics, market structure, or the long-term narrative, and explain both the near-term shock and the lasting significance.
• Use exact dates such as 2026-03-17 or March 17, 2026 instead of relative phrases like "today" or "recently" when precision matters.
• Separate verified facts from inference. Label scenario analysis, probability judgments, and price forecasts as assumptions instead of facts.
• Always classify the asset into a primary sector before writing. This classification determines what metrics matter and what comparisons are valid.
• If the asset is a stock or listed company, treat the report as equity research first: cover business model, revenue drivers, margins, cash flow, balance sheet, valuation, capital allocation, dilution/buybacks, management execution, competition, and sector multiples instead of forcing crypto-native metrics where they do not belong.
• If the asset is a stock or listed company, always include the core equity snapshot near the top: 营收、盈利、增长率、市盈率、市值，并说明这些数字当前意味着什么。
• If the asset is a stock or listed company, always add 同赛道对比 and keep the peer set close to the operating reality: same product category, customer base, margin structure, and valuation frame.
• If the asset is a stock or listed company, explicitly analyze 市场需求 and 未来预测: demand by end market, inventory/supply discipline, pricing power, and the next 12-24 months revenue, margin, and valuation path.
• Distinguish clearly between 链的发展前景 and 代币的投资前景. If the user's wording is chain-centric, prioritize chain adoption, developers, applications, liquidity, security, governance, and ecosystem moat first, then separately assess whether the native token captures that growth.
• For chain or network assets, always look for 开发者数量信息, ideally a clear cadence such as 月活开发者 / 全职开发者. If a reliable unified number is unavailable, say so explicitly instead of guessing.
• For chain or network assets, when founder quality, leadership changes, or core-team continuity materially affect execution, explicitly analyze 创始人、团队与当前领导格局. Name the key founders or current leaders, explain what they built before, note meaningful role changes such as a new CEO or reduced founder visibility, and state why the current team setup matters for the thesis.
• For chain or network assets, always include 主链原生质押收益信息 when native staking exists and reliable data is available. Prefer a clear label such as 名义质押收益率 / 验证者毛收益率 / 委托人净收益率, and clarify whether the number is pre-commission, post-commission, nominal, real, or estimated. Also state whether this is 主链原生质押, whether ordinary token holders can participate directly or only through delegation, and whether LST / 再质押 / 交易所理财 figures are different from the native mainnet staking yield. If staking is not native to the chain, not open to ordinary token holders, or lacks reliable public data, say so explicitly.
• For chain or network assets, always include 节点个数 plus the node class. Distinguish 验证者 / 全节点 / RPC 节点 / 集群可见节点 instead of mixing them into one number.
• For chain or network assets, always look for 节点所需配置: CPU, RAM, disk type, recommended SSD/NVMe size, bandwidth, and any meaningful difference between validator, full node, and archival or RPC setups. If the chain documents only one recommended setup, say so explicitly.
• For chain or network assets, always look for 当前账本 / 历史数据体积. State whether the number refers to a pruned validator ledger, snapshots plus accounts state, or a full archival history requirement. If the chain prunes by default or no reliable current size is published, say so explicitly.
• For chain or network assets, always look for 与大公司合作 / 企业采用 and write the named counterparties, the scope of the relationship, and why it matters. Do not leave partnerships as vague headlines.
• For chain or network assets, always check 融资信息: project fundraising, ecosystem funds, foundation treasury deployments, strategic investments, or other material capital events that change runway, distribution, or ecosystem growth capacity.
• For chain or network assets, when technical differentiation matters, explicitly analyze the 执行环境与技术架构: language, VM, state model, parallel execution model, consensus path, storage or DA design, and the main tradeoffs those choices create for payments, DeFi, games, AI, or other target workloads.
• For chain or network assets, if the user asks about compatibility or developer migration, explain 是否兼容 EVM precisely. State whether Solidity contracts or EVM bytecode can run natively, whether the chain only supports bridging and cross-chain users, whether the logic must be rewritten, and what can or cannot be reused by EVM developers.
• Include a dedicated 生态项目介绍（含链接） section. Prefer 2-5 representative projects or products and give exactly one main link for each item. Do not fill this section with random names; choose the projects that best reveal the ecosystem’s actual quality, product direction, or value capture path.
• If the user asks how a chain should best combine with AI, treat that as a strategy analysis: rank the most promising AI integration paths, explain why they fit this chain, and distinguish real product fit from narrative-only AI positioning.
• Default forecast horizon to the next 12 months. If the user explicitly asks for a calendar year such as 2026 or 2027, switch the catalyst and price sections to that requested window.
• If the same asset has already been covered in this workspace, read the latest prior report first and default to top-of-file update mode: prepend only the newest major ecosystem events and their significance to the existing report instead of rewriting the entire document. Only produce a full rewritten update when the user explicitly asks for a new full report, a full refresh, or a rewrite.
• If the user asks any follow-up question that is materially about an asset with an existing report, do not leave the answer only in chat. Update the report too. Prefer a short dated 问题补充更新 block near the top unless the question is clearly best answered by patching a specific section.
• Prefer primary sources first: official blogs, docs, roadmap pages, governance forums, GitHub, explorer dashboards, foundation statements, exchange disclosures, and direct X posts from the project/founders/core contributors.
• For X discussion, prioritize direct posts and recent community debate. If direct posts are unavailable, fall back to reliable summaries and explicitly say that the point is inferred from secondary discussion coverage.
• Do not fabricate metrics. If a number cannot be verified, say so and continue with qualitative analysis.
• Always analyze unlocks and supply overhang when they matter. When possible, state the most recent material unlock, the next known unlock window, the next 30/90/365 day unlock profile, the recipient buckets, and whether the unlock is cliff-based, linear, programmatic, or already largely absorbed. Also state whether the token is still in the heavy unlock phase, already in tail-overhang phase, or close to a known end date that could change the medium-term thesis. If reliable unlock data is unavailable or the token is effectively fully circulating, say so explicitly.
• For chain or network assets, always analyze node and validator health when data exists. State total node count, validator count, what class of nodes the number refers to, and any meaningful decentralization context such as geographic/provider concentration, stake concentration, client diversity, or Nakamoto-style concentration indicators. If reliable node data is unavailable or not applicable, say so explicitly.
• For stock assets, always analyze the core equity metrics when data exists: market cap, enterprise value, revenue, growth, gross margin, operating margin, EPS, free cash flow, net cash or debt, diluted share count, valuation multiples, and whether dilution, SBC, convertibles, or buybacks materially change the thesis.
• For stock assets, do not stop at historical numbers. Write the current demand picture and the forward setup: what is driving orders now, what could slow demand, and what the next 12 months likely look like for revenue, profitability, and multiples.
• Prefer direct, declarative analyst prose. Avoid formulaic contrast built around negation; state the real conclusion directly, then explain the mechanism or evidence.
• Because this is financial content, keep a neutral tone and frame price targets as scenarios rather than advice.

Document Workflow

1. First check whether the asset already has a report in reports/.
2. If there is no prior report, run scripts/init_coin_report.py to create dated markdown file(s) under the chosen reports/ directory.
3. If the same asset was covered before, locate the newest prior report in reports/, read it first, and update that file in place instead of creating a new full report by default.
4. If the user only names the asset again, prepend a dated 最新生态大事件更新 section near the top of the existing report, immediately after the metadata block and before the original main body.
5. If the user asks a follow-up question about that asset, answer it and sync the answer into the same file, preferably by prepending a dated 问题补充更新 block near the top.
6. If the user asks for a direct comparison between already covered assets, answer the comparison and sync the conclusion into each relevant report near the top instead of leaving it only in chat.
7. Read report-rubric.md and follow the section order exactly for first coverage unless the user requests a different structure.
8. Read source-priority.md before gathering evidence if the request depends on latest information, X discussion, roadmap, or price outlook. That is the normal case for this skill.
9. If the asset is a stock or listed company, verify investor-relations pages, earnings releases, SEC or exchange filings, shareholder letters, earnings transcripts, and consensus or valuation data first. Read stock-framework.md before drafting.
10. If tokenomics matter, verify vesting and unlock information from official tokenomics pages, governance posts, treasury disclosures, or vesting contracts first; use reputable unlock dashboards only as secondary fallback.
11. If the request is chain-centric or the asset is an L1/L2/network, verify node and validator data from official validator pages, explorers, staking dashboards, telemetry sites, or reputable infrastructure trackers. Distinguish validators from full nodes, RPC nodes, or other node classes.
12. If the request is chain-centric or the asset is an L1/L2/network, verify the 节点所需配置 from official validator or operator setup docs. Prefer current recommended CPU, RAM, disk, and bandwidth guidance over old community blog posts.
13. If the request is chain-centric or the asset is an L1/L2/network, verify the 当前账本 / 历史数据体积 from official setup docs, validator guides, or primary telemetry if available. Clarify whether the number refers to pruned ledger storage, snapshots plus state, or full archival history.
14. If the request is chain-centric or the asset is an L1/L2/network, verify whether the chain has 主链原生质押, who can participate, the staking ratio when available, the validator commission model, and the best available yield labels such as 名义收益率 / 验证者毛收益率 / 委托人净收益率. Distinguish native mainnet staking from LST / restaking / CeFi earn products.
15. If the request is chain-centric or the asset is an L1/L2/network, verify the 创始人 / 核心团队 / 当前领导格局 from official team, foundation, company, or investor materials before characterizing execution quality or governance stability.
16. If the request is chain-centric or the asset is an L1/L2/network, verify the chain’s 语言 / VM / 执行模型 / 共识路径 / 状态模型 from primary docs or research pages, especially when the user asks about architecture, performance, or close-peer comparisons.
17. If the user asks whether a chain is compatible with Ethereum or EVM, verify from official docs or protocol pages whether the chain runs EVM bytecode natively, whether Solidity contracts can be reused, and what the migration path actually is.
18. Read sector-frameworks.md to choose the primary sector and adjust the report emphasis.
19. If the request is chain-centric or the asset is an L1/L2/network, read chain-analysis.md and make sure chain outlook and token capture are separated.
20. If the user asks about the best AI combination path for a chain, read chain-ai-fit.md and rank the most suitable AI directions before drafting.
21. Read comparables.md and select the most relevant same-sector peers before writing the report.
22. Read depth-framework.md before drafting the main body so the report answers strong bull, strong bear, priced-in assumptions, market blind spots, and falsification points.
23. Read report-quality.md before finalizing the report.
24. Use one asset per report. If the prompt includes multiple assets, create or update one document per asset.
25. Replace every placeholder in each generated markdown template when you are creating a new report.

Output Standard

• Save reports as markdown in the active workspace, normally under reports/.
• Default to one coin per file.
• If the asset already has a report, default to updating that existing file in place instead of creating a new full report.
• In this repeat-coverage mode, prepend a short dated 最新生态大事件更新 block near the top of the report and keep the rest of the report intact unless the user asks for a full rewrite.
• If the user asks a question about an asset with an existing report, default to syncing the answer into that same report as well, usually via a short dated 问题补充更新 block near the top.
• If the user asks a comparison question across already covered assets, default to syncing a concise dated comparison update into each involved report as well.
• Do not show inline 来源：... lines in the body, and do not display a final 参考资料 / Sources section by default.
• Use a Chinese title such as # BTC / Bitcoin 深度分析报告.
• Include a Chinese 执行摘要 before the numbered sections.
• 执行摘要 should be visually easy to scan: split it into 2-3 short paragraphs instead of one long block.
• Add a visible 解锁与供给压力快照 section near the top. State the most recent material unlock, the next known unlock, the next 30/90/365 day unlock pressure when data exists, who receives the tokens, and whether the unlock should matter for market structure. If the token is largely fully circulating or no reliable unlock data exists, say so explicitly.
• Add a visible 节点与验证者概况 section near the top. State the total node count and/or validator count, clarify what kind of nodes the count refers to, describe the most relevant concentration or distribution facts, and explain why that matters for decentralization, liveness, or censorship resistance. If the metric is not applicable or no reliable data exists, say so explicitly.
• For chain or network assets, make 节点与验证者概况 explicitly cover 节点个数、节点所需配置、当前账本 / 历史数据体积，并区分 修剪节点 / 常规验证者 / RPC / 归档节点 的不同磁盘需求。
• For chain or network assets, make 关键指标快照 explicitly cover developer count when reliable data exists, and use a clear label such as 月活开发者 or 全职开发者.
• For chain or network assets, make 关键指标快照 explicitly cover 主链原生质押收益率情况 when native staking exists and reliable data is available, and clearly distinguish 名义收益率 / 验证者毛收益率 / 委托人净收益率 when those differ materially. Also state whether ordinary holders can access the native yield directly or mainly through delegation.
• For chain or network assets, make 最近生态进展 explicitly cover named enterprise partnerships or large-company adoption, and also include material financing or treasury events when they matter.
• Add a visible 股票信息与核心指标 section near the top for stock requests. Include ticker and exchange, core business description, market cap, enterprise value, revenue and growth, gross margin, operating margin, EPS, free cash flow, net cash or debt, diluted share count, valuation multiples such as P/E, EV/Sales, EV/EBITDA, and any material SBC / buyback / ATM / convertibles context.
• State the chosen 主赛道 clearly near the top of the report and let it influence which metrics and comparisons are emphasized.
• Include explicit depth sections near the top of the report: 核心投资逻辑, 反方观点与证伪条件, and 市场可能忽略的变量.
• Include a visible 历史大事件与影响意义 section near the top-middle of the report. For each event, explain what happened, why it mattered at the time, what changed afterward, and whether that effect still shapes the current thesis.
• Include a 对标项目比较 section that compares the asset with the closest same-sector chains or projects whenever reasonable peers exist.
• For chain or network assets, make 对标项目比较 do real work. Compare close peers on 创始人与团队、技术架构、执行与稳定性、生态方向、价值捕获、估值或市场心智, not just TVL or TPS snapshots.
• If the request is about a chain's future prospects, make the chain-level outlook the primary narrative and treat token capture as a separate judgment instead of assuming chain success automatically means token upside.
• If the request is about a chain and AI, identify the 最佳结合方向, 为什么适合这条链, 落地路径, 商业化与价值捕获, and 哪些 AI 方向看起来热闹但其实不适合.
• Cover the core numbered dimensions, and also include 解锁与供给压力快照 plus 节点与验证者概况 near the top when applicable: Recent ecosystem progress, Recent X discussion, Tokenomics, Outlook, Value capture, next-12-month catalysts, next-12-month price forecast, AI-related analysis, Latest roadmap, Ecosystem project introduction with links, Block explorer address, and Smart contract development language when it is materially relevant.
• If the asset is a stock, add 股票信息与核心指标 near the top, translate token-centric discussion into share count, dilution, buybacks, and capital structure where relevant, and omit crypto-only fields such as smart contract language when they are not materially relevant.
• Add a short Key Risks section near the end of the report.
• Make the 未来 12 个月价格走势预测 scenario-based with bear / base / bull ranges and the assumptions behind each range.
• When AI relevance is weak, say so plainly and explain whether the connection is product-level, infrastructure-level, narrative-level, or negligible.
• Go beyond news summarization. Explain why each development matters for adoption, token demand, margins, market structure, or narrative durability.
• For depth, force yourself to cover both bull and bear logic, what is already priced in, what the market may be missing, and what data would falsify the thesis.
• On repeat coverage of the same asset, default to a top-of-file incremental update.
• If the trigger is a repeated bare asset name, add the newest major ecosystem events first and explain why they matter.
• If the trigger is a follow-up question, add the answer and its implications to the report as well, instead of leaving it only in chat.
• In 1. 最近生态进展, do not stop at ecosystem headlines. For technical assets, explicitly cover the latest technical progress and explain why it matters for adoption, performance, security, developer experience, or token value capture.
• When the user asks about a chain’s founders or team, explain 谁是一号位、创始人当前角色是否变化、核心技术班底来自哪里、这种组织结构对执行意味着什么 instead of only listing names.
• When the user asks about compatibility or developer migration, explain 是否兼容 EVM in layers: execution layer, contract language, bytecode compatibility, developer migration cost, and cross-chain asset/user onboarding.
• In 1. 最近生态进展, present developments in 时间倒序, not mixed chronology.
• Use the chosen sector to decide what deserves the most space. For example, L1/L2 reports should emphasize developers, users, fees, and ecosystem stickiness, while DeFi reports should emphasize revenue, TVL quality, and token capture.
• Compare with the nearest chains or same-category projects, not arbitrary large-cap names. Explain relative strengths, weaknesses, and whether valuation looks rich or cheap versus peers.
• In the explorer section, provide exactly one main official or most commonly used link. For crypto, use one primary explorer URL. For stocks, use one primary investor-relations URL.
• Include the smart contract language section only when the language, VM, or developer stack is materially relevant to the asset. If it would only say 不适用, omit the entire section.

Reusable Resources

scripts/init_coin_report.py

Create a dated markdown report from the bundled template. Use it whenever you are starting a new report file.

references/report-rubric.md

Use this rubric to keep the report structure consistent and sufficiently deep.

references/source-priority.md

Use this to decide what sources to trust and how to write scenario analysis without overstating confidence.

references/sector-frameworks.md

Use this to classify the asset's main sector and choose the right evaluation framework and metrics.

references/chain-analysis.md

Use this when the request is chain-centric or the asset is primarily a blockchain network. Separate chain growth from token capture.

references/chain-ai-fit.md

Use this when the user asks how a chain should best combine with AI. Rank the best-fit AI directions and explain why they do or do not fit the chain.

references/stock-framework.md

Use this when the asset is a stock or listed company. It explains which equity metrics matter and how to map the report structure away from token-native language.

references/comparables.md

Use this to choose the right peer set and compare against similar chains or same-category projects.

references/depth-framework.md

Use this to make the report genuinely deep: strong bull case, strong bear case, priced-in assumptions, market blind spots, and falsification points.

references/report-quality.md

Use this as the final quality gate so the report has enough source diversity, freshness, and analytical depth.

assets/report-template.md

This is the report scaffold used by init_coin_report.py. Update it only when the report format should change for every future run.

Final Checklist

• The file is saved in the workspace.
• Each requested coin has its own standalone document unless the user explicitly asked for a comparison report.
• The document is written in Simplified Chinese unless the user explicitly asked for another language.
• All core numbered sections are present and non-empty, and 智能合约开发用什么语言 is included only when materially relevant.
• The report explicitly states a 主赛道, and the chosen metrics/comparables match that sector.
• The report includes 对标项目比较 and the peer set is genuinely comparable.
• If the request is chain-centric, the report clearly separates 链的发展前景 from 代币价值捕获.
• If the request is chain-centric and founder or team quality is material, the report explicitly includes 创始人、团队与当前领导格局 analysis.
• If the request is chain-centric, the report explicitly includes developer-count information when reliable data exists, and clearly states when no reliable unified developer-count source exists.
• If the request is chain-centric, the report explicitly includes major-company partnerships or enterprise adoption when such relationships are material to the thesis.
• If the request is chain-centric, the report explicitly includes financing information when recent fundraising, ecosystem funds, treasury deployments, or strategic capital events matter.
• If the request is chain-centric and architecture is material to the user’s question, the report explicitly includes 语言 / VM / 执行模型 / 共识路径 / EVM 兼容性或迁移成本 analysis.
• If the request is about chain + AI fit, the report clearly ranks AI integration paths by fit and explains why the top path is better than the alternatives.
• The metadata lines correctly state whether the report is 首次覆盖 or 更新版, and reference the previous report when one exists.
• If the asset has a prior report, the default behavior is to update that existing file in place rather than generate a full rewritten report.
• If the user asks a follow-up question about that asset, the answer should also be synced into the report, usually as a 问题补充更新 block near the top.
• If the user asks a comparison question across already covered assets, the comparison conclusion should also be synced into each relevant report near the top.
• The report includes 关键指标快照 and 未证实但值得跟踪的问题.
• The report includes 生态项目介绍（含链接）, and the chosen projects are representative rather than filler.
• For chain or network assets, the report includes 主链原生质押收益信息, either in 关键指标快照 plus the tokenomics/value-capture discussion, or an explicit explanation of why native staking yield is not applicable, not open to ordinary holders, or not reliably disclosed.
• The report includes 解锁与供给压力快照, or explicitly states why unlock analysis is not applicable.
• The unlock analysis states whether the token is still in heavy unlock phase, already in tail-overhang phase, or close to a known end date that could change the medium-term thesis.
• The report includes 节点与验证者概况, or explicitly states why node analysis is not applicable or unavailable.
• For chain or network assets, the node section includes 节点个数、节点所需配置、当前账本 / 历史数据体积，并说明这些数字是修剪口径还是归档口径。
• If the asset is a stock, the report includes 股票信息与核心指标 and uses actual equity metrics instead of generic crypto placeholders.
• If the asset is a stock, the report explicitly includes 营收、盈利、增长率、市盈率、市值.
• If the asset is a stock, the report includes 同赛道对比 with close operating peers instead of generic mega-cap names.
• If the asset is a stock, the report includes 市场需求分析 and a clear 未来 12 个月业务与估值预测.
• The report includes 核心投资逻辑, 反方观点与证伪条件, and 市场可能忽略的变量.
• The report includes 历史大事件与影响意义, and each event includes both the impact at that time and the longer-term significance.
• The X discussion section reflects recent discourse rather than generic sentiment.
• The roadmap and next-12-month catalyst sections contain concrete dates or windows when available.
• The price forecast is clearly scenario-based and not framed as certainty.
• The analysis explains second-order effects, not just headline events.
• The explorer section includes a usable URL.
• If the smart contract section is included, it states the exact language, VM, or developer stack.