From supervibe
Use WHEN starting any new user-facing feature to orchestrate end-to-end flow from requirements to merge with all gates enforced. Triggers: 'новая фича', 'feature scaffold', 'давай новую фичу', 'начни фичу'.
npx claudepluginhub vtrka/supervibe --plugin supervibeThis skill is limited to using the following tools:
WHEN user says "let's build feature X" and X is non-trivial (estimated complexity ≥4). This is the orchestrator that chains the entire feature workflow.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
WHEN user says "let's build feature X" and X is non-trivial (estimated complexity ≥4). This is the orchestrator that chains the entire feature workflow.
NOT for: bug fixes (use systematic-debugging), refactors (use refactoring-specialist), config-only changes.
Do not stop after PRD, brainstorm, prototype, plan, first task, or review if the feature workflow still has a clear next gate and no blocker. Each stage must either hand off to the next stage with artifact path, confidence, and stop condition, or stop with the exact missing approval/evidence.
Intermediate stage approval is not a feature completion signal. The feature is complete only when the approved scope is implemented, verified, reviewed, scored at least 9/10, and either merged/released or explicitly parked with a saved state and next command.
Start execution only after the product outcome, approved scope, acceptance criteria, design/prototype need, plan path, verification commands, rollback, and release path are known. If any of these are unknown, route to the owning skill instead of improvising in implementation.
A feature is done only when user-facing behavior meets acceptance criteria, tests/verification pass, security/privacy/observability/release gates are handled for the risk level, code review and quality gate evidence exist, and no deferred optional scope is hidden inside the delivered work.
Follow docs/references/skill-expert-operating-standard.md: start from source of truth, preserve retrieval evidence, apply scope safety, use real producers with runtime receipts for durable delegated outputs, verify before completion claims, and keep confidence below gate when evidence is partial.
MEMORY.md for prior preferencesFeature has clear product framing?
├─ NO → start with supervibe:prd (product-manager agent)
└─ YES → skip PRD
Feature visual / UI?
├─ YES → after design phase, supervibe:prototype + brandbook check
└─ NO → straight to plan + execute
Feature backend-heavy?
├─ Yes → involve appropriate stack-specific architect early
└─ NO → skip architect involvement
supervibe:prd if no clear product framingsupervibe:requirements-intake to set complexity routingsupervibe:brainstorming if complexity ≥7 (else skip)supervibe:brandbook if no brandbook exists, then supervibe:prototypesupervibe:writing-planssupervibe:using-git-worktrees for isolationsupervibe:executing-plans (or supervibe:subagent-driven-development)supervibe:pre-pr-checksupervibe:requesting-code-review → code-reviewer agent → supervibe:receiving-code-reviewquality-gate-reviewer agentsupervibe:finishing-a-development-branchsupervibe:confidence-scoring agent-output for entire feature; ≥9 required to mark doneReturns:
supervibe:evaluate (Phase 6)