investor-update
Generate structured monthly stakeholder update from current research state, metrics, roadmap, and feedback
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- investor-update
- type
- analysis
- version
- v0.4
- description
- Generate structured monthly stakeholder update from current research state, metrics, roadmap, and feedback
- visual_tier
- visual
- argument-hint
- [optional: month e.g. "March 2026"]
- context_intake
- artifact_only
- required_conventions
- [ "alignment-page" ]
02 资源文件 2
- 参考文档ALIGNMENT-PAGE.md52.8 KB
- 参考文档CHANGELOG.md1.1 KB
03 SKILL.md 正文
Pack Availability Guard
When recommending a skill from another pack, verify the target pack is installed via .agents/project.json enabled_packs. If it is not enabled, recommend npx skillpacks install <pack> from the project shell. After install, tell Codex users to start a fresh Codex CLI session if the $ skill list remains stale. Only the currently running skill and skills verified available in the active session or project-local install state are directly recommendable. For unavailable pack skills, recommend npx skillpacks install <pack-or-skill>; for unavailable base skills, recommend npx skillpacks init before the skill.
Investor Update — Stakeholder Communication
Invoke as $investor-update.
Generates a structured monthly update from current research state, metrics, roadmap progress, and customer feedback. Uses standard YC/First Round format suitable for investors, accelerator mentors, or advisory boards.
Soft Prerequisites
- Read all that exist:
research/metrics.md,research/cohort-review-*.md,research/runway-model.md,research/customer-feedback.md,research/gtm.md,tasks/roadmap.md,tasks/todo.md,tasks/manual-todo.md,tasks/record-todo.md,tasks/recurring-todo.md,tasks/history.md - The more data exists, the richer the update. Works with as little as a roadmap + basic metrics.
Process
0. Product-Path Scope Resolution
Resolve research scope by product path before using code or app structure as a hint:
- If
$ARGUMENTSnames a non-archivedresearch/{slug}/directory or a product-path ID whosescope_pathpoints there, use that path. Treat{slug}as the product/app name, not the ICP, audience, or segment label. - If
$ARGUMENTSnames onlyresearch/_archive/{slug}/or a manifest entry withstatus: archivedor legacystatus: abandoned, stop and warn that the path is archived; do not write or update scoped outputs there. - Read
research/.progress.yamlwhen present. Normalize legacyactive_pathtoactive_pathson read and write backactive_pathson manifest updates. Treat legacyabandonedasarchived; excludearchived,abandoned,deferred,revisit_candidate,promoted, and anyscope_pathunderresearch/_archive/from active target selection. - If active product paths exist in the manifest, use those paths. If multiple active paths exist, ask which one to target unless this skill explicitly supports cross-path output.
- If no active manifest target exists, list non-archived product directories under
research/, excludingresearch/_archive/and dot directories. Auto-select only when exactly one exists; ask when multiple exist. - If no product directories exist, use flat
research/single-product mode. - Detect monorepo/app/package structure only as a secondary hint. Suggest creating a missing
research/{slug}/product path when code clearly exposes an app, but do not require code or monorepo detection before usingresearch/{slug}/.
When product path {slug} is active, read and write research under research/{slug}/, specs under specs/{slug}/, and treat top-level research/*.md files as flat-mode documents or cross-path summaries.
1. Load Context
Read all available data sources:
- Metrics:
research/metrics.mdfor targets,research/cohort-review-*.md(most recent) for actuals - Financial:
research/runway-model.mdfor runway, burn, revenue - Customer:
research/customer-feedback.mdfor qualitative signal - Progress:
tasks/roadmap.md,tasks/todo.md,tasks/manual-todo.md(if it exists),tasks/history.mdfor what was built;tasks/record-todo.mdandtasks/recurring-todo.mdfor advisory measurements or cadence work that may affect asks/risks - GTM:
research/gtm.mdfor go-to-market context
Also check git log for the month to see what was shipped.
2. Compile Update Sections
For each section, pull from the appropriate data source. If a data source doesn't exist, either skip the section or ask the user for the data. If the session is already in Plan mode and there are 2-3 concrete choices, prefer request_user_input.
Fill gaps with user input. If the session is already in Plan mode and there are 2-3 concrete choices, prefer request_user_input; otherwise ask in plain text:
- "What were the top 3 accomplishments this month?"
- "What's the #1 thing you need help with?"
- "Any key hires, partnerships, or milestones?"
- "What are you most worried about right now?"
3. Present & Validate
Show the complete update to the user before writing:
- "Here's the draft update. Does it accurately represent the month? Anything to add or change?"
Incorporate feedback before proceeding.
4. Write Output
Only after confirmation, write the output file.
Output
research/investor-update-[YYYY-MM].md (or research/{slug}/investor-update-[YYYY-MM].md)
# Investor Update: [Month Year]
> Date: [current date]
> From: [product/company name]
## TL;DR
[2-3 sentences: the month in a nutshell — wins, challenges, and trajectory]
## Key Metrics
| Metric | Last Month | This Month | Target | Trend |
|--------|-----------|------------|--------|-------|
| [North Star] | [value] | [value] | [target] | [↑↓→] |
| MRR | [value] | [value] | [target] | [↑↓→] |
| Users | [value] | [value] | [target] | [↑↓→] |
| [Key metric] | [value] | [value] | [target] | [↑↓→] |
## Wins
1. [Accomplishment with impact — e.g., "Shipped X, resulting in Y"]
2. [Accomplishment]
3. [Accomplishment]
## Challenges
1. [Challenge and what you're doing about it]
2. [Challenge]
## Product
[What was built, shipped, or launched this month — concrete deliverables]
## Customers / Users
[New customers, notable feedback, retention signals, churn events]
## Financial
- **Cash**: $[amount]
- **Burn**: $[amount/mo]
- **Revenue**: $[MRR]
- **Runway**: [months]
## Plan for Next Month
1. [Top priority]
2. [Second priority]
3. [Third priority]
## Asks
[What you need help with — intros, advice, hiring, resources. Be specific.]
## Team
[Any changes — hires, departures, role changes]
Create the research/ directory if it doesn't exist.
Next Steps Guidance
The final response and output file must include a ## Next Steps section with one explicit recommendation and 2-4 other options.
Recommendation priority (first applicable becomes the recommendation):
- IF runway, burn, or revenue data is missing or stale: recommend
$runway-model— investor updates need current financial context. - IF metrics are missing or stale: recommend
$metrics— investor updates need a defensible KPI frame. - IF actual usage or retention data exists but has not been reviewed: recommend
$cohort-review— convert operational data into investor-ready signal. - IF the update surfaced strategic misses, stale assumptions, or missed commitments: recommend
$retro— turn the update into a corrective learning loop. - Otherwise recommend
$research-roadmap— choose the next lifecycle task after the stakeholder update is current.
Use this format:
## Next Steps
**Recommended:** [recommended skill] — [one-line reason grounded in the update]
Other options:
- [2-4 applicable alternatives]
Task Classification
When this skill produces follow-up work, file it by execution semantics:
- Immediately actionable implementation or documentation work goes in
tasks/todo.md. - Human-only external actions tied to automated steps go in
tasks/manual-todo.mdwith_(blocks: Step N.X)_or_(after: Step N.X)_; repo edits, SDK wiring, generated assets, local commands, tests, audits, and authenticated CLI/API work stay intasks/todo.md. - One-time condition-gated records, baselines, or future measurements go in
tasks/record-todo.mdwith source, condition, non-blocking reason, evidence, and promotion rule. - Cadence-based reviews, playtests, adoption checks, investor updates, retros, or docs-health checks go in
tasks/recurring-todo.mdwith cadence, owner/agent, next due, evidence path, and escalation conditions. - Do not put non-blocking records or recurring obligations in
tasks/todo.mdunless they have been explicitly promoted into current execution work.
Constraints
- Honest and concise. Investor updates should be transparent, not spin. Bad news delivered with a plan is better than hidden problems.
- Present before writing. Never write until the user validates the update.
- Separate dated files. Each update is a new file. Don't modify previous updates.
- No fabrication. Only include metrics that have real data behind them. If a metric isn't tracked yet, omit it rather than estimate.
- Standard format. Stick to the YC/First Round format — investors expect this structure.
Alignment Page
Follow the shared alignment-page convention via the packaged convention resolver; output path is alignment/investor-update-{topic}.html.
Default Shipping Contract
Follow the shared shipping contract convention in CLAUDE.md.
04 同仓库更多 Skills
source-checkout-allowed
Valid source-checkout-only fixture.
deck-install-valid
Valid deck install fixture.
codex-pack-guard-valid
Valid Codex Pack Availability Guard fixture.
codex-missing-skill-valid
Valid Codex missing skill fallback fixture.
codex-base-skill-fallback-valid
Valid Codex base skill fallback fixture.
claude-pack-guard-valid
Valid Claude Pack Availability Guard fixture.