TSH Product Engineering
tsh-product-engineering carries TSH's spec-driven implementation workflow: a plan file the team can read and commit, implementer subagents that keep file churn and MCP traffic out of your conversation, a Figma-backed UI verification gate driven by Playwright CLI capture, root-cause bug fixing guarded by a regression test, and a delegated review gate at the end.
Who installs it and where
Install it at user scope. The plugin travels with you, not with a repository. The install commands live on the installation page, which renders the repository README, so they are not repeated here.
Once installed, skills are invoked as /tsh-product-engineering:<skill> and agents as @tsh-product-engineering:<agent>. Release notes are on the changelog page.
What it ships
| Skill | Invoke | What it does |
|---|---|---|
| capturing-ui-evidence | No command — Claude or an agent loads it when the work matches | The mechanical capture contract for UI verification: drives the playwright-cli against the pinned dev server URL to collect actual.png, computed-styles.json and a11y-snapshot.yml into the iteration artifact directory. Works with no design reference at all; when — and only when — the caller supplies a Figma URL, it also exports the shared reference image. Evidence collection only — judging the result is the ui-reviewer agent's job. |
| creating-implementation-plans | /tsh-product-engineering:creating-implementation-plans | Writes TSH's implementation plan as a committed file at specifications/<task-id>/<task-name>.plan.md: phased tasks that each name their files and a verifiable Definition of Done, technical context persisted for implementers, explicit parallel groups. Use when a plan, spec, or task breakdown is asked for — a plan kept outside the repository cannot be committed, reviewed in a PR, or read by an implementer subagent. |
| debugging-code | /tsh-product-engineering:debugging-code | Finds and fixes the root cause of a bug: pins the symptom, reproduces it, secures a failing test — existing, corrected or new — narrows to the cause with evidence rather than plausibility, measures how far the fix reaches before applying it minimally, and keeps the test as a regression guard. Use when code behaves wrongly and the cause is not yet known — load it before reading, searching, or editing the code, because locating the cause is this skill's own first step, not something to do before it. |
| discovering-technical-context | /tsh-product-engineering:discovering-technical-context | Establishes which conventions a change must follow before it is written, in priority order: the plan's persisted technical context, then project instructions (CLAUDE.md, .claude/rules, decision records), then existing codebase patterns, then external documentation. Use to answer 'how does this project do X' or to fill a plan's Technical Context section. |
| orchestrating-feature-implementation | /tsh-product-engineering:orchestrating-feature-implementation | Implements a feature, ticket, or plan end to end from the main conversation: confirms a plan file exists, delegates each task to implementer subagents — in parallel where the plan allows — gates on their reports, then closes with the plan's final verification phase: code review and functional verification in parallel. Use for any feature request or multi-file change, before the first file is edited. |
| reviewing-code | /tsh-product-engineering:reviewing-code | TSH's pre-merge review of a delivered change set — a pasted diff, a task, or a PR: reads the plan and requirements first, compares the implementation against what was agreed, judges test coverage per layer, runs the project's tests, linters and build when they are available, then checks high-risk anti-patterns, security, and scalability. Use when a change must be judged for merge readiness, whether it arrives as a pasted diff or a branch, against its plan or acceptance criteria when those exist. |
| reviewing-ui | /tsh-product-engineering:reviewing-ui | Runs one UI verification pass against Figma: delegates fresh Playwright-CLI capture of the running app to ui-capture-worker, then the design comparison to ui-reviewer, and returns PASS, FAIL, or VERIFICATION NOT RUN with a complete difference table. Read-only — it never fixes code. Use when asked to verify implemented UI against a Figma design or check whether a page matches its design. |
| verifying-ui | No command — only agents that preload it | The standard for judging implemented UI against its Figma design: EXPECTED comes only from the Figma MCP, ACTUAL only from live Playwright-CLI capture artifacts, compared across structure, layout, dimensions, visual and components under strict tolerances, ending in PASS, FAIL, or VERIFICATION NOT RUN. This is the judging standard the ui-reviewer agent applies — to actually run a verification pass, use reviewing-ui. |
| Agent | Mention | Model | What it does |
|---|---|---|---|
| code-reviewer | @tsh-product-engineering:code-reviewer | opus | Reviews a delivered change set against its plan and requirements — executes tests, linters, and build, judges coverage, checks security and high-risk anti-patterns — and returns a structured findings report. Use after implementation tasks complete, before merge. |
| feature-verifier | @tsh-product-engineering:feature-verifier | sonnet | Executes a plan's verification document against the running application — committed E2E suites, browser walkthroughs with examined screenshots, real API calls, database and log checks — and returns per-scenario evidence. Use in a plan's final verification phase, in parallel with code review. |
| software-engineer | @tsh-product-engineering:software-engineer | sonnet | Implements delegated implementation-plan tasks — application code, tests, and configuration — exactly as specified, and verifies each with the plan's own commands. Use to execute one or more tasks from a *.plan.md, including several agents in parallel across independent tasks. |
| ui-capture-worker | @tsh-product-engineering:ui-capture-worker | haiku | Collects UI verification evidence from a running app with the Playwright CLI — full-page screenshot, computed styles, accessibility snapshot — into the iteration artifact directory, and exports the shared Figma reference image when given a Figma URL. Use during UI verification, always before ui-reviewer judges design fidelity. |
| ui-engineer | @tsh-product-engineering:ui-engineer | sonnet | Implements UI components and frontend changes from a design reference, fetching the Figma design before writing code and verifying the rendered result in a browser against it. Use for plan tasks that change rendered UI, especially Figma-backed screens and components. |
| ui-reviewer | @tsh-product-engineering:ui-reviewer | sonnet | Judges implemented UI against its Figma design from live capture artifacts — multimodal screenshot comparison plus computed styles and accessibility snapshot — and returns PASS, FAIL, or VERIFICATION NOT RUN with a complete difference table and recommended fixes. Use after ui-capture-worker has produced the iteration artifacts, never before. |
Every skill except verifying-ui is model-invocable, and the descriptions are written to route on the work you describe, such as "implement this ticket", "plan this feature", "is this ready to merge" or "does this page match the design". Each skill also names the sibling that owns the adjacent job, so they do not compete for the same request.
verifying-ui and capturing-ui-evidence stay out of the / menu (user-invocable: false). They are contracts that the UI agents preload, not commands worth typing. verifying-ui is also disable-model-invocation: true, so "does this page match the design?" routes to reviewing-ui, the pass that applies the standard, and never to the standard itself.
How the pieces fit
| Stage | Skill | Agents involved |
|---|---|---|
| Plan | creating-implementation-plans writes the plan file and the verification document | none |
| Implement | orchestrating-feature-implementation runs the plan from the main conversation | software-engineer, ui-engineer |
| Verify UI | reviewing-ui runs one capture-and-judge pass, repeated by the gate in the orchestrator | ui-capture-worker, ui-reviewer |
| Final verification | the orchestrator's final phase | code-reviewer and feature-verifier, in parallel |
| Fix a bug | debugging-code | loaded by software-engineer |
For the end-to-end flows see feature implementation, UI verification and debugging.
Prerequisites
- Playwright CLI. All browser evidence in this plugin runs on Playwright CLI: the UI verification gate's capture,
ui-engineer's standalone screenshot checks andfeature-verifier's browser walkthroughs. Before the first capture, the workflow runsplaywright-cli --version(with annpxfallback) and, when neither answers, asks whether to install it for you or wait while you do it yourself. The install command isnpm install -g @playwright/cli@latest. - Figma MCP server, bundled by
tsh-core. Design fetching needs the Figma MCP server. This plugin deliberately does not ship a second copy. Installtsh-corealongside it and run/mcponce to authenticate; every call then runs under your own Figma account. Until that sign-in happens, agents stop and report what is missing rather than guessing at a design, andui-reviewerreportsVERIFICATION NOT RUN. This applies to the judgment side only: capture needs no design reference, and a UI task with no design at all is implemented from the plan and never enters the gate. - A running app and its exact dev server URL, for UI work. The workflow asks you to confirm the URL once and pins it for the whole loop.
When the page under verification needs a login, capture reuses whatever the project already has: a documented auth recipe, an existing E2E setup, existing .env variables that match the login form, or a seeded development account. Only when none of those exists does the flow derive TSH_UI_LOGIN_* variable names and ask you to add them to .env. Nothing is bypassed, and credentials never travel through the chat.
MCP servers and hooks
This plugin ships no .mcp.json and no hooks. It bundled the Playwright MCP server through version 0.6.0 and replaced it with Playwright CLI, so that only file paths and measured values enter model context. Figma and Atlassian access come from tsh-core. The Jira and Confluence access is bundled there because every discipline reads from Jira, not just this one; authenticate once with /mcp.
Not covered by this plugin
E2E test suites belong to tsh-product-testing, infrastructure and CI to tsh-platform-engineering, and discovery and business-analysis work to tsh-product-management. Git worktree lifecycle lives in tsh-core. Deeper analysis skills such as codebase analysis and gap analysis are candidates for a later wave, according to the plugin README.