"/ticket The Submit button overflows on mobile and the page crashes on tap on iPhone. Plan opus, execution sonnet, /senior-review in a loop, commit push if everything is ok"
The skill reads the ticket and the screen's CSS, has a plan written, then an e2e test that turns red on iPhone (WebKit, device profile) before any fix. The executor fixes it in TDD, the session reruns the gate, checks that reverting the fix turns the test red again, and reads the captures at the three sizes. When a /senior-review round changes nothing, it commits, pushes, and the MR leaves draft.
What it does
The main session orchestrates and verifies, two agents do the rest. A strong-model agent writes the plan from the ticket and the scope measured in the code. A red test is written before any line of code, at the highest level that catches the defect: an e2e scenario in the project's own harness when a screen is touched, with mobile, tablet and desktop captures taken with a device profile (touch, user agent, WebKit for the iPhone) rather than a plain resize. A standard-model agent executes in TDD. The session then reruns the gate itself, reverts the fix to watch the test turn red, restarts the app and reads every capture. Finally, /senior-review runs in a loop until the first round with no blocker that changes nothing.
When to use it
For a real ticket to ship: a bug, a small feature, a review finding. A trivial fix (a label, a one-line guard) takes a short path, with no plan and no executor. The launch sentence sets the roles ("plan opus, execution sonnet, /senior-review in a loop, commit push if everything is ok"), and the commit only happens if it allows it. Not for a large feature in an autonomous loop (feature-loop), nor for only creating the issue and branch (issue-mr), nor for closing already-written work (branch-wrap-up).
The stance: a ticket is done when its proof can be checked from the outside, not when "it looks like it works". The report separates three things: the code is right (tests red then green, reverse mutation), the effect is visible to the user, and the stage set (what really ran, what was simulated, what was not exercised). At the end, a retrospective proposes at most three rules drawn from your corrections, and nothing is written without your approval.
Install this skill
$ /plugin marketplace add ohugonnot/claude-skills
$ /plugin install ticket@web-developpeur-skills
Frequently asked questions
How is it different from /feature-loop?
/feature-loop launches a team of agents that loops until every axis hits 8/10, and costs accordingly: it only starts by hand. /ticket is lighter, with one agent for the plan, one for execution, and the main session doing the verification. It is the default path for an ordinary ticket.
Do I need the other skills installed?
No. /ticket calls issue-mr, senior-review and branch-wrap-up when they are there, and has a fallback otherwise (for example one fresh read-only reviewer per round instead of senior-review). They are built to work together, but none is required.
Why device-profile captures rather than resizing?
A shrunken viewport has neither the touch nor the user agent of a phone, so a page that adapts to the device shows up in a state that exists nowhere. A device profile reproduces the engine, and WebKit is added to Chromium when the screen targets the iPhone. What emulation cannot show (the iOS address bar, safe-area) is written in the MR as not verified.
Feedback & discussion · 0
No feedback yet. Tried it? Tell us what you think.