From c270fba1ab41b7db5582e88dfba471b5604ab0d7 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sun, 12 Apr 2026 13:12:26 -0400 Subject: [PATCH 1/7] Add SECURITY.md, fix workflow permissions, and redesign README header Add a lightweight security policy, restrict GITHUB_TOKEN permissions to contents:read in both CI workflows to resolve CodeQL warnings, and restructure the README with a centered header/tagline/badge layout. --- .github/workflows/sync-check.yml | 2 ++ .github/workflows/test.yml | 2 ++ README.md | 29 ++++++++++++++++++++++------- SECURITY.md | 24 ++++++++++++++++++++++++ 4 files changed, 50 insertions(+), 7 deletions(-) create mode 100644 SECURITY.md diff --git a/.github/workflows/sync-check.yml b/.github/workflows/sync-check.yml index 9eebc17..cdfe9a4 100644 --- a/.github/workflows/sync-check.yml +++ b/.github/workflows/sync-check.yml @@ -1,5 +1,7 @@ name: Sync check on: [push, pull_request] +permissions: + contents: read jobs: sync-check: runs-on: ubuntu-latest diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 63174e3..fc33538 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -1,5 +1,7 @@ name: Tests on: [push, pull_request] +permissions: + contents: read jobs: test: runs-on: ubuntu-latest diff --git a/README.md b/README.md index d1009bb..04647e1 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,25 @@ -![Code Cannon](.github/assets/readme-header.png) - -[![CI](https://github.com/LightbridgeLab/CodeCannon/actions/workflows/sync-check.yml/badge.svg)](https://github.com/LightbridgeLab/CodeCannon/actions/workflows/sync-check.yml) [![Tests](https://github.com/LightbridgeLab/CodeCannon/actions/workflows/test.yml/badge.svg)](https://github.com/LightbridgeLab/CodeCannon/actions/workflows/test.yml) [![codecov](https://codecov.io/gh/LightbridgeLab/CodeCannon/branch/main/graph/badge.svg)](https://codecov.io/gh/LightbridgeLab/CodeCannon) [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE) [![GitHub release](https://img.shields.io/github/v/release/LightbridgeLab/CodeCannon)](https://github.com/LightbridgeLab/CodeCannon/releases) [![Last Commit](https://img.shields.io/github/last-commit/LightbridgeLab/CodeCannon)](https://github.com/LightbridgeLab/CodeCannon/commits) [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg)](docs/contributing.md) [![Python](https://img.shields.io/badge/Python-3.x-blue?logo=python&logoColor=white)](sync.py) [![Install](https://img.shields.io/badge/install-git%20submodule-blue?logo=git&logoColor=white)](https://github.com/LightbridgeLab/CodeCannon#quick-start) - -# Code Cannon - -Write your team's AI agent workflow once — start, submit-for-review, review, deploy — and sync it to Claude Code, Cursor, Gemini, and Codex across all your projects. +

Code Cannon

+

+ Write your AI agent workflow once. Sync it everywhere. +

+

+ Portable skills for Claude Code, Cursor, Gemini, and Codex — start, review, deploy — across all your projects. +

+

+ CI + Tests + codecov + License: MIT + GitHub release + Last Commit + PRs Welcome + Python + Install +

+ +

+ Code Cannon +

## The problem diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..859045e --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,24 @@ +# Security Policy + +## Supported Versions + +| Version | Supported | +|---------|--------------------| +| Latest | :white_check_mark: | +| Older | :x: | + +Only the latest release receives security fixes. We recommend always using the most recent version. + +## Reporting a Vulnerability + +Code Cannon is a developer tool that generates static configuration files. It does not run a server, handle user credentials, or process sensitive data. The attack surface is limited to the sync script and generated output. + +If you discover a security issue, please **open a GitHub Issue** in this repository with the label `security`. Include: + +- A description of the vulnerability +- Steps to reproduce +- The potential impact + +We will acknowledge the report within 7 days and aim to provide a fix or mitigation within 30 days, depending on severity. + +For issues that could enable supply-chain attacks (e.g., generating malicious output files), please email the maintainers directly rather than opening a public issue. Contact information is available in the repository's GitHub profile. From 85a31fe53c51fab5b85e4107785795cbdea43984 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sun, 12 Apr 2026 14:26:42 -0400 Subject: [PATCH 2/7] Add make roll-call target for voluntary installation telemetry via GitHub Discussions --- Makefile | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 92b5e98..6aa9403 100644 --- a/Makefile +++ b/Makefile @@ -7,7 +7,7 @@ INTEGRATION_BRANCH = dev include Makefile.agents.mk .DEFAULT_GOAL := help -.PHONY: help check dev sync test bump-patch bump-minor bump-major set-version deploy-preview deploy-prod +.PHONY: help check dev sync test bump-patch bump-minor bump-major set-version deploy-preview deploy-prod roll-call help: @echo "Usage: make " @@ -33,6 +33,9 @@ help: @echo "Deployment" @echo " deploy-preview Push $(INTEGRATION_BRANCH) for preview/testing" @echo " deploy-prod Push $(PRODUCTION_BRANCH) with tags" + @echo "" + @echo "Community" + @echo " roll-call Say hello — let us know you're using CodeCannon" # Validate that all skill placeholders resolve against the config. check: @@ -106,3 +109,51 @@ deploy-prod: git pull --rebase origin $(PRODUCTION_BRANCH) git fetch origin --tags --force git push origin $(PRODUCTION_BRANCH) --tags + +# ── Community ─────────────────────────────────────────────────────────────── + +# Discussion node ID for the Roll Call registry (LightbridgeLab/CodeCannon #133). +ROLL_CALL_DISCUSSION_ID := D_kwDORls6r84Alpjt + +# Post a voluntary check-in to the CodeCannon Installation Registry discussion. +roll-call: + @# ── Preflight: gh must be installed and authenticated ── + @command -v gh >/dev/null 2>&1 || { echo "Error: gh CLI is not installed. See https://cli.github.com"; exit 1; } + @gh auth status >/dev/null 2>&1 || { echo "Error: not authenticated. Run 'gh auth login' first."; exit 1; } + @# ── Gather metadata ── + @repo=$$(gh repo view --json nameWithOwner -q '.nameWithOwner' 2>/dev/null || echo "unknown"); \ + if [ -f CodeCannon/VERSION ]; then \ + version=$$(cat CodeCannon/VERSION); \ + elif [ -f VERSION ]; then \ + version=$$(cat VERSION); \ + else \ + version="unknown"; \ + fi; \ + if [ -f .codecannon.yaml ]; then \ + adapters=$$(grep -E '^\s*-\s+' .codecannon.yaml | grep -io 'claude\|cursor\|gemini\|codex' | sort -u | paste -sd ', ' -); \ + fi; \ + adapters=$${adapters:-none detected}; \ + date=$$(date +%Y-%m-%d); \ + body="📡 **$$repo** — v$$version — adapters: $$adapters — $$date"; \ + echo ""; \ + echo " Roll Call — CodeCannon Installation Registry"; \ + echo " ─────────────────────────────────────────────"; \ + echo " Repo: $$repo"; \ + echo " Version: v$$version"; \ + echo " Adapters: $$adapters"; \ + echo " Date: $$date"; \ + echo ""; \ + echo " This will post a comment to the public CodeCannon discussion:"; \ + echo " https://github.com/LightbridgeLab/CodeCannon/discussions/133"; \ + echo ""; \ + echo " Your GitHub username and repo name will be visible."; \ + echo ""; \ + printf " Continue? [y/N] "; \ + read -r confirm; \ + case "$$confirm" in \ + [yY]|[yY][eE][sS]) ;; \ + *) echo " Cancelled."; exit 0;; \ + esac; \ + gh api graphql -f query="mutation { addDiscussionComment(input: {discussionId: \"$(ROLL_CALL_DISCUSSION_ID)\", body: \"$$body\"}) { comment { url } } }" --jq '.data.addDiscussionComment.comment.url' \ + && echo "" && echo " 🎉 Thanks for checking in! You're helping make CodeCannon better." \ + || { echo ""; echo " Error: failed to post. Check your gh permissions and try again."; exit 1; } From 51067ebab7f7500a7a8cd28d6fbabff7c87ecf64 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sun, 12 Apr 2026 14:42:31 -0400 Subject: [PATCH 3/7] Guard make targets with existence check and cd to repo root before running --- .agents/skills/submit-for-review/SKILL.md | 34 +++++++++++++++++++++-- .claude/commands/submit-for-review.md | 34 +++++++++++++++++++++-- .cursor/rules/submit-for-review.mdc | 34 +++++++++++++++++++++-- .gemini/skills/submit-for-review/SKILL.md | 34 +++++++++++++++++++++-- skills/submit-for-review.md | 32 ++++++++++++++++++++- 5 files changed, 159 insertions(+), 9 deletions(-) diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index f031964..b7b281e 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -32,7 +32,25 @@ If the current branch matches any of the above, **abort immediately** and say: ## Step 2 — Type-check gate -Run: +First, move to the repository root so the command resolves against the correct Makefile / project config: + +``` +cd "$(git rev-parse --show-toplevel)" +``` + +Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: + +``` +make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command. Do not proceed. + +If the target exists, run: ``` make check ``` @@ -171,6 +189,18 @@ Wait for the review to complete and report its verdict. ## Step 8 — Act on verdict +Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: + +``` +cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed. + Merge command (used by all paths below): `make merge` --- @@ -325,4 +355,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index cb9f0ce..82a6a32 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -27,7 +27,25 @@ If the current branch matches any of the above, **abort immediately** and say: ## Step 2 — Type-check gate -Run: +First, move to the repository root so the command resolves against the correct Makefile / project config: + +``` +cd "$(git rev-parse --show-toplevel)" +``` + +Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: + +``` +make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command. Do not proceed. + +If the target exists, run: ``` make check ``` @@ -166,6 +184,18 @@ Wait for the review to complete and report its verdict. ## Step 8 — Act on verdict +Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: + +``` +cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed. + Merge command (used by all paths below): `make merge` --- @@ -320,4 +350,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 8fa4491..05f2d96 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -33,7 +33,25 @@ If the current branch matches any of the above, **abort immediately** and say: ## Step 2 — Type-check gate -Run: +First, move to the repository root so the command resolves against the correct Makefile / project config: + +``` +cd "$(git rev-parse --show-toplevel)" +``` + +Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: + +``` +make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command. Do not proceed. + +If the target exists, run: ``` make check ``` @@ -172,6 +190,18 @@ Wait for the review to complete and report its verdict. ## Step 8 — Act on verdict +Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: + +``` +cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed. + Merge command (used by all paths below): `make merge` --- @@ -326,4 +356,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index c2bab6e..9d72f64 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -32,7 +32,25 @@ If the current branch matches any of the above, **abort immediately** and say: ## Step 2 — Type-check gate -Run: +First, move to the repository root so the command resolves against the correct Makefile / project config: + +``` +cd "$(git rev-parse --show-toplevel)" +``` + +Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: + +``` +make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command. Do not proceed. + +If the target exists, run: ``` make check ``` @@ -171,6 +189,18 @@ Wait for the review to complete and report its verdict. ## Step 8 — Act on verdict +Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: + +``` +cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed. + Merge command (used by all paths below): `make merge` --- @@ -325,4 +355,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index 5659c6c..91312ce 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -35,7 +35,25 @@ If the current branch matches any of the above, **abort immediately** and say: ## Step 2 — Type-check gate -Run: +First, move to the repository root so the command resolves against the correct Makefile / project config: + +``` +cd "$(git rev-parse --show-toplevel)" +``` + +Then verify the make target exists before running it. Extract the target name from `{{CHECK_CMD}}` (e.g. `make check` → `check`) and run: + +``` +make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`{{CHECK_CMD}}` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command. Do not proceed. + +If the target exists, run: ``` {{CHECK_CMD}} ``` @@ -190,6 +208,18 @@ Wait for the review to complete and report its verdict. ## Step 8 — Act on verdict +Before merging, verify the merge target exists. Move to the repo root, extract the target name from `{{MERGE_CMD}}` (e.g. `make merge` → `merge`), and run: + +``` +cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +``` + +If `make -n` exits non-zero, **stop** and say: + +> "`{{MERGE_CMD}}` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure." + +Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed. + {{#if BRANCH_DEV}} Merge command (used by all paths below): `{{MERGE_CMD}}` {{/if}} From f9ca4d864ed84d083f128144eaf495a9d0ca7eaf Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sun, 12 Apr 2026 21:49:44 -0400 Subject: [PATCH 4/7] Fix hard rules to reference --body-file instead of --body --- .agents/skills/start/SKILL.md | 4 ++-- .claude/commands/start.md | 4 ++-- .cursor/rules/start.mdc | 4 ++-- .gemini/skills/start/SKILL.md | 4 ++-- skills/start.md | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 28e63a4..171fb16 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -309,8 +309,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - Do not use `make branch` — always use `gh issue develop` so the branch is linked to the issue in GitHub. - Do not commit during `/start` — commits happen in `/submit-for-review`. - If already on a feature branch when `/start` is invoked with new work (Case A), prompt the user to either continue on the current branch (skipping branch creation) or abort. See **Pre-check: Existing feature branch** above. -- `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. +- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index dc01d24..3c3513e 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -304,8 +304,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - Do not use `make branch` — always use `gh issue develop` so the branch is linked to the issue in GitHub. - Do not commit during `/start` — commits happen in `/submit-for-review`. - If already on a feature branch when `/start` is invoked with new work (Case A), prompt the user to either continue on the current branch (skipping branch creation) or abort. See **Pre-check: Existing feature branch** above. -- `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. +- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index 720171b..14acaa0 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -310,8 +310,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - Do not use `make branch` — always use `gh issue develop` so the branch is linked to the issue in GitHub. - Do not commit during `/start` — commits happen in `/submit-for-review`. - If already on a feature branch when `/start` is invoked with new work (Case A), prompt the user to either continue on the current branch (skipping branch creation) or abort. See **Pre-check: Existing feature branch** above. -- `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. +- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index a84528a..20d594a 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -309,8 +309,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - Do not use `make branch` — always use `gh issue develop` so the branch is linked to the issue in GitHub. - Do not commit during `/start` — commits happen in `/submit-for-review`. - If already on a feature branch when `/start` is invoked with new work (Case A), prompt the user to either continue on the current branch (skipping branch creation) or abort. See **Pre-check: Existing feature branch** above. -- `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. +- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/skills/start.md b/skills/start.md index b404998..623c7d0 100644 --- a/skills/start.md +++ b/skills/start.md @@ -384,7 +384,7 @@ When done, say: **"The code is ready for review. Please run `{{DEV_CMD}}` and te - Do not use `make branch` — always use `gh issue develop` so the branch is linked to the issue in GitHub. - Do not commit during `/start` — commits happen in `/submit-for-review`. - If already on a feature branch when `/start` is invoked with new work (Case A), prompt the user to either continue on the current branch (skipping branch creation) or abort. See **Pre-check: Existing feature branch** above. -- `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. +- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. {{#if TICKET_LABELS}} {{#if TICKET_LABEL_CREATION_ALLOWED}} From 0082d01f94c8e6c6c796aa3ad32984f965981736 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sun, 12 Apr 2026 21:55:39 -0400 Subject: [PATCH 5/7] Replace command substitution with two-step cd in submit-for-review skill --- .agents/skills/submit-for-review/SKILL.md | 18 +++++++++++++++--- .claude/commands/submit-for-review.md | 18 +++++++++++++++--- .cursor/rules/submit-for-review.mdc | 18 +++++++++++++++--- .gemini/skills/submit-for-review/SKILL.md | 18 +++++++++++++++--- skills/submit-for-review.md | 16 ++++++++++++++-- 5 files changed, 74 insertions(+), 14 deletions(-) diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index b7b281e..be30c00 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -35,7 +35,13 @@ If the current branch matches any of the above, **abort immediately** and say: First, move to the repository root so the command resolves against the correct Makefile / project config: ``` -cd "$(git rev-parse --show-toplevel)" +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above: + +``` +cd ``` Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: @@ -192,7 +198,13 @@ Wait for the review to complete and report its verdict. Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: ``` -cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above and check the target: + +``` +cd && make -n 2>/dev/null ``` If `make -n` exits non-zero, **stop** and say: @@ -355,4 +367,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 82a6a32..1fc51d3 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -30,7 +30,13 @@ If the current branch matches any of the above, **abort immediately** and say: First, move to the repository root so the command resolves against the correct Makefile / project config: ``` -cd "$(git rev-parse --show-toplevel)" +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above: + +``` +cd ``` Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: @@ -187,7 +193,13 @@ Wait for the review to complete and report its verdict. Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: ``` -cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above and check the target: + +``` +cd && make -n 2>/dev/null ``` If `make -n` exits non-zero, **stop** and say: @@ -350,4 +362,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 05f2d96..f274c95 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -36,7 +36,13 @@ If the current branch matches any of the above, **abort immediately** and say: First, move to the repository root so the command resolves against the correct Makefile / project config: ``` -cd "$(git rev-parse --show-toplevel)" +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above: + +``` +cd ``` Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: @@ -193,7 +199,13 @@ Wait for the review to complete and report its verdict. Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: ``` -cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above and check the target: + +``` +cd && make -n 2>/dev/null ``` If `make -n` exits non-zero, **stop** and say: @@ -356,4 +368,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 9d72f64..d542089 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -35,7 +35,13 @@ If the current branch matches any of the above, **abort immediately** and say: First, move to the repository root so the command resolves against the correct Makefile / project config: ``` -cd "$(git rev-parse --show-toplevel)" +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above: + +``` +cd ``` Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run: @@ -192,7 +198,13 @@ Wait for the review to complete and report its verdict. Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run: ``` -cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above and check the target: + +``` +cd && make -n 2>/dev/null ``` If `make -n` exits non-zero, **stop** and say: @@ -355,4 +367,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index 91312ce..ce725cb 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -38,7 +38,13 @@ If the current branch matches any of the above, **abort immediately** and say: First, move to the repository root so the command resolves against the correct Makefile / project config: ``` -cd "$(git rev-parse --show-toplevel)" +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above: + +``` +cd ``` Then verify the make target exists before running it. Extract the target name from `{{CHECK_CMD}}` (e.g. `make check` → `check`) and run: @@ -211,7 +217,13 @@ Wait for the review to complete and report its verdict. Before merging, verify the merge target exists. Move to the repo root, extract the target name from `{{MERGE_CMD}}` (e.g. `make merge` → `merge`), and run: ``` -cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null +git rev-parse --show-toplevel +``` + +Then `cd` into the path returned above and check the target: + +``` +cd && make -n 2>/dev/null ``` If `make -n` exits non-zero, **stop** and say: From 921190190f2d80f9126ab9fe3a3ce70162b8c431 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Mon, 13 Apr 2026 09:18:21 -0400 Subject: [PATCH 6/7] Embed issue number in feature branch names for reliable PR-to-issue linking --- .agents/skills/start/SKILL.md | 6 +++--- .agents/skills/submit-for-review/SKILL.md | 11 +++++------ .claude/commands/start.md | 6 +++--- .claude/commands/submit-for-review.md | 11 +++++------ .cursor/rules/start.mdc | 6 +++--- .cursor/rules/submit-for-review.mdc | 11 +++++------ .gemini/skills/start/SKILL.md | 6 +++--- .gemini/skills/submit-for-review/SKILL.md | 11 +++++------ skills/start.md | 8 ++++---- skills/submit-for-review.md | 9 ++++----- 10 files changed, 40 insertions(+), 45 deletions(-) diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 171fb16..c8f0433 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -213,7 +213,7 @@ git checkout dev && git pull origin dev Now create the feature branch: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from. @@ -278,7 +278,7 @@ git checkout dev && git pull origin dev Find and check out the existing branch, or create a new one linked to the issue: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state. @@ -313,4 +313,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index be30c00..31d60a8 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -71,12 +71,11 @@ Do not proceed until `make check` passes cleanly. ## Step 3 — Identify linked issue -Check for a linked issue by inspecting the branch name (should follow `feature/` linked via `gh issue develop`) or by running: -``` -gh pr view --json number,body 2>/dev/null -``` +Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/-` (e.g. `feature/42-fix-login`). + +Parse the number from the branch name returned in Step 1. If the branch name matches `feature/-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user: -If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user. +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -367,4 +366,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index 3c3513e..ca98ac5 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -208,7 +208,7 @@ git checkout dev && git pull origin dev Now create the feature branch: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from. @@ -273,7 +273,7 @@ git checkout dev && git pull origin dev Find and check out the existing branch, or create a new one linked to the issue: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state. @@ -308,4 +308,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 1fc51d3..0cfa625 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -66,12 +66,11 @@ Do not proceed until `make check` passes cleanly. ## Step 3 — Identify linked issue -Check for a linked issue by inspecting the branch name (should follow `feature/` linked via `gh issue develop`) or by running: -``` -gh pr view --json number,body 2>/dev/null -``` +Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/-` (e.g. `feature/42-fix-login`). + +Parse the number from the branch name returned in Step 1. If the branch name matches `feature/-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user: -If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user. +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -362,4 +361,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index 14acaa0..858828e 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -214,7 +214,7 @@ git checkout dev && git pull origin dev Now create the feature branch: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from. @@ -279,7 +279,7 @@ git checkout dev && git pull origin dev Find and check out the existing branch, or create a new one linked to the issue: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state. @@ -314,4 +314,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index f274c95..0e647df 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -72,12 +72,11 @@ Do not proceed until `make check` passes cleanly. ## Step 3 — Identify linked issue -Check for a linked issue by inspecting the branch name (should follow `feature/` linked via `gh issue develop`) or by running: -``` -gh pr view --json number,body 2>/dev/null -``` +Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/-` (e.g. `feature/42-fix-login`). + +Parse the number from the branch name returned in Step 1. If the branch name matches `feature/-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user: -If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user. +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -368,4 +367,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index 20d594a..5008a87 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -213,7 +213,7 @@ git checkout dev && git pull origin dev Now create the feature branch: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from. @@ -278,7 +278,7 @@ git checkout dev && git pull origin dev Find and check out the existing branch, or create a new one linked to the issue: ```bash -gh issue develop --base dev --name feature/ --checkout +gh issue develop --base dev --name feature/- --checkout ``` > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state. @@ -313,4 +313,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index d542089..6503e61 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -71,12 +71,11 @@ Do not proceed until `make check` passes cleanly. ## Step 3 — Identify linked issue -Check for a linked issue by inspecting the branch name (should follow `feature/` linked via `gh issue develop`) or by running: -``` -gh pr view --json number,body 2>/dev/null -``` +Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/-` (e.g. `feature/42-fix-login`). + +Parse the number from the branch name returned in Step 1. If the branch name matches `feature/-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user: -If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user. +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -367,4 +366,4 @@ If a single `gh issue create` call fails, report the failure for that finding an - `/submit-for-review` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. - + diff --git a/skills/start.md b/skills/start.md index 623c7d0..d2d15a1 100644 --- a/skills/start.md +++ b/skills/start.md @@ -264,12 +264,12 @@ Now create the feature branch: {{#if BRANCH_DEV}} ```bash -gh issue develop --base {{BRANCH_DEV}} --name feature/ --checkout +gh issue develop --base {{BRANCH_DEV}} --name feature/- --checkout ``` {{/if}} {{#if !BRANCH_DEV}} ```bash -gh issue develop --name feature/ --checkout +gh issue develop --name feature/- --checkout ``` {{/if}} @@ -345,12 +345,12 @@ Find and check out the existing branch, or create a new one linked to the issue: {{#if BRANCH_DEV}} ```bash -gh issue develop --base {{BRANCH_DEV}} --name feature/ --checkout +gh issue develop --base {{BRANCH_DEV}} --name feature/- --checkout ``` {{/if}} {{#if !BRANCH_DEV}} ```bash -gh issue develop --name feature/ --checkout +gh issue develop --name feature/- --checkout ``` {{/if}} diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index ce725cb..a2a2564 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -74,12 +74,11 @@ Do not proceed until `{{CHECK_CMD}}` passes cleanly. ## Step 3 — Identify linked issue -Check for a linked issue by inspecting the branch name (should follow `feature/` linked via `gh issue develop`) or by running: -``` -gh pr view --json number,body 2>/dev/null -``` +Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/-` (e.g. `feature/42-fix-login`). + +Parse the number from the branch name returned in Step 1. If the branch name matches `feature/-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user: -If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user. +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- From b7e31b719dd014ed1de7dcf6473e6d2b01040c37 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Mon, 13 Apr 2026 12:30:37 -0400 Subject: [PATCH 7/7] Bump version to 0.5.1 --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index 8f0916f..4b9fcbe 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.5.0 +0.5.1