StielChancellor
UserVibeGod Tech Team — install one plugin and a whole software team (27 expert agents: product, design, security, engineering, QA, release) plans, builds, tests, and ships your idea into a production-grade platform inside Claude Code. You approve; the team does the work. OWASP + WCAG baked in.
Categories
Indexed Skills (46)
accessibility-wcag
Use when building, reviewing, or signing off any UI to enforce WCAG 2.2 AA — color contrast, keyboard operability, focus management, ARIA, alt text, reduced-motion, and forms. Trigger on "is this accessible", "a11y", "WCAG", "keyboard navigation", "screen reader", "contrast", or as part of "done" for any user-facing feature. Provides a concrete checklist an engineer can apply and verify.
analytics-instrumentation
Use to make a product MEASURABLE — define the tracking plan / event taxonomy, instrument events (client + server), and tie dashboards to the PRD success metrics (North Star + inputs). Trigger on "how do we measure this", "add analytics/tracking", "instrument the funnel", "set up events/metrics/dashboards", "North Star", "A/B test measurement", or before any GA so the launch can be measured.
build-roadmap
Use to create the foundation-first build plan before any coding starts — the shared base all modules sit on, then the modules, with milestones and explicit TDD, UAT, smoke-test, and QA plans. Trigger on "make the build plan", "what do we build first", "plan the implementation", "roadmap the work". Ends with a hard gate: explicit user go-ahead before the coding agents run.
change-propagation
Use on EVERY add, change, or delete to a feature or behavior to flow it end-to-end through all artifacts and code with no orphans left behind. Trigger on "change this feature", "add/remove X", "update the behavior", "rename", "refactor across the codebase", or whenever a modification touches more than one place. Enforces PRD -> blueprint -> code roadmap -> graphify -> actual code, updates every call site, and keeps UI and backend in sync.
change-risk-triage
Use to right-size the process to the change — classify a change as trivial / low / standard / high-or-emergency and run only the gates that fit, so a typo doesn't pay the full enterprise gate tax while a risky change gets the whole pipeline. Trigger at the start of any build or change request, on "is this a big change", "fast-track this", "do we need the full process", "hotfix", or "express lane".
codebase-knowledge-graph
Use to keep codebase awareness current via graphify — a knowledge graph of modules, symbols, and dependencies used for impact analysis during change propagation. Trigger on "graphify", "update the code graph", "what depends on this", "impact of this change", or whenever a change needs a full picture of call sites and dependents. Detects whether graphify is installed; if not, offers to auto-install it or proceed with a lighter built-in fallback.
data-engineering
Use for anything touching data at rest or in motion — schema design, database migrations, data pipelines/ETL, data quality, and PII handling. Trigger on "design the schema", "write a migration", "change the database", "build a pipeline/ETL", "data validation", "handle PII", or any change to data models. Enforces safe, reversible migrations and privacy-by-design.
design-refinement
Use to make a UI distinctive instead of generic — when a design "looks AI-made / Claude-type / templated", needs to be bolder or quieter, or before shipping any user-facing surface. Picks real fonts (not training-data defaults), commits to a color strategy, kills cliché patterns, and runs an audit -> polish pass. Trigger on "make it look better", "less generic", "design critique", "polish the UI", "pick fonts/colors", "this looks like AI slop".
devops-delivery
Use to set up or improve delivery and operations — CI/CD pipelines, containers, infrastructure-as-code, staged/canary rollouts, observability/SLOs, rollback, and blameless postmortems. Trigger on "set up CI/CD", "containerize", "deploy", "Terraform/IaC", "canary release", "monitoring/alerting", "SLO", "rollback", or "the deploy broke". Applies top-tier release-engineering practices.
engineering-excellence
Apply how high-performing engineering teams (Google/SRE/DORA) actually work — design docs & design review, code-review standards (small CLs, fast SLAs, improve-code-health), the test pyramid & test sizes, trunk-based development + CI, DORA delivery metrics, SRE SLOs/error budgets/blameless postmortems, secure SDLC (NIST SSDF), and AI-era harness engineering. Use during design review, planning delivery, setting team standards, code review, release/CI-CD decisions, reliability work, or whenever asked "how should we work" / "what's best practice".
frontend-craft
Use whenever building or restyling any user-facing UI — web app, site, landing page, dashboard, or component. Trigger on "build the frontend", "make the UI", "style this page", "it looks generic/like AI slop", or any visual/design work. Enforces distinctive, sophisticated, committed design by default (anti "AI slop") and ties every choice to WCAG 2.2 AA accessibility. Loads before the frontend coding agents run.
identity-access
Use for authentication, authorization, SSO, and multi-tenant isolation — OIDC/OAuth2 + PKCE, enterprise SAML SSO, SCIM provisioning, RBAC/ABAC/ReBAC, deny-by-default server-side authz, tenant isolation, sessions/tokens/MFA. Trigger on "login/auth", "SSO/SAML/OIDC", "SCIM/provisioning", "roles/permissions/RBAC", "multi-tenant isolation", "tokens/sessions/MFA", or any identity/access decision.
integration-engineering
Use for public APIs, webhooks, third-party connectors, and data integration — REST/OpenAPI contracts + versioning + idempotency, signed/idempotent webhooks, the transactional outbox + DLQ, resilient outbound calls (timeout/retry/circuit-breaker), contract testing, and SSRF-safe boundaries. Trigger on "build/expose an API", "webhooks", "integrate with <service>", "connector", "ETL/sync", "rate limit/versioning", or any system-to-system boundary.
journey-mapping
Use to map the complete frontend + backend UI/UX flow of a product after the PRD is approved — every screen, state, branch, and the backend interactions behind them. Trigger on "map the user journey", "what's the flow", "diagram the screens", "draw the UX flow". Produces a Mermaid diagram for simple journeys and auto-switches to the interactive local canvas for complex ones (many nodes/branches).
lang-go
Use when writing or reviewing Go (.go) code or modules — idiomatic style, gofmt/vet/staticcheck, wrapped errors, context propagation, goroutine/channel discipline, the race detector, and Go's top security pitfalls. Triggers on go.mod/go.sum, net/http, database/sql, html/template projects.
lang-java-kotlin
Use when writing or reviewing Java (.java) or Kotlin (.kt) or Spring Boot code — idiomatic Java 21 / Kotlin style, Gradle/Maven, JUnit5, null-safety, and the top JVM/Spring security pitfalls. Triggers on build.gradle(.kts)/pom.xml, Spring, JPA/Hibernate, JdbcTemplate projects.
lang-python
Use when writing or reviewing Python (.py/.pyi) or FastAPI/Django/Flask code — idiomatic 3.11+ style, type hints + mypy/pyright, pydantic boundary validation, error handling, and the language's top security pitfalls. Triggers on pyproject.toml, requirements.txt, ruff/black, pytest, venv/poetry/uv projects.
lang-rust
Use when writing or reviewing Rust (.rs) code or crates — idiomatic style, cargo fmt/clippy, Result/Option error handling (thiserror/anyhow), ownership/borrowing, minimal justified unsafe, and Rust's top safety/security pitfalls. Triggers on Cargo.toml/Cargo.lock, tokio, axum/actix projects.
lang-typescript
Use when writing or reviewing TypeScript/JavaScript (.ts/.tsx/.js/.mjs/.cts) or Node/Next.js/React/Nest/Express code — idiomatic style, strict typing, async error handling, and the language's top security pitfalls. Triggers on tsconfig, package.json, ESLint/Prettier, Vitest/Jest, pnpm/npm/yarn projects.
module-architecture
Use to decompose the system into self-contained modules and define exactly how they communicate — API/events/protocol contracts, dynamic linking, and how upgrades propagate to dependents. Trigger on "break this into modules", "define the interfaces", "how do these services talk", "module map", "what are the contracts". Runs after the stack is confirmed and before the build plan.
performance-engineering
Use to define and enforce performance & scale gates — load/stress/soak/spike tests, latency SLOs (p95/p99), throughput/error-rate targets, capacity & breaking-point analysis, profiling, and Core Web Vitals/RAIL budgets for UI. Use whenever someone asks "is it fast enough", "will it scale", "what's our p99", "load/stress/soak/spike test", "performance budget", "capacity plan", or before any ship gate on a user-facing or high-traffic surface. Gates ship on performance.
platform-blueprint
Use when defining the enterprise architecture of a non-trivial system — Architecture Decision Records (ADRs), non-functional requirements (scale, latency, cost, security, privacy), C4-style views, and a threat-model hook. Trigger when the user asks to "design the architecture", "write an ADR", "what are the NFRs", "how should this be structured at scale", or after the PRD is approved and before stack selection. Produces a modular-by-default decomposition the rest of the pipeline builds on.
prd-authoring
Use to create or maintain the Product Requirements Document — the source of truth for what is being built. Trigger at project kickoff ("let's build X", "write the PRD", "what are the requirements") and on ANY feature change/add/removal, which re-enters here first. Starts from the end objective, lets the user dump everything before any planning, and designs for modularity by default. Never jumps to a solution or a plan.
product-discovery
Apply how high-performing product teams work — continuous discovery, opportunity-solution trees, Amazon working-backwards / PR-FAQ specs, prioritization (RICE/ICE/MoSCoW/Kano/WSJF), goal-setting (OKRs, North Star, HEART, AARRR), outcome-based roadmaps, JTBD + usability testing + MVP, Cagan's four risks, empowered teams, and accessibility as a product duty. Use during discovery, PRD/brainstorm, prioritization, roadmapping, defining success metrics, validating an idea, or any change request — i.e. Stages 0/1/9 and whenever deciding WHAT to build and why.
qa-gates
Use to run the multi-lens QA model that gates every feature and the final ship. Trigger before closing any feature ("is this feature done", "QA this", "feature check") and before shipping ("ship check", "final QA", "ready to release"). Per feature, dispatch security-engineer + code-quality-reviewer + adversarial-tester + qa-engineer (plus ux-design-reviewer for UI) in PARALLEL — all must pass. Final gate adds a best-practices pass + UAT + smoke before ship.
secure-coding
Apply OWASP-grounded secure coding when writing or reviewing backend, frontend, API, data, or infrastructure code, handling auth/secrets/user input, or doing a security pass. Use whenever code touches authentication, authorization, secrets, databases, file/network I/O, deserialization, or external input — and during the security-engineer QA lens and /ship-check.
security-architecture
Use when setting the SECURITY DESIGN of a system or major feature — zero-trust architecture, identity/access and multi-tenant isolation strategy, STRIDE threat modeling, trust boundaries, crypto/key-management strategy, and security-by-design reviews of the blueprint. Trigger for Stage 4 (module map / blueprint) security review and whenever a new service, trust boundary, tenancy model, or auth model is introduced. NOT for code-level OWASP review of an implementation (that is the security-engineer / secure-coding lens).
tech-stack-and-cost
Use to design the technology stack for a product from its frontend, backend, UI/UX, and end outcome — and to attach implementation and run cost to every significant choice. Trigger on "what stack should we use", "pick the technologies", "how much will this cost to run", "is there a cheaper option". ALWAYS shows cost, and whenever a choice is expensive presents a cheaper alternative with pros/cons and exactly what is lost. Requires explicit cost sign-off before proceeding.
technical-writing
Use to author or review developer- and user-facing documentation — API reference, admin/developer/user guides, runbooks, release notes, tutorials, how-to guides, conceptual explanations, and ADR polish. Use whenever a feature changes public behavior and needs docs, when shipping a runbook or release notes, or when judging whether docs are GA-ready. Structures every page with the Diataxis framework and enforces the Google + Microsoft style guides.
test-automation
Use when authoring, shaping, or hardening automated tests and CI test infrastructure — the test pyramid (unit/integration/contract/E2E), headless runners, test data and doubles, consumer-driven contracts, flaky-test detection/quarantine, and the green-build gate that backs QA. Trigger on "add tests", "set up CI tests", "this test is flaky", "contract test", "e2e/visual/regression automation", or "why is the suite slow/red".
ui-ux-excellence
The golden rules an expert UI/UX designer applies when building or reviewing any page, screen, or component — usability heuristics, color (60-30-10, WCAG contrast), typography, 8-pt spacing/grid, design tokens, responsive/cross-device behavior, the four data states, motion, and a visual-QA checklist for catching broken or inconsistent layouts. Use when designing UI, building a page/screen/component, choosing colors/typography/layout, judging "does this look right / is it broken", or reviewing a front-end for quality and cross-screen consistency.
ux-research
Use when you need EVIDENCE about real users — to plan a study, run usability tests (~5 users, think-aloud, realistic tasks), interview users (JTBD/critical-incident), field-study in context, run surveys or A/B, or validate a journey/prototype against actual behavior before the design or scope is locked. Picks the right method for the question and lifecycle phase, separates observation from interpretation, and never lets stated opinion stand in for observed behavior.
brainstorming
Use BEFORE any creative or build work — creating features, components, functionality, a new project, or modifying behavior. Explores user intent, requirements, and design through one-question-at-a-time dialogue and produces an approved design/spec before any code. Triggers on "build/create/add/start a ...", vague feature requests, or any task where jumping to code would be premature.
dispatching-parallel-agents
Use when facing 2+ INDEPENDENT tasks, failures, or subsystems that can be worked on concurrently without shared state or sequential dependencies — e.g. multiple unrelated test files failing, separate modules to build, or distinct bugs. Triggers when sequential investigation would waste time and each problem domain is self-contained.
executing-plans
Use when you have a written implementation plan to execute inline in the current/separate session with review checkpoints, and subagents are unavailable or the tasks are tightly coupled. Triggers after writing-plans when the user picks inline execution. If subagents ARE available, prefer subagent-driven-development.
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work — presents structured options for merge, PR, keep, or discard, and handles worktree cleanup safely. Triggers at the end of executing/subagent-driven development or whenever a feature branch is ready to land.
receiving-code-review
Use when receiving code review feedback (from a reviewer subagent, an external reviewer, or the user), before implementing any suggestion — especially if feedback seems unclear or technically questionable. Requires verifying against the codebase and reasoned pushback, not performative agreement or blind implementation.
requesting-code-review
Use when completing a task, finishing a major feature, or before merging — dispatch a fresh code-reviewer subagent with precisely-crafted context to catch issues before they cascade. Triggers after each task in subagent-driven development, before merge to main, or when stuck and needing a fresh perspective.
subagent-driven-development
Use when executing an implementation plan with mostly-independent tasks in the current session by dispatching a fresh subagent per task with two-stage review (spec compliance, then code quality). Triggers after writing-plans when the user picks the subagent-driven option, or whenever coordinating a coding swarm task-by-task.
systematic-debugging
Use when encountering ANY bug, test failure, crash, performance problem, build failure, or unexpected behavior, BEFORE proposing or attempting fixes. Forces root-cause investigation before patches. Triggers especially under time pressure, when a "quick fix" seems obvious, or when previous fixes didn't work.
test-driven-development
Use when implementing ANY feature or bugfix, before writing implementation code. Write the failing test first, watch it fail, write minimal code to pass, refactor. Triggers whenever you are about to write production code, fix a bug, or change behavior — and especially when you catch yourself wanting to "skip tests just this once".
using-git-worktrees
Use when starting feature work that needs isolation from the current workspace, or before executing an implementation plan, or before dispatching parallel coding agents. Ensures an isolated workspace exists — detect existing isolation, prefer the harness's native worktree tools, fall back to git worktree only if none.
verification-before-completion
Use when about to claim work is complete, fixed, passing, or done — before committing, creating a PR, marking a task complete, or moving on. Requires running the verification commands and confirming output (and the consistency/no-orphans check) BEFORE any success claim. Evidence before assertions, always.
vibegod-orchestrator
The lead engineer/orchestrator for building or improving a software platform, app, website, service, or system. Use whenever the user wants to design, build, scope, plan, architect, or extend ANY non-trivial software product, or asks to "create a platform/app", "build a system", "start a new project", or "add a major feature". Runs a strict, gated enterprise SDLC (PRD -> journey -> stack+cost -> modules -> foundation-first build -> multi-lens QA -> UAT/smoke -> ship) and delegates to specialist subagents. Enforces security (OWASP), accessibility (WCAG), and never jumps straight to code.
writing-plans
Use when you have an approved spec/PRD/requirements for a multi-step task and need a concrete implementation plan, BEFORE touching code. Produces bite-sized, TDD-structured tasks with exact file paths, real code, and exact verification commands. Triggers after brainstorming/PRD approval or whenever someone says "write a plan", "plan this out", or hands you requirements to build.
writing-skills
Use when creating a new skill, editing an existing skill, or verifying a skill works before deployment. Treats skill authoring as TDD for process documentation — baseline a pressure scenario, write the skill, confirm compliance, close loopholes. Triggers on "write/create/improve a skill", "add a SKILL.md", or changes to skill content.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.