一键导入
where-are-we
Show project progress — what's done, what's next, and what to kick off. Reads PROJECT.state.yaml to give a status report across all work streams.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Show project progress — what's done, what's next, and what to kick off. Reads PROJECT.state.yaml to give a status report across all work streams.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Interactively scaffold a new team-kickoff phase config YAML. Use when the user wants to plan a new phase but doesn't have a config file yet.
Execute approved plan docs by spawning teammates to write actual code. Takes the same phase config YAML used by /team-kickoff. Each teammate reads their approved plan doc and writes the code files described in it, then self-verifies with build and test commands.
Scaffold a complete code project — generates PROJECT.md and phase kickoff YAMLs from a few questions. Analyzes project complexity to decide phases, teammate roles, and focus areas automatically. Run this to go from idea to ready-to-kickoff in seconds.
Execute approved plan docs by re-spawning teammates to write full deliverables. Takes the same phase config YAML used by /team-kickoff. Each teammate reads their approved plan doc and produces the final detailed content.
Spawn a multi-agent planning team from a phase config YAML. Use when the user wants to kick off a new planning phase with multiple specialized teammates, each writing a dedicated plan doc. Each teammate stays in PLAN MODE and follows the master plan template verbatim.
Interactively define a new project from scratch — captures the core idea, architecture, tech stack, non-goals, constraints, and team composition into a PROJECT.md source-of-truth doc. Run this before /new-team-phase or /team-kickoff.
| name | where-are-we |
| description | Show project progress — what's done, what's next, and what to kick off. Reads PROJECT.state.yaml to give a status report across all work streams. |
| argument-hint | [optional: track name to focus on] |
| disable-model-invocation | false |
Read the project state file and present a clear status report showing what's been done and what's next.
Look for PROJECT.state.yaml in the current working directory (project root). If it doesn't exist, tell the user:
No PROJECT.state.yaml found in this project.
To create one, either:
- Run /team-code-project to scaffold a new project (generates it automatically)
- Create one manually — see the format at ~/.claude/skills/where-are-we/SKILL.md
If it exists, read it.
If $ARGUMENTS names a specific track (e.g., "compute-spawning"), focus on that track only. Otherwise, show all tracks.
## <Track Name> — <status emoji> <status>
<description>
| Phase | Plan | Execute | Config | Notes |
|-------|------|---------|--------|-------|
| <phase> | <plan_status> | <execute_status> | <config path> | <notes> |
...
Plan status tracks /team-kickoff (writing plan docs):
Execute status tracks /team-execute or /team-code-execute (writing deliverables/code):
Overall phase status is derived:
next → plan not started, dependencies met (suggest /team-kickoff)planning → plan in progressplanned → plans done, execute not started (suggest /team-execute or /team-code-execute)executing → execute in progressdone → both plan and execute donepending → dependencies not metblocked → explicitly blockedStatus emoji mapping:
Collect ALL phases across ALL tracks that are actionable. Two types of actionable:
plan_status: not_started and dependencies metplan_status: done and execute_status: not_started## What's Next
Ready to execute (plans approved):
1. **<track> / <phase>** — <notes>
Execute: `/team-execute <config path>` or `/team-code-execute <config path>`
Ready to plan (dependencies met):
1. **<track> / <phase>** — <notes>
Kick off: `/team-kickoff <config path>`
Prioritize "ready to execute" over "ready to plan" — finish what's already planned first.
Collect phases where status: pending and show what they're blocked on.
## Coming After
- **<track> / <phase>** — blocked on: <depends_on list>
End with a direct suggestion:
Suggested next action: /team-kickoff <path to highest-priority next phase config>
Priority order for suggestions:
in_progress (finish what you started)project: <name>
updated: <date>
tracks:
<track-slug>:
description: "<what this work stream is>"
project_doc: <path to PROJECT.md> # optional
status: done | in_progress | pending
phases:
<phase-slug>:
config: <path to kickoff.yaml> # for team phases
plan_status: not_started | in_progress | done
execute_status: not_started | in_progress | done
completed: <date> # when both plan + execute are done
commit: <short sha> # when done
depends_on: [<phase-slugs>] # within same track
notes: "<what this phase does>"
Status lifecycle per phase:
plan_status: not_started → /team-kickoff starts → plan_status: in_progressplan_status: done/team-execute or /team-code-execute starts → execute_status: in_progressexecute_status: done, set completed date