Workflows overview
A workflow here is a chain of skills and agents that takes one kind of work from request to result. Each page below says which step runs in the main conversation and which in a subagent, where a person has to decide, and which files the workflow leaves behind.
The five workflows
| Workflow | Starts with | Plugins it needs |
|---|---|---|
| Feature implementation | orchestrating-feature-implementation, which writes a plan first through creating-implementation-plans | tsh-product-engineering; tsh-core for the Figma MCP server when a task is backed by a design; the Playwright CLI on the machine when a task is UI work or the verification document has browser scenarios |
| UI verification | reviewing-ui for one pass, or the UI verification gate inside feature implementation | tsh-product-engineering and tsh-core (Figma MCP), plus the Playwright CLI on the machine |
| Debugging | debugging-code | tsh-product-engineering |
| Business analysis | analyze-materials or explore-materials, both running orchestrating-business-analysis | tsh-product-management; tsh-core for the Atlassian MCP server (Jira) and the Figma MCP server (designs) |
| Project context | /tsh-core:init for a repository's own Claude Code context; initializing-project-context for a project's shared knowledge base | tsh-core for the repository side; tsh-product-management for the knowledge-base side |
How to install each plugin, and at which scope, is on the installation page.
What the workflows have in common
- The main conversation orchestrates. In feature implementation and business analysis it owns the plan or the gate ledger, the delegation and every question to the user. Subagents do the reading and the implementation work, and start with no conversation history, so every delegation carries the file paths they need.
- State lives in files, not in the conversation. Feature implementation works from a plan file at
specifications/<task-id>/<task-name>.plan.md. Business analysis records each gate approval inspecifications/<workshop-name>/.gates.mdbefore the action it unlocks. - People decide at named points. A plan is executed only after the user has read it. Nothing reaches Jira before Gate 2 is recorded. A project-context skill creates a branch, commits or pushes only after its own yes for that step.
- Workflows hand over to each other. A bug whose fix outgrows a minimal change leaves debugging for a plan. Every Figma-backed UI task in feature implementation closes through UI verification. The domain dictionary that business analysis produces is wired into a repository by
managing-claude-context, part of project context. - Missing plugins are named, not worked around. A skill that needs another plugin's work — E2E suites, infrastructure, implementation — names the gap to the user instead of improvising it.