englishstreetventures.com

Use when this repository's Cloudflare Worker misbehaves or fails to deploy, or when setting or rotating a Worker secret. Covers where to look first, the secret-setting trap for JSON and JWK values, why a secret change needs a redeploy, and the module-evaluation crash on a first deploy.

Start a feature or fix in the English Street Ventures website repository. Clarify the observable result, inspect the Astro and Cloudflare setup, plan the files and verification, then implement on the current task branch.

Use when driving one or more tasks end to end from the local bare repo's `main` worktree — a feature designed with the user first when its scope is open, or a ready list of tasks — ordering them, cutting a worktree per task, handing each to a subagent that runs new-feat, running prep-pr with every finding fixed rather than reported, and shepherding each pull request to a squash merge and worktree teardown. Not for a one-file change, and not outside the bare repo.

Use when preparing the current branch for a pull request — resolving the base branch, checking changesets, running builds and reviews, filing findings as issues, and opening the PR with the mandatory five-section body.

Use when an issue needs its complexity declared — proposing a rating from the issue body alone and getting the owner to confirm or amend it, or backfilling a rating onto an existing unrated issue. Invoked by new-feat at issue-creation time; also the backfill path for issues opened before the label existed.

Use when running the retrospective on a piece of work that has just finished — the retro, normally the step straight after `prep-pr` opens the pull request — to write and commit the session-metrics card for the branch, read what the session actually cost against the difficulty declared before it started, and turn that into concrete changes to the skills, `AGENTS.md`, the wiki, the tests or the brief. Also the owner of the card — nothing else writes one carrying the pull request's identity.

Use when auditing the monorepo's dependencies — every workspace package.json — for version drift between workspaces and for upgrades available on npm. Finds the packages whose declared ranges disagree, checks the registry for newer versions, classifies each upgrade against the waiting-period rules, reads the changelogs of the ready ones, and reports the package.json changes to make.

Use when reviewing the documentation a branch changes — AGENTS.md, READMEs and pages under wiki/ — or sweeping the whole wiki with --full. Cross-checks every claim a page makes against the code, finds wikilinks and heading anchors the branch broke, checks frontmatter and page shape, and reports D-C/H/M/L findings in the four-field format.

Use when reviewing a branch diff for performance defects — redundant database round trips, N+1 queries, unbounded reads, per-request layer rebuilds, wasted client fetches, and build steps that ship a broken artefact — and reporting findings with P-C/W/I IDs in the four-field format.

Use when reviewing a branch diff for security concerns — auth, tokens and sessions, injection, secrets, cookies, CSP and third-party content — and reporting findings with S-C/H/M/L IDs in the four-field format.

Use when checking whether a branch is adequately tested — building and running the affected workspaces, then auditing changed code for missing test files, untested exports, untested error paths and untested routes — and reporting gaps with T-M/U/E/R/S IDs in the four-field format.

Use when an implementation plan has just been written and before any code is written — hands the plan to a second model in a fresh context to attack it, then requires every finding to be closed or rejected in writing. Invoked by new-feat at the end of its planning step and by orchestrate once per phase, and worth running on its own for any plan whose assumptions have not been checked against the code.