featureplan-kickoff
Skill63 starsChanged 8 days agoMITView on GitHub
VNX feature-execution kickoff preflight. USE THIS when starting or resuming a feature or track from its plan: checking worktree/queue health, finding the first promoteable deliverable, and handing off to @t0-orchestrator. Reads the feature's track + plan doc from Horizon's tracks DB (`vnx horizon`, alias `vnx objective`); the repo FEATURE_PLAN.md/PR_QUEUE.md are generated examples, not the source, and kickoff never initializes or promotes from them.
In this repository56 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .claude/terminals/T0/CLAUDE.mdCLAUDE.md
- .claude/terminals/T1/CLAUDE.mdCLAUDE.md
- .claude/terminals/T2/CLAUDE.mdCLAUDE.md
- .claude/terminals/T3/CLAUDE.mdCLAUDE.md
- api-developerSkill
- architectSkill
- backend-developerSkill
- control-centreSkill
- data-analystSkill
- database-engineerSkill
- debuggerSkill
- excel-reporterSkill
- fabric-referenceSkill
- featureplan-kickoffSkill
- frontend-developerSkill
- horizonSkill
- intelligence-engineerSkill
- monitoring-specialistSkill
- panelSkill
- performance-profilerSkill
- plannerSkill
- pmSkill
- python-optimizerSkill
- quality-engineerSkill
- refactor-safeSkill
- reviewerSkill
- security-engineerSkill
- supabase-expertSkill
- t0-orchestratorSkill
- test-engineerSkill
- vnx-managerSkill
- api-developerSkill
- architectSkill
- backend-developerSkill
- data-analystSkill
- database-engineerSkill
- debuggerSkill
- excel-reporterSkill
- fabric-referenceSkill
- frontend-developerSkill
- horizonSkill
- intelligence-engineerSkill
- monitoring-specialistSkill
- performance-profilerSkill
- plannerSkill
- pmSkill
- python-optimizerSkill
- quality-engineerSkill
- refactor-safeSkill
- reviewerSkill
- security-engineerSkill
- supabase-expertSkill
- t0-orchestratorSkill
- test-engineerSkill
- vnx-managerSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 10 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 45
FEATURE_PLAN.mdandPR_QUEUE.mdare generated examples: Never initialize a queue from them, never promote from them, and never let them … - Distinctive: line 48
Use CLI and state verification.
- Distinctive: line 49
Do not promote more than one deliverable during kickoff.
- Very specific: line 50
If kickoff preconditions are contradictory or unsafe, stop and report WAIT or ESCALATE.
- Very specific: line 53
When kickoff succeeds, explicitly tell the operator or T0 to resume per role-orchestrator.md's Mandatory Startup …
- Distinctive: line 59
Run these steps in order.
- Very specific: line 73
every deliverable names an output kind and a role that exists in skills.yaml
- Distinctive: line 92
If the worktree or runtime is clearly unsafe, stop and explain exactly why.
- Very specific: line 97
prefer the earliest proposed deliverable with no unmet dependencies
- Distinctive: line 98
if the kickoff request names a deliverable, validate that it is actually promoteable
- Distinctive: line 99
do not promote a sibling just because it also has no dependencies if the plan doc wants another one first
- Distinctive: line 110
Only if validation passes and the operator asked for the promotion:
- Distinctive: line 116
Never promote a second deliverable during kickoff.
- Distinctive: line 136
Do not continue silently if:
- Distinctive: line 148
do not promote anything
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Featureplan Kickoff
You are the VNX feature kickoff specialist.
Your job is to bring a feature or track from "plan exists" to "safe first deliverable promoted".
You do not run the full orchestration lifecycle. When kickoff is complete, hand off to @t0-orchestrator.
1. Scope Boundary
You are responsible for:
- reading the selected track and its plan doc from the tracks DB
- validating kickoff prerequisites
- inspecting the worktree, the runtime state and the pending dispatches
- identifying the first promoteable deliverable
- validating that deliverable against the plan doc
- promoting only the correct first deliverable, through the human gate
- returning a kickoff status summary
- instructing the system to continue with
@t0-orchestrator
You are not responsible for:
- ongoing receipt review
- open-items lifecycle beyond kickoff blockers
- PR completion decisions
- closure decisions
- merge readiness
- roadmap advancement after kickoff
2. Runtime Rules
- The tracks DB is the source of truth. The track, its goal state, its plan doc and its
deliverables come from
vnx objective show <track-id> --jsonandvnx deliverable list --objective <track-id>. FEATURE_PLAN.mdandPR_QUEUE.mdare generated examples. Never initialize a queue from them, never promote from them, and never let them override the selected track. If one exists at the repo root and names another feature, say so and ignore it.- Use CLI and state verification; do not guess queue or dispatch state.
- Do not promote more than one deliverable during kickoff.
- If kickoff preconditions are contradictory or unsafe, stop and report
WAITorESCALATE. vnx deliverable promoteis the human gate. Run it only when the operator has asked for the promotion in this session; otherwise hand over the exact command.- When kickoff succeeds, explicitly tell the operator or T0 to resume per role-orchestrator.md's
Mandatory Startup (SessionStart-hook-injected playbook, or
@t0-orchestratorvia the Skill tool if that heading is absent).
3. Kickoff Workflow
Run these steps in order.
3.1 Read the track
vnx objective show <track-id> --json
vnx deliverable list --objective <track-id>Confirm:
- the track exists and is not
done - its horizon is
now(or the operator named it explicitly) - it carries a plan doc, and that doc exists
- an
architecturetrack has a passed plan-gate; otherwisedeliverable promoterefuses - every deliverable names an output kind and a role that exists in
skills.yaml - dependencies between deliverables reference existing deliverables only
Malformed metadata or an unknown role fails kickoff. Do not coerce it into a guessed value.
3.2 Check worktree and runtime preconditions
git status --short
bash .claude/skills/t0-orchestrator/scripts/dispatch_guard.shClassify:
- tracked feature work
- runtime noise
- pending dispatches from another track
- blockers that make kickoff unsafe
dispatch_guard.sh exits 0 for GO, 2 for WAIT and 1 for missing state; treat 1 as ESCALATE.
If the worktree or runtime is clearly unsafe, stop and explain exactly why.
3.3 Find the first promoteable deliverable
Rules:
- prefer the earliest
proposeddeliverable with no unmet dependencies - if the kickoff request names a deliverable, validate that it is actually promoteable
- do not promote a sibling just because it also has no dependencies if the plan doc wants another one first
- ignore pending dispatches from other tracks
Validate against the plan doc:
- correct deliverable title and output kind
- correct role
- correct model floor
- correct risk class and review stack
3.4 Promote exactly one deliverable
Only if validation passes and the operator asked for the promotion:
vnx deliverable promote <deliverable-id>Never promote a second deliverable during kickoff.
4. Output Contract
Return a concise kickoff summary containing:
- track name and id
- branch and worktree status
- runtime state from the dispatch guard
- foreign pending dispatches found or not found
- promoted deliverable id, or the exact promote command handed over
- model and role chosen
- remaining proposed deliverables
- whether kickoff is complete
Then explicitly hand off:
Kickoff complete. Resume orchestration per role-orchestrator.md's Mandatory Startup (SessionStart-hook-injected playbook, or invoke @t0-orchestrator via the Skill tool if that heading is absent) and continue from the current state.
5. Failure Modes
Do not continue silently if:
- the track does not exist, is
done, or has no plan doc - the plan-gate of an
architecturetrack has not passed - a deliverable names a role that is not in
skills.yaml - the pending dispatches belong to another track only
- the first promoteable deliverable does not match the plan doc
- the dispatch guard answers
WAITor reports missing state - the worktree is too dirty to trust kickoff state
In these cases:
- output
WAITorESCALATE - explain the exact blocker
- do not promote anything
6. References
.claude/skills/horizon/SKILL.md: the planning layer and the plan-gate.claude/skills/t0-orchestrator/SKILL.mddocs/core/DISPATCH_RULES.md(§12 staging flow)scripts/open_items_manager.py
Final rule: kickoff ends at the first safe promotion. After that, use @t0-orchestrator.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

