From 9460505efdc66e134a5bb990906a8490124ac0f7 Mon Sep 17 00:00:00 2001 From: tend-agent <270458913+tend-agent@users.noreply.github.com> Date: Sat, 8 Aug 2026 13:15:09 +0000 Subject: [PATCH 1/2] fix(running-in-ci): read a recipe before running it, and never extract one by position Verifying a skill's own recipe runs it against the live repo, and those recipes write. Add the missing guard to the 'verify by running the code' instruction: read the block first, match it by prose rather than by fence ordinal, run the read half, and point a write at a scratch object. --- plugins/tend-ci-runner/skills/running-in-ci/SKILL.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md b/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md index 32dc8c98..c17e1154 100644 --- a/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md +++ b/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md @@ -618,6 +618,15 @@ Two paths, in order of preference: If both paths fail (GUI-only tool, private repo, environment-specific behavior), cite what you found, name the remaining gap honestly, and follow **Who to ask when you can't do it yourself** below — don't hand the verification to an outside party, least of all an upstream maintainer reviewing your change. +**Path 1 runs against the live repo.** Verifying a skill's own recipe is the common case, and those recipes write: `gh issue close`, `gh pr comment`, `git push`. Read a block before running it, and never select one by position — `awk` on the Nth fence, `sed` on a line range — because the ordinal moves with every edit to the file, so the block that runs is not the one you meant to test. Match on the surrounding prose or the command instead. Run the read half and stop before the pipe into the write: + +```bash +gh issue list --state open --author '@me' --search '"..." in:title' --json number --jq '.[].number' +# ...and read that, rather than piping it into `xargs gh issue close`. +``` + +If the write is the part in question, point it at a scratch object you own. A wrong write is only partly recoverable: reopening an issue leaves the close in its timeline, and a deleted comment has already fired its `issue_comment` event, so any workflow it triggered ran and is still in the run list. + From bf73b02ef935e8840784641b35f4353e7eabb44d Mon Sep 17 00:00:00 2001 From: tend-agent <270458913+tend-agent@users.noreply.github.com> Date: Sat, 8 Aug 2026 13:23:11 +0000 Subject: [PATCH 2/2] fix(running-in-ci): never extract a block to run it; move the guard after the example --- .../skills/running-in-ci/SKILL.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md b/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md index c17e1154..97ba2048 100644 --- a/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md +++ b/plugins/tend-ci-runner/skills/running-in-ci/SKILL.md @@ -618,15 +618,6 @@ Two paths, in order of preference: If both paths fail (GUI-only tool, private repo, environment-specific behavior), cite what you found, name the remaining gap honestly, and follow **Who to ask when you can't do it yourself** below — don't hand the verification to an outside party, least of all an upstream maintainer reviewing your change. -**Path 1 runs against the live repo.** Verifying a skill's own recipe is the common case, and those recipes write: `gh issue close`, `gh pr comment`, `git push`. Read a block before running it, and never select one by position — `awk` on the Nth fence, `sed` on a line range — because the ordinal moves with every edit to the file, so the block that runs is not the one you meant to test. Match on the surrounding prose or the command instead. Run the read half and stop before the pipe into the write: - -```bash -gh issue list --state open --author '@me' --search '"..." in:title' --json number --jq '.[].number' -# ...and read that, rather than piping it into `xargs gh issue close`. -``` - -If the write is the part in question, point it at a scratch object you own. A wrong write is only partly recoverable: reopening an issue leaves the close in its timeline, and a deleted comment has already fired its `issue_comment` event, so any workflow it triggered ran and is still in the run list. - @@ -640,6 +631,15 @@ Good: Same question. Cloned cmux's source repo → grepped the CLI parser for `l +**Path 1 runs against the live repo.** Verifying a skill's own recipe is the common case, and those recipes write: `gh issue close`, `gh pr comment`, `git push`. Never extract a block programmatically to run it — not by position (`awk` on the Nth fence, `sed` on a line range), and not by anchor either: both hand you a block you haven't read, and the ordinal additionally moves with every edit to the file, so what runs isn't even the block you meant to test. Read the file, then run the commands directly. Run the read half and stop before the pipe into the write: + +```bash +gh issue list --state open --author '@me' --search '"..." in:title' --json number --jq '.[].number' +# ...and read that, rather than piping it into `xargs gh issue close`. +``` + +If the write is the part in question, point it at a scratch object you own. A wrong write is only partly recoverable: reopening an issue leaves the close in its timeline, and a deleted comment has already fired its `issue_comment` event, so any workflow it triggered ran and is still in the run list. + ### Who to ask when you can't do it yourself Some checks need hardware or an environment CI doesn't have (Windows, a GPU, a physical terminal). When you can't complete or verify something directly, escalate in this order and stop at the first rung that works: