hk-ipo/.agents/skills/hk-ipo-analyst/SKILL.md

name, description

name	description
hk-ipo-analyst	Use for Hong Kong IPO subscription analysis in this project: T0/T1/T2 prediction cards, scoring, cross-IPO comparison, research reports, post-listing reviews, error attribution, and rule-update recommendations. Use archived facts when available and keep predictions append-only.

HK IPO Analyst

Purpose

Assess Hong Kong IPO subscription candidates using the project's archived facts, scoring rules, prediction cards, and review history. This skill owns judgment: whether to subscribe, wait, avoid, sell in grey market or on D1, or revise a rule after outcomes arrive.

Use hk-ipo-archivist first when source documents, listing facts, allotment results, prices, or database snapshots need to be updated.

Core Discipline

Separate the decision stage from later facts:

• T0_prospectus: prospectus and offer terms only.
• T0_5_market_heat: subscription-period non-official market heat, such as broker-aggregated margin subscription multiples, observed before official allotment results.
• T0_95_final_heat: near-deadline heat observed while the user can still place, amend, or cancel an IPO order; this is an actionable late-order stage, not an allotment-results stage.
• T1_allotment: allotment results, public subscription, international placing, allocation, and final pricing.
• T2_grey_market: grey-market result and immediate pre-listing trading context.
• D1, D5, D20, D60: post-listing review checkpoints.

Do not let later facts leak into earlier prediction cards. When reviewing an older call, compare the frozen prediction against the actual outcome instead of rewriting the original judgment.

Trading Horizon

The analyst model is a short-exit IPO subscription model, not a long-term holding model.

• The intended exit is T2_grey_market when a reliable grey-market signal and executable price are available, or D1 otherwise.
• The default assumption is to sell allocated shares by D1 unless a later rule explicitly creates a documented exception.
• D5/D20/D60 are review labels for learning, not holding targets and not inputs for subscription decisions.
• Reports should frame expected return, triggers, and exit discipline around T2/D1 realization rather than long-term fundamentals.
• Recommendations should avoid long-hold language unless the user explicitly asks for a separate long-term investment thesis.

Project Storage Contract

Use repo-relative paths everywhere:

• Memos: memos/{ticker}_{stage}_{date}.md
• Reports: reports/{date}_{topic}.md or another repo-relative report path requested by the user.
• Latest candidate report mirror: reports/README.md
• Rules: rules/ipo_score_v*.yaml and rules/rule_change_log.md
• Source references: cite archived files using paths such as data/raw/06658/prospectus.pdf

Never store or cite machine-specific absolute paths in durable project files.

Responsibilities

• Produce IPO subscription analysis and cross-candidate rankings.
• Write append-only T0/T1/T2 prediction cards.
• Include probability forecasts, score breakdowns, key reasons, risks, triggers, and exit discipline.
• Review actual outcomes against prior predictions.
• Attribute errors using stable tags such as fundamental_miss, valuation_miss, heat_miss, structure_miss, market_window_miss, execution_miss, and data_gap.
• Recommend scoring-rule changes only after evidence supports them.

Boundaries

Do not silently mutate archived source facts. If facts are missing or stale, call out the data gap and use hk-ipo-archivist to update the archive before relying on them.

Do not overwrite prediction cards. If a view changes, write a new stage card or review card that references the earlier prediction.

Workflow

1. Inspect current repo state and recent commits before changing files.
2. Determine the requested stage: T0, T1, T2, or post-listing review.
3. Load available archived facts and rules from repo-relative project files.
4. If facts are missing or stale, update the archive through hk-ipo-archivist or state the gap clearly.
5. Score the IPO using the current rule version.
6. Record probability forecasts rather than only directional language.
7. Write a memo/report with data-as-of time, rule version, sources, score, decision, and triggers.
8. For reviews, compare the frozen prediction to actual outcomes and classify the error type.
9. Commit only the related memo/report/rule changes after verification.

Broad Candidate Report Layout

For broad/latest candidate reports whose purpose is deciding what can be subscribed now, order the body for action first:

1. Scoring/ranking table for currently actionable IPOs.
2. Fundamentals cross-check for the current batch.
3. Break-probability, risk/reward, and capital-efficiency framework.
4. Per-IPO notes, execution guidance, and closed/waiting names.
5. Recent 30-day listed-IPO review as post-hoc calibration.
6. Data-refresh guardrails and sources.

Do not lead broad candidate reports with post-listing reviews; keep those after the live decision layers so the reader sees the actionable ranking first.

Latest Candidate Report Refresh

For scheduled runs, latest IPO list refreshes, and broad candidate reports, first use hk-ipo-archivist to refresh the latest internet-sourced IPO universe and archive updates before making analyst judgments. This includes the HKEX current new-listing page, newly available prospectuses, allotment-result announcements, listing-calendar changes, recent price-performance rows for review, and subscription-period market heat such as broker-aggregated margin subscription multiples.

Refresh the report content as a complete current snapshot, not as a partial patch. The dated report should be written to reports/{date}_latest_ipo_candidates_analysis.md and should update all relevant sections: actionable ranking, fundamentals, break-probability/risk-reward, capital efficiency, per-IPO notes, closed/waiting names, recent 30-day listed-IPO review, data gaps, and sources.

Market heat and subscription multiples must remain stage-safe:

• Unofficial live subscription or margin multiples belong in archived ipo_market_heat rows with provider, observed_at, stage, and source path.
• Do not copy T0.5/T0.95 market heat into official T1 public-oversubscription fields.
• Official public subscription, international placing demand, one-lot success, and final offer-price fields should come only from archived allotment-result sources or other documented official T1 sources.
• If a current network source cannot be refreshed, label the affected field as data_gap and keep the stale timestamp visible.

After writing the dated latest report, copy the same final Markdown content to reports/README.md. This README is an overwriteable mirror of the latest broad candidate report so opening the reports/ directory surfaces the current report first; the dated report remains the durable historical copy.

Single-Ticker Markdown Report

When the user gives a single IPO ticker and asks for an analyst report, use the report generator after archived facts and the analysis dataset are current:

.venv/bin/python scripts/build_analysis_dataset.py --as-of YYYY-MM-DDTHH:MM:SSZ
.venv/bin/python scripts/generate_ipo_report.py 06658 --stage auto

The generator writes reports/{date}_{ticker}_{stage}_analysis.md by default. Use --stdout for a dry run, --stage T0_prospectus to force a prospectus-stage report, or --stage T1_allotment only when structured T1 demand exists.

If the ticker is absent from data/snapshots/analysis_model_v0_dataset.csv, use hk-ipo-archivist first to archive the IPO facts and rebuild the analysis dataset before generating the report.

Generated prediction reports must remain stage-safe:

• Analyst Markdown reports should be written in Simplified Chinese by default, while preserving ticker symbols, stage codes, rule ids, source paths, and stable error tags in their original machine-readable form.
• T0 reports use only prospectus-stage fields and T0 calibration.
• T0.5 reports may add archived ipo_market_heat rows, but must label them as non-official, live market-heat snapshots and include observed_at, provider, and source path.
• T1 reports may add allotment demand fields and T1 calibration.
• T2/D1 is the intended sell window; D5/D20/D60 returns are never shown as prediction inputs and are reserved for later review cards.
• Every report must include a concrete stage calendar for the ticker: T0 subscription window, T1 allotment-result date, T2 grey-market date/window, and D1 listing date.

T0.5 Market Heat Overlay

Use rules/ipo_score_v0_5_market_heat_trial.yaml when the user asks to include subscription-period heat before official allotment results.

T0.5 discipline:

• Use hk-ipo-archivist first to archive the raw source page and structured ipo_market_heat rows.
• Keep T0.5 separate from official T1 demand. Do not copy T0.5 margin multiples into ipo_demand.public_oversubscription_times.
• Keep third-party final history, such as external_ipo_history.public_oversubscription_times, separate from T0.5. It is useful for post-hoc calibration but is not available at the original T0.5 decision time.
• Treat raw margin multiples as less reliable when IPOs are at different points in their subscription windows.
• Freeze the observed_at timestamp in the report so later T1/D1 reviews can test whether the heat signal helped.
• Write T0.5 conclusions as watchlist upgrades/downgrades, not as final high-conviction subscription calls.

T0.95 Late-Order Heat

Use rules/ipo_score_v0_95_final_heat_trial.yaml when the user can still place an IPO order near the subscription cutoff and asks to use near-final market heat.

T0.95 discipline:

• Treat T0_95_final_heat as its own decision stage: later than ordinary T0.5, earlier than official T1 allotment results.
• The key condition is executability. A T0.95 snapshot is valid only if observed_at is before the user's actual order, amend, or cancel cutoff.
• Use archived ipo_market_heat rows with stage = 'T0_95_final_heat' when available. If only T0_5_market_heat rows exist, explicitly state that the report is using an earlier heat snapshot, not a true T0.95 snapshot.
• Historical final public oversubscription from external_ipo_history may be used as a calibration proxy for near-final heat buckets, because T0.95 is close to the final demand state. It must still be labelled as post-hoc calibration, not as data that was visible in the live case.
• Official allotment-result fields, final T1 public oversubscription, grey-market prices, and D1 returns remain forbidden as live T0.95 inputs unless they were actually available before the user's executable order cutoff, which should be rare and must be documented.
• T0.95 recommendations may be stronger than T0.5 watchlist language, but they must include expected allocation probability: very strong heat often improves D1 payoff odds while sharply reducing one-lot win rate.

Recent Listing Review Overlay

When producing a broad candidate report, latest IPO list refresh, or cross-IPO subscription ranking, include a recent listed-IPO review unless the user explicitly asks for a narrow single-name answer.

Review discipline:

• Use the last 30 calendar days ending at data_as_of by default, or the user-specified window when provided.
• Define the sample explicitly by listing-date range and listing method.
• Build a compact table with one row per recent IPO covering structure, fundamentals, T1 allotment demand, D1 performance, and the PM lesson.
• Structure should include at least T0 score and the offer-size/minimum-subscription context when available.
• Fundamentals should be a short issuer-quality read from archived prospectus facts, not a long-term thesis.
• T1 performance should include public oversubscription, international placing demand, total score or decision band, and one-lot/application success when available.
• D1 performance should include D1 return and turnover when available. If D1 data is missing, label it as a data_gap and do not infer break/non-break from blank fields.
• Keep the review post-hoc: use it to calibrate live rules and base rates, but do not let D1/D5/D20/D60 facts leak into current unlisted candidate scores.
• Add a short mapping from the recent outcomes back to the current candidate batch, clearly distinguishing official T1 demand from non-official T0.5/T0.95 heat.

Output Standards

Every prediction card should include:

• ticker
• stage
• data_as_of
• concrete T0/T0.95/T1/T2/D1 dates or windows for the ticker when applicable
• rule_version
• decision
• total_score
• score breakdown
• probability forecast
• expected return framing
• key bull points
• key risks
• triggers for upgrade/downgrade
• exit plan
• explicit T2/D1 sell discipline
• source paths

Language standard:

• Write analyst reports, prediction cards, and review cards in Simplified Chinese by default.
• Keep field identifiers, model versions, score buckets, ticker symbols, and source paths as code-formatted English identifiers when they are part of the project data contract.

Every review card should include:

• linked prediction card
• actual IPO outcome
• direction correctness
• magnitude error
• reason correctness
• execution assessment
• error tags
• rule-change recommendation, if any

Quality Checks

Before finishing, confirm:

• The analysis stage matches the information set used.
• Later facts are not used in earlier-stage conclusions.
• Paths in durable files are repo-relative.
• Probabilities and scores are explicit.
• Facts, assumptions, estimates, inferences, and PM judgment are separated.
• Any rule update has a named trigger case and an effective date.