Web Studio for Claude Code

Read in: English · Русский · Español · Deutsch · 中文

Web Studio turns Claude Code into a full web development studio: 30 specialised agents in three tiers, 50 slash commands that form a pipeline from idea to production, hooks that guard secrets and commit hygiene, path-scoped coding rules, document templates, a dated reference of current stack versions and best practices, and a framework for testing the agents themselves. It covers web applications and browser games alike.¹

Stack: Go 1.27 · PHP 8.5 (Yii3 reference; Symfony/Laravel/Slim by choice) · TypeScript 7 / Node 24 · Angular 22 (Material, Taiga UI) · Vue 3.5 / Nuxt 4 · Vite 8 · GraphQL first, REST where it fits · PostgreSQL 18 · three.js r185 / PixiJS 8 / Phaser · Vitest 4 / Playwright · Docker / GitHub Actions · OWASP Top 10:2025 · WCAG 2.2 AA.

The conversation language is chosen per project (/init asks); code, identifiers and commit messages stay in English.

---

1. Install

Option A — Claude Code plugin (recommended)

claude plugin marketplace add gonimar/claude-web-studio
claude plugin install web-studio@claude-web-studio        # --scope user (default) | project | local

Agents, skills and hooks are now available in every project. Skills are namespaced: /web-studio:init, /web-studio:help, … Update with claude plugin update web-studio.

Option B — vendored copy inside the project

git clone https://github.com/gonimar/claude-web-studio ~/tools/claude-web-studio
~/tools/claude-web-studio/install.sh /path/to/project            # add --with-testing for the agent test framework

Everything lives in the project's .claude/ directory, no plugin dependency, skills without a prefix (/init, /help). Update by re-running the installer or with /update.

Option C — new project from the template

~/tools/claude-web-studio/install.sh --new /path/to/new-project

Creates the directory, runs git init, installs option B and writes a starter CLAUDE.md.

Options A and B coexist: a plugin gives central updates, a copy is fully editable per project.

---

2. First session

1. Open Claude Code in the project and run /init (plugin: /web-studio:init). It asks the conversation language and the review mode (lean for solo work, full for teams, solo for no gates), then creates the project files: CLAUDE.md sections, .claude/docs/ (stack reference, templates, roster), .claude/rules/, docs/, production/.
2. New idea? run /start — it asks where you are (idea / clear product / browser game / existing code) and routes you. Existing code? run /adopt — it detects the stack from lockfiles, audits what documents exist, merges settings and writes a numbered adoption plan.
3. Follow the pipeline. /help always tells you the current phase and the single next command.

Pipeline: discovery → specification → architecture → build → hardening → release → operate (.claude/docs/workflow-catalog.yaml). Phase gates are advisory — you decide.

3. Coming back in a new session

Nothing needs to be re-explained. When a session starts, the hook hands Claude the branch, recent commits, the current stage, the stack-reference age and — if you left work unfinished — the contents of production/session-state/active.md (Task:, Branch:, Next:, Blocked:), and shows you a three-line summary (branch state · stage, task and next step · warnings and an open gate) in the terminal and in the VS Code extension. CLAUDE.md is loaded automatically, so the language, stack and principles are known.

Typical return: read the three-line summary → /help → continue with the command it names (usually /dev-story S-NNN or /code-review --diff). After context compaction the same hook runs again and hands Claude the whole active.md and the modified files; /dev-story keeps active.md updated as it works. The plan of record is production/roadmap.md (a checkbox list); sprints and stories live in production/.

Every other situation — a new or an existing project step by step, the build cycle, releases, periodic maintenance, incidents, hook messages, lost context — is in the playbook: docs/playbook.md (/help guide inside a project). What the studio does not do yet is listed in docs/roadmap.md.

4. How the studio works

• Agents are tiered: two directors (Opus) decide, seven leads (Sonnet) design and review, twenty-one specialists implement. Skills route work to the right agents automatically.
• One protocol for every agent: ask when the spec is unclear → offer 2–3 options with costs → you decide → show a draft → "May I write?" → verify by running tests and commands.
• Nothing is claimed done without evidence: acceptance criteria map to tests, and /story-done runs them.
• Security is built in: hooks block secrets in commits and files and force-pushes; every sensitive path gets an application-security review; the release gate requires clean audits.
• The stack reference is the source of truth for versions: agents read .claude/docs/stack-reference/<technology>.md before working and warn when it is older than 60 days. /stack-update refreshes it from official sources.

---

5. All commands

Plugin mode prefixes each with web-studio:.

Onboarding and maintenance

• /init — scaffolds the studio files in the project, asks the conversation language and review mode, merges settings.
• /start — onboarding for a new project: asks where you are and routes to the right first steps.
• /help — shows the current phase, which steps are done and the single next command; /help commands lists every command with its description, /help guide [topic] opens the playbook (what to run in every situation — docs/playbook.md).
• /adopt — attaches the studio to an existing project: detects the stack, audits documents, produces an adoption plan — fills technical-preferences.md from the detected facts and writes a checkbox adoption plan that /help follows.
• /migrate — converts documents in older or foreign formats (roadmap, stories, ADRs, specs, sprints) to the current templates, keeping IDs and history; dry run before any write.
• /setup-stack — chooses and pins the stack (backend, frontend, API style, engine, database, tests, CI) with exact versions.
• /stack-update — refreshes the stack reference from official sources with dates and proposes an upgrade plan for the project.
• /update — updates the studio itself in the project (plugin update or copy-mode reinstall) while keeping local edits.
• /skill-test — lints skills and agents, evaluates them against behavioural specs and reports coverage.
• /skill-improve — runs a test → fix → retest loop on one skill or agent.

Product and design

• /brainstorm — explores a vague idea into a concept brief with audience, differentiation and hypotheses.
• /product-spec — writes the product specification section by section with goals, users, scope, NFRs and risks.
• /feature-spec — writes one feature's specification with scenarios, rules, contract, states, edge cases, security and acceptance criteria.
• /ux-spec — specifies a flow or screen with every state, copy, accessibility and responsive behaviour.
• /design-system — defines design tokens, themes and the component inventory, mapped onto Material, Taiga or a Vue kit.
• /game-concept — writes a browser-game concept with core loop, mechanics, economy, feasibility budgets and a prototype plan; /game-concept gate records the prototype go/no-go.

Architecture

• /architecture-decision — creates or retrofits an ADR with options, decision, consequences and verification.
• /architecture-review — cross-checks ADRs, contracts, data model, threat model and specs for consistency (read-only).
• /impact — classifies a change proposal from the conversation (architecture, security, product scope or routine) by the ADRs, threat-model surfaces and paths it touches, gets the owning director's short verdict and hands off to the commands the verdict requires.
• /api-contract — designs the API contract before code: GraphQL SDL by default, or OpenAPI/AsyncAPI/WebSocket protocols.
• /data-model — designs entities, PostgreSQL DDL with justified indexes and expand/contract migrations.
• /threat-model — builds the STRIDE threat model per attack surface with mitigations and priorities.
• /test-setup — sets up the test strategy and configuration for the chosen stack, from unit to e2e and security.

Build

• /create-stories — slices a feature spec into vertical-slice stories with a criteria-to-test matrix.
• /dev-story — implements one story end to end through the right engineers, with tests and a criteria check.
• /code-review — reviews files or the current diff for correctness, standards, ADR conformance, security and performance.
• /story-done — verifies a story is truly done (tests run, checks green, review approved) and closes it.
• /sprint-plan — plans a sprint from ready stories, capacity and dependencies, and triages the Dependabot/Renovate queue (green patch/minor merged at sprint start, majors become stories).
• /sprint-status — reports sprint progress from artefacts, blockers, the dependency-update queue and risk to the goal.
• /backlog — records an idea from the conversation as one line in production/backlog.md without acting on it; weekly review; promotes an idea to /brainstorm, /impact or /feature-spec.
• /retrospective — sprint retrospective from artefacts: planned vs shipped, estimate vs actual with the calibration ratio the next /sprint-plan applies, blockers, actions with owners.
• /qa-plan — maps every story's acceptance criteria to test levels, tools and files for a sprint.
• /tech-debt — inventories technical debt and proposes prioritised stories.
• /refactor — refactors the maintained code without changing behaviour: a dry-run plan by numbers (build, tests, coverage, dependency graph, test smells), stories, and the execution from a story with characterisation tests first and one green step per commit; layout migrates a Go or PHP service to the layered architecture, tests brings tests to the rules, framework (PHP) inventories and plans a move to another framework.
• /docs — documentation for people through tech-writer: README, API reference generated from the contract, user guide from the feature specs, runbook; every command in the docs is run first.

Hardening

• /security-audit — audits code and configuration against OWASP Top 10:2025 with tools, CVSS-scored findings and fixes; BLOCKING findings go to production/findings.md, which /create-stories and /sprint-plan read.
• /dependency-audit — audits the supply chain: vulnerabilities, abandoned packages, outdated majors, licences, pinning.
• /harden — hardens headers, TLS, proxy, containers and CI, verifying with live requests.
• /pentest — runs authorised dynamic testing against the project's own application within a recorded scope.
• /perf-audit — measures Core Web Vitals, bundles, API latency, queries or game frames against budgets and ranks fixes.
• /a11y-audit — audits accessibility against WCAG 2.2 AA with axe and a manual keyboard checklist.

Release and operations

• /changelog — generates the changelog from Conventional Commits and proposes the version bump.
• /release-checklist — runs the release gate from evidence and writes the release file with rollback steps.
• /deploy — plans and executes a deployment with confirmations, smoke checks and rollback, handing the stack mutation to the declared deploy delegate by the deploy target contract (docs/deploy-target-contract.md) or producing runbook steps when none is declared.
• /hotfix — fa