From 14f06432bfc7e328bdf3b54b5feb4097ed7241cc Mon Sep 17 00:00:00 2001 From: Vivek Date: Thu, 9 Jul 2026 12:47:43 +0530 Subject: [PATCH 1/2] chore: guard start-work skill to require an issue before coding Add a Precondition that routes untracked work (a conversational request, a review finding, an idea) through webjs-file-issue before any branch or code, and state the no-code-before-a-tracked-issue rule in when_to_use. Closes the gap where a feature shipped in a PR with no Closes #N and never appeared on the board. --- .claude/skills/webjs-start-work/SKILL.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/.claude/skills/webjs-start-work/SKILL.md b/.claude/skills/webjs-start-work/SKILL.md index 10d0fc42..17dc766e 100644 --- a/.claude/skills/webjs-start-work/SKILL.md +++ b/.claude/skills/webjs-start-work/SKILL.md @@ -10,12 +10,30 @@ when_to_use: | "let's start work on the rate-limit issue" "begin work on the next webjs todo" Do NOT trigger for: opening a PR for already-in-progress work, merging, asking what issues are open, or any non-webjs project. + ALSO invoke this (right after webjs-file-issue) before writing ANY code for + new work that has no issue yet, even when the user did not name an issue. The + standing rule is: no code before a tracked issue AND a branch cut from it. --- # Start work on a webjs GitHub issue The webjsdev/webjs project tracks work on the GitHub Project board at https://github.com/orgs/webjsdev/projects/1. This skill runs the start-of-work lifecycle whenever the user wants to begin a tracked issue. +## Precondition: the work MUST already have a tracked issue + +This skill picks up from an EXISTING issue. Before running any step below, confirm the task has one. It often does NOT: a task that arrives from a conversation, a code-review finding, a dogfood observation, or your own idea has no issue yet, and THAT is the gap this guards. + +**If there is no tracked issue for this work, STOP. Do not create a branch, do not write code.** First invoke `webjs-file-issue` to file it and capture the new number, THEN run this skill with that number. Starting code on untracked work is a process failure: the PR ships with no `Closes #N`, the work never appears on the board, and the card never moves to Done. This has happened (a whole feature was implemented and merged before any issue existed, then filed retroactively only after the user noticed). + +If you are unsure whether an issue already exists, search before filing: + +```sh +gh issue list --repo webjsdev/webjs --search "" --state all +gh project item-list 1 --owner webjsdev --format json --limit 20000 +``` + +When in doubt, file it. A duplicate is cheap to close; untracked work is the expensive failure. Only once an issue number exists do you continue to Inputs below. + ## Inputs The user's request typically names an issue by number (e.g. `#112`) or by description (e.g. "the dist issue"). Resolve the number first: From 80706dba7360680445b249eddcc2e569bbd073da Mon Sep 17 00:00:00 2001 From: Vivek Date: Thu, 9 Jul 2026 13:34:23 +0530 Subject: [PATCH 2/2] chore: warn against admin-merging past a failing check in start-work --- .claude/skills/webjs-start-work/SKILL.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.claude/skills/webjs-start-work/SKILL.md b/.claude/skills/webjs-start-work/SKILL.md index 17dc766e..0ec69873 100644 --- a/.claude/skills/webjs-start-work/SKILL.md +++ b/.claude/skills/webjs-start-work/SKILL.md @@ -360,6 +360,8 @@ If you cannot honestly say "last round clean", you cannot say "ready to merge". **Merge is gated on green CI, enforced at the branch level, not by trust.** A PR must not merge until all CI checks pass. `main` branch protection requires the five `ci.yml` checks (Conventions, Unit+integration, Browser, E2E, Build) before any merge; if `gh api repos/webjsdev/webjs/branches/main/protection` shows `required_status_checks: null`, run `bash scripts/protect-main.sh` once (needs repo admin) to restore it. Do not work around a red or pending check; wait for green. +**NEVER use `gh pr merge --admin` to bypass a FAILING check.** `--admin` skips ALL branch-protection gates, not only the review requirement, so a red CI check merges silently and lands broken code on `main`. This has happened (a Unit-test failure was admin-merged, breaking `main`). `--admin` is acceptable ONLY to bypass a required-review gate on a PR whose CI is confirmed all-green. Before any `--admin` merge, re-run `gh pr checks ` and confirm EVERY check reads `pass` (a `BLOCKED` state can mean review-required OR a failing check, so never assume which). If any check is red or pending, stop and fix or wait. + ### Subagent prompt template ```