.agents/skills/iterate-pr/SKILL.md (§ "No PR check asks whether the OpenSpec change is archived", line ~284) predates openspec-label.yml / openspec-tracking.yml / openspec-sweep.yml and still says:
There is no gate for it, in either direction. … A replacement is a separate piece of design. … Nothing will fail either way.
That was true when the section was written and is now misleading in the one direction that matters. An agent following the skill on the tip PR of a stack reads "nothing will fail either way" as permission to defer archiving to "on landing", which cannot happen: main only takes PRs, so the change lands unarchived, openspec-tracking opens an issue, and a second PR is needed to close it. That is exactly what happened on taskless/marketing today (PRs #50 and #51 landed unarchived; #52 was the correction), with the skill's wording as the cause.
The section should describe the current signal and what to do with it:
openspec-label.yml labels every PR carrying an unarchived change Open OpenSpec, and on the tip of a stack posts a warning listing the exact pnpm openspec archive <change> lines.- On a tip PR, treat that warning as feedback to act on before merge: sync deltas into
openspec/specs/, archive, push. "Archive on landing" is not an option.
- On a non-tip PR, leave the change directory alone and let the label stand.
- Nothing fails; the label and the tracking issue are the channel.
The skill is consumed downstream via dotagents (source = "taskless/cli"), so it can only be fixed here; a local edit is clobbered on the next install.
.agents/skills/iterate-pr/SKILL.md(§ "No PR check asks whether the OpenSpec change is archived", line ~284) predatesopenspec-label.yml/openspec-tracking.yml/openspec-sweep.ymland still says:That was true when the section was written and is now misleading in the one direction that matters. An agent following the skill on the tip PR of a stack reads "nothing will fail either way" as permission to defer archiving to "on landing", which cannot happen:
mainonly takes PRs, so the change lands unarchived,openspec-trackingopens an issue, and a second PR is needed to close it. That is exactly what happened on taskless/marketing today (PRs #50 and #51 landed unarchived; #52 was the correction), with the skill's wording as the cause.The section should describe the current signal and what to do with it:
openspec-label.ymllabels every PR carrying an unarchived changeOpen OpenSpec, and on the tip of a stack posts a warning listing the exactpnpm openspec archive <change>lines.openspec/specs/, archive, push. "Archive on landing" is not an option.The skill is consumed downstream via dotagents (
source = "taskless/cli"), so it can only be fixed here; a local edit is clobbered on the next install.