@gallopsystems/agent-skills 1.22.0 → 1.24.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gallopsystems/agent-skills",
-  "version": "1.22.0",
+  "version": "1.24.0",
   "description": "Gallop Systems agent skills, symlinked into .claude/skills (Claude Code) and .agents/skills (Codex) on install.",
   "license": "UNLICENSED",
   "repository": {

package/plugins/copier-template/skills/copier-template/SKILL.md

@@ -30,7 +30,34 @@ When working in a descendant and a fix belongs in the template too: fix the symp
 
 ## Releasing a Template Version
 
-After merging to the template's main:
+First determine **how the template releases** — it changes everything below:
+
+```bash
+ls release-please-config.json .release-please-manifest.json 2>/dev/null   # present ⇒ release-please
+```
+
+### If the template uses release-please (e.g. nuxt-copier-template)
+
+**You never `git tag` by hand.** Merging to `main` runs release-please, which opens a "release PR"; merging *that* cuts the tag + GitHub Release. The **Conventional-Commits type of your merged PR governs the entire outcome** — both the version bump and whether a release happens at all:
+
+- `feat:` → **minor** bump. `fix:` → **patch**. `feat!:` / `BREAKING CHANGE:` → **major**.
+- `chore:`, `docs:`, `refactor:`, `style:`, `test:`, `ci:`, `build:` → **no version bump, no release**. The change lands on `main` but sits in the (often hidden) "Miscellaneous" changelog bucket, **invisible to descendants**, until some later `feat`/`fix` rides out and drags it along.
+
+**The trap:** a template change that *should* propagate — a new alias/convention, a raised dependency floor, anything descendants must adopt — is a `feat` (or `fix`), **not** a `chore`. Type it `chore` and it silently never releases; descendants track git *tags*, so no tag = no `copier update` PR. When in doubt about whether descendants need it, it's a `feat`.
+
+**If you already merged it as the wrong type** (non-releasing), don't wait — force a release with an empty commit carrying a `Release-As` footer, via a normal PR (squash-merge it):
+
+```bash
+git commit --allow-empty -m "chore: release template <X.Y.Z>
+
+<why this is being force-released>
+
+Release-As: <X.Y.Z>"
+```
+
+release-please honors `Release-As:` regardless of commit types and opens the release PR at that exact version. Note: **release PRs get no CI** (the meta-test workflow doesn't run on `release-please--branches--*`), so if branch protection requires a status check, the release PR stays `BLOCKED` under a normal merge and an admin/maintainer must merge it — that's the expected path for release PRs here, not a failure.
+
+### If the template has no release automation (manual tags)
 
 ```bash
 git checkout main && git pull --ff-only

package/plugins/linear/skills/linear/SKILL.md

@@ -205,6 +205,8 @@ The CLI resolves friendly names against `workspace.json`, so you rarely need raw
 >
 > **Required placement rule:** Never create an issue without both `--project` and `--milestone`. If the right project does not exist, create it first. If the project exists but the right milestone does not, create the milestone first. Do not leave issues unscoped or unmilestoned.
 >
+> **Never target a completed milestone.** New work never belongs in a milestone that is already done — it distorts the completed phase and hides the issue from the team's current view. Only place an issue in an **open** milestone. If no open milestone matches the issue, create a new one and use that; do not reopen or reuse a completed milestone.
+>
 > **Confirm decisions with the requester — don't punt them into the issue.** When the person asking you to create the issue is right there in the conversation, ask the open decisions (scope, mechanism, data source, ownership, who/where it should land) *before* writing the issue — e.g. via a structured question prompt — and bake the confirmed answers into the body. Do **not** write an "Open questions" section full of decisions you could have just asked, and do **not** use that manufactured uncertainty as a rationale to leave the issue in Backlog or unassigned. Only genuinely external unknowns (something that needs a meeting, a client, or a spike to resolve) belong as open questions; everything the requester can answer on the spot should already be a confirmed decision with the issue placed and assigned accordingly.
 
 ```bash
@@ -672,7 +674,7 @@ Initiative: Northwind
 1. **Every issue must be placed into a cycle with Todo status.** **Do NOT default to the current/active cycle.** Follow this procedure: (a) Run `cycle-capacity` to see each cycle's capacity % (velocity-based, from last 3 completed cycles). (b) Starting from the earliest (current) cycle, find the first cycle that is **strictly under 100%** capacity. (c) If the current cycle is at or above 100%, **skip it** and use the next cycle with room. Assign the issue there via `--cycle`. **Always set `--state todo`** — issues in Backlog don't work with cycles. **Exception:** High priority or above (priority ≤ 2: Urgent, High) always go into the current active cycle regardless of capacity.
 2. **Every issue must belong to a project and a milestone.** Never create orphan issues and never leave an issue outside a milestone.
 3. **If the correct project does not exist, create it before creating the issue.** Do not park work in a generic team backlog while waiting to organize it later.
-4. **If the correct milestone does not exist, create it before creating the issue.** Milestone creation is part of issue intake, not optional cleanup.
+4. **If the correct milestone does not exist, create it before creating the issue.** Milestone creation is part of issue intake, not optional cleanup. **Never add an issue to a completed milestone** — only open milestones may receive new issues. If no open milestone matches the issue, create a new one; do not reuse a completed one.
 5. **Use milestones for sequencing.** Milestones can have target dates, making them useful for communicating delivery phases to clients.
 6. **Track progress in Linear.** After creating/updating projects or milestones, update the initiative's content in Linear to reflect the current structure (see "Post-Organization: Update Initiative in Linear" below).
 7. **When creating issues with the CLI**, use the `--project`, `--milestone`, and `--cycle` flags to place issues correctly in the hierarchy and cycle.