diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 28e63a4..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. @@ -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/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index f031964..31d60a8 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -32,7 +32,31 @@ 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: + +``` +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: + +``` +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 ``` @@ -47,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`). -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. +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: + +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -171,6 +194,24 @@ 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: + +``` +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: + +> "`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 +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 dc01d24..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. @@ -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/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index cb9f0ce..0cfa625 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -27,7 +27,31 @@ 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: + +``` +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: + +``` +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 ``` @@ -42,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`). -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. +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: + +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -166,6 +189,24 @@ 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: + +``` +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: + +> "`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 +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 720171b..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. @@ -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/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 8fa4491..0e647df 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -33,7 +33,31 @@ 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: + +``` +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: + +``` +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 ``` @@ -48,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`). -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. +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: + +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -172,6 +195,24 @@ 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: + +``` +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: + +> "`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 +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 a84528a..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. @@ -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/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index c2bab6e..6503e61 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -32,7 +32,31 @@ 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: + +``` +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: + +``` +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 ``` @@ -47,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`). -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. +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: + +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -171,6 +194,24 @@ 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: + +``` +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: + +> "`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 +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/.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/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; } 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. diff --git a/VERSION b/VERSION index 8f0916f..4b9fcbe 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.5.0 +0.5.1 diff --git a/skills/start.md b/skills/start.md index b404998..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}} @@ -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}} diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index 5659c6c..a2a2564 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -35,7 +35,31 @@ 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: + +``` +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: + +``` +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}} ``` @@ -50,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`). -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. +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: + +> "Could not extract an issue number from branch name ``. The PR will not include an issue reference. Was this branch created outside of `/start`?" --- @@ -190,6 +213,24 @@ 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: + +``` +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: + +> "`{{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}}