Getting Started by Role¶
The toolkit ships 125 skills. You do not need most of them. This page gives each role a short, opinionated starting point: what the toolkit does for you, the handful of skills that matter, and the one entry-point skill to run first.
Pick your role below. Only the Developer role is fully written today; the other roles are deliberately stubbed until their own specs land (see the note under each).
Developer¶
Who you are: you write code with this toolkit — features, bug fixes, UI, or prototypes. You are comfortable in Claude Code but have little patience for scanning a 125-skill list to find the five you actually need.
What the toolkit does for you: it wraps your work in a spec-driven loop (plan → build → review → finalize) with security and quality gates, and it captures what you learn so the next person (or the next you) does not repeat a mistake.
Start here: run /vt-c-dev-start — the developer entry
point. Give it your task type (feature, bug, ui, prototype, skill, or
debug) and it prints the ~5 skills for that task and where to begin. Everything
below is the same map in a persistent, readable form.
Top 5 skills for your day-to-day:
| Skill | Use it to |
|---|---|
/vt-c-activate |
Load a spec (or generate one from a PRD) and start the build cycle |
/vt-c-2-plan |
Research, architecture, and a task breakdown before you write code |
/vt-c-3-build |
Implement against the plan with decision journaling |
/vt-c-4-review |
Mandatory multi-agent security + quality review |
/vt-c-5-finalize |
Pre-merge verification and merge-readiness checks |
Task-specific maps: for bug work, UI, prototypes, or building skills/agents, see
Getting Started by Task — it mirrors the six categories that
/vt-c-dev-start uses.
Kept in sync: the skill lists surfaced by
/vt-c-dev-startare read fromdocs/skill-orchestration-map.json(regenerated byscripts/generate-skill-map.sh), so they track the deployed skills rather than a hand-maintained copy that drifts.
PM¶
Coming soon — a separate spec.
A Product-Manager onboarding view (which skills matter for planning, prioritisation, and the domain dashboard) is intentionally not written here yet. It will land as its own spec once the PM workflow is validated with the team, so this page does not conflate developer onboarding with product-planning concerns.
Until then, developers should use the Developer role above.
Support¶
Coming soon — a separate spec.
A Support-role view (bug intake, triage, and customer-facing troubleshooting) is deferred to its own spec, to be written when the support workflow is confirmed with the people who will actually use it.
Power-User¶
Coming soon — a separate spec.
An advanced view for toolkit maintainers and power users (governance, skill authoring at scale, cross-project aggregation) is deferred to its own spec. The Developer role above already covers the skill-authoring entry points for everyday use.
Why only Developer is complete¶
Wave 1 of the toolkit's discoverability work targets the one role with a confirmed, present need: developers. Filling in the other three roles speculatively is exactly the over-reach that got an earlier adoption spec withdrawn, so each remaining role gets its own spec once its need is validated — not a placeholder written on a guess.