An A-share research skill that separates the live feed from the record
面向 AI Agent 的可溯源 A 股板块研究 Skill,贯通政策、权威媒体、市场资金、公司与 ETF,支持实时查询、研究编排和二次应用开发。
At a glance
- What is it?
- This Apache-licensed Agent Skill wraps Chinese sector research data, splitting five-minute real-time material from reproducible daily snapshots and keeping source, date and evidence on every judgement. Its stated scope limits and consent-gated update protocol are the parts worth copying.
- Who is it for?
- This skill suits a Chinese-reading analyst who wants an assistant that can answer sector questions with a source and a date attached, and whose daily snapshots make an answer from last Tuesday still checkable today. It is the wrong tool for anyone wanting individual holdings named or entry points suggested, because the README states plainly that conclusions land on the sector and that companies and ETFs appear only as mapping evidence.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 52 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Two clocks running at once
This is an Agent Skill that packages a body of Chinese A-share sector research data so an assistant can query it, combine it and build on it. The subjects are policy documents, authoritative media coverage, market attention, capital confirmation, and the mappings that connect sectors to listed companies and exchange-traded funds.
The design decision that stands out sits in the first capability table. The README separates real-time discovery, described as material surfacing on a five-minute cadence, from stable research, described as daily published snapshots that can be reproduced. Those are two different clocks, and keeping them apart is the part worth studying.
Anyone who has built a research workflow over a live feed knows why. A question asked at half past nine and the same question asked at four in the afternoon return different answers, both correct, and neither one citable a week later. A daily snapshot is dull by comparison and is the only thing you can point at when someone asks what the position was on a given date.
The README states the same requirement for individual judgements: each one retains its source, its date, a stable identifier and a chain of evidence. That is the difference between a data feed and a research record.
A stated scope, and the discipline of refusing questions
Most projects in this area advertise what they can answer. This one publishes a section on where its conclusions stop, and the section is unusually specific.
Conclusions always land on the sector. Companies and ETFs appear only as mapping, exposure or confirmation evidence, never as the answer. Policy signals, media signals, market attention and capital movement are each explained separately, and the README states that contemporaneous performance is not written up as established causation. There are no individual stock or ETF recommendations, no entry and exit points, and no return forecasts. The text goes on to say that users who take the content apart and apply it to investment decisions bear the resulting risk themselves, and that the project offers no guarantee of any kind.
Read as engineering rather than as a legal notice, that is a specification of what the tool will refuse. A system that separates four signal types rather than blending them into one score is harder to build and much harder to sell, because a single number is what people ask for. It is also the only version that lets a reader disagree with one input while accepting another.
The narrowness is also what makes the evidence chain meaningful. Tracking provenance for a sector-level claim is tractable; tracking it for a recommendation to buy something is not.
Installing it, and what the verification commands tell you
The README offers two routes. The first is to ask the agent in plain language to install the repository URL, letting it use its own native skill mechanism to decide the directory and registration. The second is a manual clone.
After installation, three commands run from the skill directory:
python3 scripts/gendangzou.py apps doctor
python3 scripts/gendangzou.py apps list --format agent
python3 scripts/gendangzou.py api bootstrap --forceThe README says the first should report a true status, and that the public API is used by default. If the server returns an authentication-required response, a token must be obtained from the project's application page and configured through a separate authentication command.
That detail deserves attention before installing anything. The skill is a client. The policy, media, attention and capital data lives behind a hosted service, and the open-source component here is the packaging, the orchestration and the application layer rather than the underlying dataset. The default path is public access, with authentication appearing as a server-side condition rather than a prerequisite, which is a reasonable arrangement provided you understand which half you have a copy of.
Requirements are modest: Python 3.10 or later and HTTPS access to GitHub and the service host. The README states that core queries use only the Python standard library, with no third-party packages to install in advance. Image generation for the daily report application is the one exception, needing a browser automation stack at the point of use.
An update protocol that refuses to act on its own
The update mechanism is described in more detail than most projects give it, and every detail points the same way.
On the first call each day, the skill checks the repository's stable tags directly on GitHub, caching the check date, the ETag, the tag and the commit hash locally. The README is explicit that this check does not pass through the service API, and that it downloads nothing and overwrites nothing. An explicit check is available:
python3 scripts/gendangzou.py update check --forceOnly after the user agrees can the agent fetch the source archive by commit hash and update through its own native mechanism. If there is no stable tag, if GitHub is unavailable, or if queries are rate limited, the README says existing functionality is unaffected.
The tag rules in the manual installation notes are equally strict. Only tags matching a strict version pattern count. Installation resolves the tag to a full commit hash first, then downloads that commit. The version file in the installed copy must match the tag, and the whole directory structure has to be kept rather than copying the skill description alone.
git clone --depth 1 \
--branch vX.Y.Z \
https://github.com/MobiusQuant/Gendangzou-skill.git \
gendangzou-skillMost pointedly, when the repository has no stable tag, the README says this counts as having no published stable version, and that the main branch is not substituted automatically. A project that declines to let agents install its own default branch is making a statement about what it considers releasable.
Layers, applications, and the direction dependencies point
The internal structure is three layers with a dependency direction the README draws explicitly: applications depend on the API SDK, which depends on the platform core, and nothing points back.
The platform core handles authorisation, request state, caching, updates and the application registry. The SDK is described as read-only transport with capability contracts and shared query rules. Applications sit on top, each one independent of the others.
Read-only transport at the middle layer is the choice to note. A research client that cannot write has a much smaller surface to reason about, and it means the entire question of what the tool might change reduces to what the agent does with the answers.
Seven applications ship in their own directories, each installable, updatable and removable separately, with the agent loading only the description matching the current task: a real-time radar, a daily sector report rendered as an image, a weekly report, a sector movement explainer, a company mapping audit, an ETF sector exposure query, and a reader for a national evening news programme that maps its segments into sectors.
The repository tree matches the description, carrying separate directories for the platform core, the SDK, the applications, the scripts, the agent definitions, tests and tools. Source-level development has its own commands for validation, tests and building a release, which the README is careful to distinguish from the post-installation checks.
What to check before adopting it
The documentation is written entirely in Chinese, including the application descriptions an agent reads at runtime and the API reference the project links. For the subject matter that is a defensible choice, since the sources being tracked are Chinese-language policy documents and media, but it does set who can use this.
The repository carries no published releases, while the installation protocol keys on Git tags rather than releases. Those are different things on GitHub, so their absence does not by itself mean no stable tag exists, but it does mean a reader cannot confirm the current version from release metadata and has to run the check command to find out. Against a protocol this strict about versions, that is an odd gap.
The feedback section points contributors at an issue tracker belonging to a different repository under the same organisation, so a report filed in the obvious place may not land where its author expects. The repository shows no forks and no open issues at a little over three hundred stars, and the last push was on 2026-07-28.
The licence is Apache 2.0, which covers the code and the packaging. What it does not cover is the hosted data the skill queries, and the terms attached to that service are a separate question the repository does not answer. This is not legal advice.
For anyone evaluating it, the order of checks is straightforward. Run the doctor command and see whether the public API answers without a token. Read the research boundary section and decide whether a tool that refuses to name individual holdings is the tool you wanted. Then confirm which stable tag exists before letting an agent install anything, because the project's own protocol says that absent one, there is nothing stable to install.
Editorial conclusion
This skill suits a Chinese-reading analyst who wants an assistant that can answer sector questions with a source and a date attached, and whose daily snapshots make an answer from last Tuesday still checkable today. It is the wrong tool for anyone wanting individual holdings named or entry points suggested, because the README states plainly that conclusions land on the sector and that companies and ETFs appear only as mapping evidence. Run the doctor command first to see whether the public API answers without a token, since the dataset lives behind a hosted service and the Apache licence covers the client rather than the data, and confirm which stable tag exists before installing, because the project's own protocol treats the absence of one as nothing stable to install.
Frequently asked questions
What data does this skill provide?
Chinese A-share sector research across five capability layers: real-time policy, media and market attention material; daily reproducible snapshots with capital confirmation and sector movement; company and ETF mapping audits; seven packaged report applications; and an API SDK for building on top.
Does it recommend stocks or ETFs?
No. The README states a research boundary in which conclusions always land on the sector, companies and ETFs serve only as mapping, exposure or confirmation evidence, and the project provides no individual recommendations, no entry or exit points and no return forecasts.
Do I need an API token?
Not necessarily. The README says the public API is used by default, and a token from the project's application page is needed only when the server returns an authentication-required response, after which it is configured through a separate authentication command.
How does it handle updates?
On the first call each day it checks the repository's stable tags on GitHub, caching the date, ETag, tag and commit hash locally without downloading or overwriting anything. Fetching an update requires explicit user agreement, and the main branch is never substituted when no stable tag exists.
What are the requirements?
Python 3.10 or later and HTTPS access to GitHub and the service host. The README states core queries use only the Python standard library with no third-party packages needed in advance, apart from the daily report image application, which needs a browser automation stack when used.
Community notes