@clipboard-health/ai-rules 2.21.1 → 2.22.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clipboard-health/ai-rules",
-  "version": "2.21.1",
+  "version": "2.22.0",
   "description": "Pre-built AI agent rules for consistent coding standards.",
   "keywords": [
     "ai",

package/skills/babysit-pr/SKILL.md

@@ -27,9 +27,9 @@ This skill always runs exactly one pass. It never waits or repeats internally. F
 
 The skill uses two sentinels. Each is a visible footer line wrapped in `<sub>` (a 🤖 mark plus the token in `<code>`).
 
-**Addressed sentinel**: `<sub>🤖 <code>babysit-pr:addressed v1 core@3.5.0</code></sub>`. Appended on its own line at the end of every reply the skill posts (both thread replies and the review-body summary); this is how re-runs know which threads and review-body comments are already handled. Dedupe matches the version-agnostic substring `babysit-pr:addressed v1` followed by a space (also matches legacy `<!-- babysit-pr:addressed v1 ... -->` sentinels). Grep `babysit-pr:addressed v1` for any version; add `core@3.5.0` for a specific one.
+**Addressed sentinel**: `<sub>🤖 <code>babysit-pr:addressed v1 core@3.6.0</code></sub>`. Appended on its own line at the end of every reply the skill posts (both thread replies and the review-body summary); this is how re-runs know which threads and review-body comments are already handled. Dedupe matches the version-agnostic substring `babysit-pr:addressed v1` followed by a space (also matches legacy `<!-- babysit-pr:addressed v1 ... -->` sentinels). Grep `babysit-pr:addressed v1` for any version; add `core@3.6.0` for a specific one.
 
-**Follow-up sentinel**: `<sub>🤖 <code>babysit-pr:followup v1 core@3.5.0</code></sub>`. Attached to replies that defer an out-of-scope comment as a tracked follow-up (see the Scope subsection and the Defer verdict in step 6). Grep `babysit-pr:followup` across PR conversation JSON to enumerate deferred items. This sentinel is additive — the post-reply scripts still append the `addressed` sentinel at the end, so a deferred thread is correctly machine-classified as addressed (the skill _has_ handled it — by deferring). Human reviewers and future sweeps distinguish deferred from resolved by looking for the follow-up sentinel.
+**Follow-up sentinel**: `<sub>🤖 <code>babysit-pr:followup v1 core@3.6.0</code></sub>`. Attached to replies that defer an out-of-scope comment as a tracked follow-up (see the Scope subsection and the Defer verdict in step 6). Grep `babysit-pr:followup` across PR conversation JSON to enumerate deferred items. This sentinel is additive — the post-reply scripts still append the `addressed` sentinel at the end, so a deferred thread is correctly machine-classified as addressed (the skill _has_ handled it — by deferring). Human reviewers and future sweeps distinguish deferred from resolved by looking for the follow-up sentinel.
 
 **Sentinel recency rules.** The script emits a per-thread `activityState` with three values:
 
@@ -280,7 +280,7 @@ Body templates (the script appends the `addressed` sentinel if missing):
 - **Agree**: `Addressed in <commit-url>. <one-line what-changed>.`
 - **Disagree**: `Leaving current behavior. <reasoning>.`
 - **Already fixed**: `Already handled by <commit-url-or-file:line>. <brief pointer>.`
-- **Defer**: `Out of scope for this PR; this looks like follow-up work rather than something introduced or required by this change. <one-line rationale or pointer if useful>.\n\n<sub>🤖 <code>babysit-pr:followup v1 core@3.5.0</code></sub>`
+- **Defer**: `Out of scope for this PR; this looks like follow-up work rather than something introduced or required by this change. <one-line rationale or pointer if useful>.\n\n<sub>🤖 <code>babysit-pr:followup v1 core@3.6.0</code></sub>`
 
 For Defer replies, include the follow-up sentinel on its own line as shown. The script will append the `addressed` sentinel after it on its own line, so the final body ends with the follow-up sentinel followed by a blank line followed by the `addressed` sentinel — `grep babysit-pr:followup` finds the deferral and `grep babysit-pr:addressed` still marks the thread handled for dedupe.
 
@@ -296,7 +296,7 @@ The PR-level summary should:
 
 - Group by source. Use `## Review-body findings` for step-7 work and `## Conversation-tab comments` for step-6b work. Omit a section if its list is empty.
 - Inside each section, group verdicts under **Agree / Disagree / Already fixed / Deferred (out of scope)** subheadings. Omit a subheading if its list is empty.
-- Under **Deferred (out of scope)**, list each deferred item as a bullet, followed on its own line by `<sub>🤖 <code>babysit-pr:followup v1 core@3.5.0</code></sub>` so grep catches them individually.
+- Under **Deferred (out of scope)**, list each deferred item as a bullet, followed on its own line by `<sub>🤖 <code>babysit-pr:followup v1 core@3.6.0</code></sub>` so grep catches them individually.
 - Include the commit URL for fixes.
 - End with a fenced fingerprint block listing every current fingerprint — addressed and deferred — one per line. Include both `reviewBodyComments[].fingerprint` (whole-body, one per automated review) and `activeIssueComments[].fingerprint` (per Conversation-tab comment). Future runs dedupe by matching these against `priorBabysitSentinels`.
 

package/skills/babysit-pr/scripts/_sentinel.sh

@@ -9,7 +9,7 @@
 # substituted at build time by embedPluginVersion.mts.
 
 SENTINEL_PREFIX='babysit-pr:addressed v1 '
-SENTINEL='<sub>🤖 <code>babysit-pr:addressed v1 core@3.5.0</code></sub>'
+SENTINEL='<sub>🤖 <code>babysit-pr:addressed v1 core@3.6.0</code></sub>'
 
 # Bot author allowlist (JSON array literal). Used by unresolvedPrComments.sh
 # as a fallback when GraphQL's `author.__typename == "Bot"` misses a GitHub

package/skills/commit-push-pr/SKILL.md

@@ -47,7 +47,7 @@ Script paths in this procedure are written as `scripts/...`, relative to this SK
 6. Check for an existing PR with `gh pr view`.
 
    PR title format: conventional-commit type + description, with no scope, plus the Linear ticket in parentheses at the end when one applies (e.g., `feat: add resume command (STAFF-123)`). This differs from the commit subject, which keeps its scope. Derive the ticket from the branch name, commit body, or session context; omit the parenthetical when no ticket applies.
-   - No PR: create with `gh pr create` using the PR title format above. Description = the PR body shape above, followed by the session footer line if known and the agent footer `<sub>🤖 <code>commit-push-pr:created v1 core@3.5.0</code></sub>` on its own line.
-   - PR exists: if the title doesn't match the format above, correct it with `gh pr edit --title`. Refresh the body via `gh pr edit --body` so (a) the new commit's changes are reflected in the prose while existing `## Summary`, `## Validation`, and `## Notes` sections are preserved unless clearly stale, (b) any known session footer line is appended if missing, never removing or rewriting existing `Agent session: ...` or `Agent session ID: ...` lines, and (c) any existing footer carrying the substring `commit-push-pr:created v1` is preserved verbatim, appending `<sub>🤖 <code>commit-push-pr:created v1 core@3.5.0</code></sub>` only if absent. Then report the URL.
+   - No PR: create with `gh pr create` using the PR title format above. Description = the PR body shape above, followed by the session footer line if known and the agent footer `<sub>🤖 <code>commit-push-pr:created v1 core@3.6.0</code></sub>` on its own line.
+   - PR exists: if the title doesn't match the format above, correct it with `gh pr edit --title`. Refresh the body via `gh pr edit --body` so (a) the new commit's changes are reflected in the prose while existing `## Summary`, `## Validation`, and `## Notes` sections are preserved unless clearly stale, (b) any known session footer line is appended if missing, never removing or rewriting existing `Agent session: ...` or `Agent session ID: ...` lines, and (c) any existing footer carrying the substring `commit-push-pr:created v1` is preserved verbatim, appending `<sub>🤖 <code>commit-push-pr:created v1 core@3.6.0</code></sub>` only if absent. Then report the URL.
 
 7. End with one short text response: branch name and the full PR URL (e.g., `https://github.com/clipboardhealth/core-utils/pull/123`). Never use shorthand like `repo#123` — always output the complete URL.

package/skills/create-groundcrew-ticket/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: create-groundcrew-ticket
+description: "Create Linear tickets that Groundcrew can pick up: assigned to the current Linear user, labeled with agent-*, tied to an implementation repository in the description, optionally linked to parent and blocker tickets, and written to use the core:go implementation workflow."
+---
+
+# Create Groundcrew Ticket
+
+Create Linear issues that are ready for Groundcrew dispatch. This skill is agent-agnostic: use the structured Linear capability available in the current agent, following that tool's current schema instead of hard-coding one here.
+
+## Eligibility Contract
+
+A Linear issue is Groundcrew-eligible when all of these are true:
+
+- It is assigned to the current Linear user. Use the active Linear tool's "current user" value, commonly `me`, when available.
+- It is in a Todo workflow state. Prefer the Linear state type for Todo when tooling accepts state types.
+- It has exactly one appropriate `agent-*` label. Use `agent-any` unless the user explicitly asks for a specific model such as `agent-codex` or `agent-claude`.
+- Its description contains the implementation repository text exactly as Groundcrew can match it, for example `Repository: groundcrew`.
+- It is a leaf work item. Do not put `agent-*` labels on parent tickets that have children; Groundcrew skips parents with sub-issues.
+- It is not blocked by non-terminal blockers if the user expects it to start immediately. If blockers are intentional, create `blocked-by` relations and tell the user Groundcrew will wait.
+
+Groundcrew resolves the repository by scanning the description for a known repository name. Do not rely on Linear custom fields for repository routing.
+
+## Required Inputs
+
+Before creating, know:
+
+- `title`
+- Linear `team`
+- implementation `repository`
+- enough task context to write a useful implementation ticket
+
+If any required input is missing and cannot be inferred safely, ask a concise question before creating.
+
+Repository inference:
+
+- If the user names a repository, use that exact value.
+- Otherwise infer from the current git remote or directory name.
+- Prefer a value present in `crew.config.ts` `workspace.knownRepositories` when this repo is available.
+- If multiple known repositories could match the same bare name, ask the user to choose.
+
+Optional metadata:
+
+- `parent`: parent Linear identifier, for example `ENG-123`
+- blocked-by relations: tickets this new ticket depends on
+- blocking relations: tickets this new ticket blocks
+
+## Description Template
+
+Use a direct implementation-shaped ticket. Keep the repository line near the top.
+
+```md
+## Groundcrew
+
+Repository: <repo>
+Implementation workflow: use the `core:go`/`go` skill when available. If that skill is unavailable, follow this repo's AGENTS.md/CLAUDE.md implementation workflow and run the documented verification.
+
+## Task
+
+<what to change>
+
+## Acceptance Criteria
+
+- [ ] <observable outcome>
+
+## Notes
+
+<links, constraints, parent/blocker context, or "None">
+```
+
+Keep the ticket agent-agnostic. Do not mention Codex-only commands unless the user explicitly requested a Codex-specific ticket.
+
+## Creation Path
+
+Use the current agent's structured Linear issue tool. Tool names and exact field names vary, so inspect the active tool schema/help and map these intents to the available fields:
+
+- Set the `title`.
+- Assign it to the current Linear user.
+- Set its state to Todo.
+- Apply the chosen `agent-*` label.
+- Put the generated Markdown body in the issue description.
+- Set the parent issue when the user provided one.
+- Add dependency relations for blockers and blocked tickets.
+- Apply optional project, cycle, milestone, priority, estimate, and due date metadata only when requested or clearly inferable.
+
+Rules:
+
+- Use a blocked-by relation for "this work is blocked by X".
+- Use a blocking relation only when the user says the new ticket blocks another ticket.
+- If the tool cannot create relations during creation, create the issue first, then update it to add the parent and dependency relations.
+- If creating a parent and child tickets, create the parent without an `agent-*` label, then create labeled child tickets under that parent.
+
+## Verification
+
+After creation:
+
+- Confirm the resulting issue identifier and URL.
+- Check that the issue has the intended assignee, state, `agent-*` label, repository line, parent, and relations.
+- If this Groundcrew repo or `crew` CLI is available, run `node --run crew -- status <ISSUE>` and report whether Groundcrew sees the ticket as ready for dispatch or why it will wait.
+
+Do not claim the ticket is eligible if verification fails. Report the missing field or blocking condition plainly.