workflow-e2e-author
Skill0 starsChanged 5 months agoMITView on GitHub
Author Playwright E2E specs for the named E2E task ids on a slice branch. Read the slice body, locate the task block(s) in the `## Tasks` checklist, set up the slice worktree, translate the mapped Gherkin scenarios into specs, tick the authored tasks' checkboxes, commit with `Refs #<slice#>` + `Task: <id>` trailers, push, post a summary comment. Activate when dispatched with `Author E2E for slice #<n> tasks <ids>`, or on '/workflow-e2e-author'.
In this repository74 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- create-bug-issueSkill
- create-enhancement-issueSkill
- create-feature-issuesSkill
- dream-summary-memorySkill
- memory-conventionSkill
- operation-gitSkill
- pattern-architect-api-endpointSkill
- pattern-architect-data-modelSkill
- pattern-architect-deep-moduleSkill
- pattern-e2e-coding-standardSkill
- pattern-engineer-apiSkill
- pattern-engineer-backend-standardSkill
- pattern-engineer-coding-standardSkill
- pattern-engineer-containerSkill
- pattern-engineer-databaseSkill
- pattern-engineer-fastapiSkill
- pattern-engineer-frontend-standardSkill
- pattern-engineer-goSkill
- pattern-engineer-javaSkill
- pattern-engineer-kotlinSkill
- pattern-engineer-nodeSkill
- pattern-engineer-non-functionalSkill
- pattern-engineer-observabilitySkill
- pattern-engineer-pythonSkill
- pattern-engineer-rustSkill
- pattern-engineer-securitySkill
- pattern-engineer-ssrSkill
- pattern-engineer-swiftSkill
- pattern-engineer-typescriptSkill
- pattern-engineer-viteSkill
- pattern-exploratory-testingSkill
- pattern-reviewer-apiSkill
- pattern-reviewer-backend-standardSkill
- pattern-reviewer-coding-standardSkill
- pattern-reviewer-containerSkill
- pattern-reviewer-contractSkill
- pattern-reviewer-databaseSkill
- pattern-reviewer-fastapiSkill
- pattern-reviewer-frontend-standardSkill
- pattern-reviewer-goSkill
- pattern-reviewer-javaSkill
- pattern-reviewer-kotlinSkill
- pattern-reviewer-nodeSkill
- pattern-reviewer-non-functionalSkill
- pattern-reviewer-observabilitySkill
- pattern-reviewer-pythonSkill
- pattern-reviewer-rustSkill
- pattern-reviewer-securitySkill
- pattern-reviewer-ssrSkill
- pattern-reviewer-swiftSkill
- pattern-reviewer-test-coverageSkill
- pattern-reviewer-typescriptSkill
- pattern-reviewer-viteSkill
- pattern-test-coverageSkill
- principle-engineer-tddSkill
- scaffold-projectSkill
- workflow-architect-interviewSkill
- workflow-designer-sample-pagesSkill
- workflow-design-interviewSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Do NOT activate to address coverage-gate findings on a slice (use workflow-e2e-fix), or to write production code (engineer's lane).
- Very specific: line 36
Create-or-reuse the slice-scoped worktree on that branch (do not integrate origin/main — authoring happens on the slice branch as-is.
- Very specific: line 37
Before authoring, check the slice branch for prior Refs #<slice#> WIP commits — a killed earlier run may have already landed specs for some …
- Distinctive: line 54
Use the project's Conventional Commits format.
- Distinctive: line 71
E2E specs run against the full stack and start from the UI: Never call backend HTTP endpoints directly from a spec's assertions.
- Distinctive: line 79
Truth is in Git, the checklist, and the comment: No structured summaries returned to the caller — the push, the ticked boxes, and the …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
workflow-e2e-author
Translate the named e2e tasks on a slice into Playwright specs. Dispatched with a (slice #, task ids) pair — the agent reads the slice body's ## Tasks checklist for the named ids, the slice branch, the worktree path, and the slice's Acceptance criteria.
The agent loads its own pattern set (E2E conventions, semantic selectors, fixture isolation, etc.) at kickoff. This skill owns only the workflow: read → worktree → write → tick → commit → push → comment.
When to activate
Activate this skill whenever:
- The dispatch prompt opens with
Author E2E for slice #<n> tasks <ids>. - The user types
/workflow-e2e-author, or phrases like "author the E2E specs for slice #<n>tasks e2e.1,e2e.2".
Do NOT activate to address coverage-gate findings on a slice (use workflow-e2e-fix), or to write production code (engineer's lane).
Input contract
Read the slice issue #<n> body. Locate the task block(s) for <ids> in the ## Tasks checklist (each entry is a header [ ] \<id>` · <type> · blocked-by <ids|—>, the delivery on the next line, a metadata line tagging covers:(AC clause ids) + the realized critical-path Journey step /entry-source:/done:, then scenario:and a fenced ```gherkin block of named Scenarios to walk). The checklist is the durable task ledger — a box already checked[x]means that task is DONE; skip it (resume safety). Read the slice's Acceptance criteria (EARS) plus the e2e task's ownscenario:` Gherkin for behavior; follow the pointer for the unit spec. An e2e task exists only because the slice closes a cross-surface journey segment — assert user-visible state through the UI, never a backend internal (those are proven at the backend layer).
Workflow
Input from the caller: the slice # and the task ids. Discover everything else.
1. Read the slice body and locate the named tasks
Fetch the slice issue (number, title, body, labels, url) via bash skills/operation-git/scripts/issue-body.sh <n> — skips comment chrome. Parse the ## Tasks checklist; locate each id in <ids>. Drop any already checked [x] (resume safety). If every named id is already [x], exit cleanly — nothing to author. Confirm each remaining id is **e2e**; a non-e2e id is a routing bug → halt and surface.
2. Resolve the slice branch and set up the worktree
- Resolve the slice's attached branch (
gh issue develop <n> --list, orresolve-slice-branch.sh). - Create-or-reuse the slice-scoped worktree on that branch (do not integrate
origin/main— authoring happens on the slice branch as-is; main is integrated once, later, at the Pass-E2E phase viaworkflow-engineer-diagnose-e2e). - Before authoring, check the slice branch for prior
Refs #<slice#>WIP commits — a killed earlier run may have already landed specs for some named ids; reconcile against the checklist ([x]= done) and resume from the first un-authored task. cdinto the worktree path.
3. Author / extend Playwright specs from the slice AC
For each named e2e task, translate its own scenario: Gherkin block (the task carries the Given/When/Then it walks; covers: names the AC clause it discharges) into a Playwright spec inside the worktree — plus the pattern-mandated non-happy-paths (pattern-test-coverage). The agent's loaded pattern set owns the conventions (semantic selectors, fixture identity, extend-vs-fragment, what to assert). Read the slice's Acceptance criteria (EARS) plus the task's scenario: Gherkin for the behavior under test.
While authoring, lock each behavioral outcome state the spec asserts in the surface's docs/ui-contract/<screen>.yaml (per pattern-e2e-coding-standard): if the asserted toast / banner / redirect has no states entry yet, add it — naming the queryable proof — in the same worktree, and include the contract edit in the task's commit. The engineer renders to that locked entry; do NOT touch the skeleton (regions/actions — design-lead's lane; a skeleton gap is a halt, not an edit).
Smoke-run touched specs (npx playwright test <files>) and confirm each spec reaches a real assertion. Parse / load / locator-API errors → fix and re-run. Assertion failures (production code missing) → expected; don't patch production code.
4. Tick the authored tasks' checkboxes
For each id whose specs are authored and smoke-clean, flip its checklist box [ ] → [x] in the slice body (edit the slice body via gh issue edit <n> --body-file, or the operation-git helper). The checklist is the durable task ledger — ticking it is what lets a fresh dispatch skip the done task on resume.
5. Commit with Refs + Task trailers
Use the project's Conventional Commits format. Every commit body MUST end with:
Refs #<slice#>
Task: <static-id><static-id> is the checklist id the commit advances (e.g. Task: e2e.1). Commits land directly on the slice branch inside the worktree. Never use Closes.
6. Push and post a summary comment
Push the slice branch to origin, then post a comment on the slice issue summarizing what was authored (spec files, the task ids covered, the scenarios walked) via bash skills/operation-git/scripts/post-comment.sh <n> <file>.
Terminal action. Exit. Do NOT flip any label (the calling workflow owns gating). Do NOT close the slice, do NOT open a PR, do NOT message reviewers.
Iron rules
- E2E specs run against the full stack and start from the UI. Never call backend HTTP endpoints directly from a spec's assertions.
- Every commit carries
Refs #<slice#>+Task: <id>. TheTask:trailer is the commit→checklist mapping the recovery story relies on. - Tick the box you authored. The checklist is the durable ledger; an authored-but-unticked task looks un-done to the next dispatch.
- Scope strictly to the named task ids and their mapped scenarios. Anything outside the slice AC / the named tasks'
covers:pointers is out of scope. - Red is expected; broken is not. A test that fails on a missing implementation is correct output. A test that fails to load / parse / locate is not.
- Never patch production code from this lane. Production fixes are engineer's lane.
- Resume from the checklist + WIP commits. On a fresh dispatch, skip already-
[x]tasks and pick up from the first unchecked one; reconcile against priorRefs #<slice#>commits on the branch. - Bail with
status:need-attentionon unrecoverable blockers (slice branch missing, unfixable smoke-run parse error). Post a diagnostic comment before flipping the label. - Truth is in Git, the checklist, and the comment. No structured summaries returned to the caller — the push, the ticked boxes, and the summary comment are the outputs.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

