Finish a bounded piece of work
My tech-lead skill deploys each finished PRD in dependency order. Migrations come before the backend and frontend that need them. That makes the release part of the job rather than a separate pile of completed changes waiting for someone to remember their relationships.
The acceptance criteria give me something concrete to check after release. A local result is useful, but the user meets the production version with real data. The skill treats done as having seen the work where the user will see it, with production details recorded in the PRD.
On withseismic.com the checks run locally because there is no CI. Types, tests and the build are checked before merging. But passing those gates does not replace the production check: they answer whether the work passes the checks, not whether that work reached the public site.
Know what the deploy actually uploads
This site is not connected to GitHub for deployment, so merging a change deploys nothing. Railway receives a folder through railway up. I name the folder explicitly when deploying from a worktree, so the upload contains the code I intend to release.
railway up <absolute worktree path> --path-as-root --service web-dossier --environment production --ciThat command is copied from this site’s CLAUDE.md and is specific to its Railway setup. The worktree form names the folder explicitly and includes --path-as-root. Every deploy uploads a folder, so identifying that folder is part of the release decision.
Agents do not push to git unless I say so, and deploys do not need a push. The important check is what the upload contains. A branch history records the committed code, but it cannot by itself tell me which folder the deployment command sent.
Check a string unique to the change
A deploy reporting SUCCESS is not enough. My tech-lead session fetches the live page and checks for a string that exists only in the new code. That distinguishes the intended release from an older page that still responds successfully at the same address.
For the offer pages, a script fetched each page and found all 153 strings. That check ties the deployed page to the copy it was meant to show. A successful request alone would only establish that the page answered, which is a much smaller claim.
The broader check still follows the work. The tech-lead skill uses endpoints, a real browser and read-only database queries with real production data. Choose evidence that reaches the behaviour in the PRD; a content check cannot by itself establish that an interaction or data change works.
Follow the work into live products
Vouchernaut’s rebuild repo started on 20 September 2026; Benson’s started on 24 September, with 169 commits on 25 September. These repos hold the product work alongside its plans, so I can keep moving from one agreed piece to the next with the decisions close to the code.
Bytky’s repo started on 12 October 2026 and held 81 PRDs by 18 October. Famoka’s started on 14 October and Godotoro’s on 15 October. All three are live. Keeping the plan in the repo, reusing skills and checking each release is how I keep several products moving.
withseismic.com had 50 commits on 18 October 2026. PRD 11’s plan was committed at 21:43, its implementation at 21:52 and its live check recorded at 21:56: commit times, so they show when work was committed. The plan, change and production check each leave a record.
The same day’s changelog had 22 top-level entries. Each describes what changed for a visitor. That is useful alongside the live evidence because it records the result of the release, rather than asking someone to infer the product change from a commit message.
Leave the result ready for a handover
My tech-lead session puts the production check and its details in the PRD’s Implementation Notes, updates the backlog status and records the visitor-facing change in CHANGELOG.md. Those records should agree. If the release stops at a seam, I leave the remaining work open in the backlog.
After a production fix, the session also explains what the issue was. A future session needs the cause and the verified result, not just a note saying it was fixed. The release is finished when the live work and its record give the next person something reliable to continue from.