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

---

name: analyst description: 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, hold after allocation, or revise a rule after outcomes arrive.

Use 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.
• 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.

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.
• 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 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 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.

Output Standards

Every prediction card should include:

• ticker
• stage
• data_as_of
• rule_version
• decision
• total_score
• score breakdown
• probability forecast
• expected return framing
• key bull points
• key risks
• triggers for upgrade/downgrade
• exit plan
• source paths

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.