From 20de2ec3dcb30920b218e4198e699e12464f5cc3 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Wed, 15 Apr 2026 08:51:37 -0400 Subject: [PATCH 1/2] Add commit signing detection and configuration to setup skill --- .agents/skills/setup/SKILL.md | 69 +++++++++++++++++++++++++++++++---- .claude/commands/setup.md | 69 +++++++++++++++++++++++++++++++---- .cursor/rules/setup.mdc | 69 +++++++++++++++++++++++++++++++---- .gemini/skills/setup/SKILL.md | 69 +++++++++++++++++++++++++++++++---- docs/skills/setup.md | 10 ++++- skills/setup.md | 67 +++++++++++++++++++++++++++++++--- 6 files changed, 318 insertions(+), 35 deletions(-) diff --git a/.agents/skills/setup/SKILL.md b/.agents/skills/setup/SKILL.md index f86ffc7..2d82e09 100644 --- a/.agents/skills/setup/SKILL.md +++ b/.agents/skills/setup/SKILL.md @@ -258,7 +258,62 @@ A value counts as "set" if it is present, uncommented, and non-empty in `.codeca --- -### Phase 2 — Label population +### Phase 2 — Commit signing + +Check whether commit signing is already configured at any level (local or global): + +```bash +git config --get commit.gpgsign +``` + +If the output is `true`, display `Commit signing: enabled` in the health summary area and skip to Phase 3. + +If not `true`, ask: **"Does this project require signed commits? (yes/no)"** + +Wait for response. + +- **no / skip** → continue to Phase 3. +- **yes** → proceed with signing setup. + +**Verify a signing key exists:** + +```bash +git config --get user.signingkey +``` + +**If a signing key is found**, enable signing at the repo level: + +```bash +git config commit.gpgsign true +git config tag.gpgsign true +``` + +Display: `Commit signing enabled (key: ). Tags will also be signed.` + +Continue to Phase 3. + +**If no signing key is found**, detect the signing format: + +```bash +git config --get gpg.format +``` + +- If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. +- If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. + +Once the user provides a key value, set it along with signing: + +```bash +git config user.signingkey +git config commit.gpgsign true +git config tag.gpgsign true +``` + +If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." + +--- + +### Phase 3 — Label population Run: @@ -290,7 +345,7 @@ Wait for response. After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again. -If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 3; otherwise leave it unset so `/start` auto-detects." +If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 4; otherwise leave it unset so `/start` auto-detects." Display the results as a numbered list: @@ -308,7 +363,7 @@ Wait for the user's response. - **yes** → use all labels - **numbers** (e.g. `1,3,5`) → use only those labels -- **no / skip / anything else** → skip this phase, continue to Phase 3 +- **no / skip / anything else** → skip this phase, continue to Phase 4 Show the exact change before writing: @@ -324,7 +379,7 @@ Wait for confirmation. Write only on yes. --- -### Phase 3 — Optional config walkthrough (profile-aware) +### Phase 4 — Optional config walkthrough (profile-aware) First, infer the current profile using the same rules as Phase 1. @@ -346,7 +401,7 @@ The walkthrough adapts based on profile. Walk through each applicable unset valu --- -### Phase 4 — Team sharing +### Phase 5 — Team sharing After completing or skipping the config walkthrough, say: @@ -369,6 +424,6 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. +- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md index 15d78d5..cef0c0b 100644 --- a/.claude/commands/setup.md +++ b/.claude/commands/setup.md @@ -253,7 +253,62 @@ A value counts as "set" if it is present, uncommented, and non-empty in `.codeca --- -### Phase 2 — Label population +### Phase 2 — Commit signing + +Check whether commit signing is already configured at any level (local or global): + +```bash +git config --get commit.gpgsign +``` + +If the output is `true`, display `Commit signing: enabled` in the health summary area and skip to Phase 3. + +If not `true`, ask: **"Does this project require signed commits? (yes/no)"** + +Wait for response. + +- **no / skip** → continue to Phase 3. +- **yes** → proceed with signing setup. + +**Verify a signing key exists:** + +```bash +git config --get user.signingkey +``` + +**If a signing key is found**, enable signing at the repo level: + +```bash +git config commit.gpgsign true +git config tag.gpgsign true +``` + +Display: `Commit signing enabled (key: ). Tags will also be signed.` + +Continue to Phase 3. + +**If no signing key is found**, detect the signing format: + +```bash +git config --get gpg.format +``` + +- If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. +- If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. + +Once the user provides a key value, set it along with signing: + +```bash +git config user.signingkey +git config commit.gpgsign true +git config tag.gpgsign true +``` + +If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." + +--- + +### Phase 3 — Label population Run: @@ -285,7 +340,7 @@ Wait for response. After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again. -If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 3; otherwise leave it unset so `/start` auto-detects." +If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 4; otherwise leave it unset so `/start` auto-detects." Display the results as a numbered list: @@ -303,7 +358,7 @@ Wait for the user's response. - **yes** → use all labels - **numbers** (e.g. `1,3,5`) → use only those labels -- **no / skip / anything else** → skip this phase, continue to Phase 3 +- **no / skip / anything else** → skip this phase, continue to Phase 4 Show the exact change before writing: @@ -319,7 +374,7 @@ Wait for confirmation. Write only on yes. --- -### Phase 3 — Optional config walkthrough (profile-aware) +### Phase 4 — Optional config walkthrough (profile-aware) First, infer the current profile using the same rules as Phase 1. @@ -341,7 +396,7 @@ The walkthrough adapts based on profile. Walk through each applicable unset valu --- -### Phase 4 — Team sharing +### Phase 5 — Team sharing After completing or skipping the config walkthrough, say: @@ -364,6 +419,6 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. +- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.cursor/rules/setup.mdc b/.cursor/rules/setup.mdc index 689ece5..e8670b9 100644 --- a/.cursor/rules/setup.mdc +++ b/.cursor/rules/setup.mdc @@ -259,7 +259,62 @@ A value counts as "set" if it is present, uncommented, and non-empty in `.codeca --- -### Phase 2 — Label population +### Phase 2 — Commit signing + +Check whether commit signing is already configured at any level (local or global): + +```bash +git config --get commit.gpgsign +``` + +If the output is `true`, display `Commit signing: enabled` in the health summary area and skip to Phase 3. + +If not `true`, ask: **"Does this project require signed commits? (yes/no)"** + +Wait for response. + +- **no / skip** → continue to Phase 3. +- **yes** → proceed with signing setup. + +**Verify a signing key exists:** + +```bash +git config --get user.signingkey +``` + +**If a signing key is found**, enable signing at the repo level: + +```bash +git config commit.gpgsign true +git config tag.gpgsign true +``` + +Display: `Commit signing enabled (key: ). Tags will also be signed.` + +Continue to Phase 3. + +**If no signing key is found**, detect the signing format: + +```bash +git config --get gpg.format +``` + +- If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. +- If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. + +Once the user provides a key value, set it along with signing: + +```bash +git config user.signingkey +git config commit.gpgsign true +git config tag.gpgsign true +``` + +If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." + +--- + +### Phase 3 — Label population Run: @@ -291,7 +346,7 @@ Wait for response. After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again. -If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 3; otherwise leave it unset so `/start` auto-detects." +If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 4; otherwise leave it unset so `/start` auto-detects." Display the results as a numbered list: @@ -309,7 +364,7 @@ Wait for the user's response. - **yes** → use all labels - **numbers** (e.g. `1,3,5`) → use only those labels -- **no / skip / anything else** → skip this phase, continue to Phase 3 +- **no / skip / anything else** → skip this phase, continue to Phase 4 Show the exact change before writing: @@ -325,7 +380,7 @@ Wait for confirmation. Write only on yes. --- -### Phase 3 — Optional config walkthrough (profile-aware) +### Phase 4 — Optional config walkthrough (profile-aware) First, infer the current profile using the same rules as Phase 1. @@ -347,7 +402,7 @@ The walkthrough adapts based on profile. Walk through each applicable unset valu --- -### Phase 4 — Team sharing +### Phase 5 — Team sharing After completing or skipping the config walkthrough, say: @@ -370,6 +425,6 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. +- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.gemini/skills/setup/SKILL.md b/.gemini/skills/setup/SKILL.md index 3ca9690..fda7de1 100644 --- a/.gemini/skills/setup/SKILL.md +++ b/.gemini/skills/setup/SKILL.md @@ -258,7 +258,62 @@ A value counts as "set" if it is present, uncommented, and non-empty in `.codeca --- -### Phase 2 — Label population +### Phase 2 — Commit signing + +Check whether commit signing is already configured at any level (local or global): + +```bash +git config --get commit.gpgsign +``` + +If the output is `true`, display `Commit signing: enabled` in the health summary area and skip to Phase 3. + +If not `true`, ask: **"Does this project require signed commits? (yes/no)"** + +Wait for response. + +- **no / skip** → continue to Phase 3. +- **yes** → proceed with signing setup. + +**Verify a signing key exists:** + +```bash +git config --get user.signingkey +``` + +**If a signing key is found**, enable signing at the repo level: + +```bash +git config commit.gpgsign true +git config tag.gpgsign true +``` + +Display: `Commit signing enabled (key: ). Tags will also be signed.` + +Continue to Phase 3. + +**If no signing key is found**, detect the signing format: + +```bash +git config --get gpg.format +``` + +- If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. +- If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. + +Once the user provides a key value, set it along with signing: + +```bash +git config user.signingkey +git config commit.gpgsign true +git config tag.gpgsign true +``` + +If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." + +--- + +### Phase 3 — Label population Run: @@ -290,7 +345,7 @@ Wait for response. After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again. -If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 3; otherwise leave it unset so `/start` auto-detects." +If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 4; otherwise leave it unset so `/start` auto-detects." Display the results as a numbered list: @@ -308,7 +363,7 @@ Wait for the user's response. - **yes** → use all labels - **numbers** (e.g. `1,3,5`) → use only those labels -- **no / skip / anything else** → skip this phase, continue to Phase 3 +- **no / skip / anything else** → skip this phase, continue to Phase 4 Show the exact change before writing: @@ -324,7 +379,7 @@ Wait for confirmation. Write only on yes. --- -### Phase 3 — Optional config walkthrough (profile-aware) +### Phase 4 — Optional config walkthrough (profile-aware) First, infer the current profile using the same rules as Phase 1. @@ -346,7 +401,7 @@ The walkthrough adapts based on profile. Walk through each applicable unset valu --- -### Phase 4 — Team sharing +### Phase 5 — Team sharing After completing or skipping the config walkthrough, say: @@ -369,6 +424,6 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. +- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/docs/skills/setup.md b/docs/skills/setup.md index 681b8d1..557b180 100644 --- a/docs/skills/setup.md +++ b/docs/skills/setup.md @@ -10,7 +10,7 @@ First-run onboarding and configuration walkthrough. 1. **You're in the Code Cannon repo itself** — explains how Code Cannon works and offers to help you add it to your project. 2. **Partial setup** — the submodule exists but something is missing (sync.py not initialized, `gh` not installed, config file missing, etc.). Walks through fixes one at a time. -3. **Fully configured** — runs a health check, offers to populate labels from your GitHub repo, and walks through optional config values. +3. **Fully configured** — runs a health check, configures commit signing if needed, offers to populate labels from your GitHub repo, and walks through optional config values. ## Usage @@ -47,6 +47,14 @@ When creating `.codecannon.yaml` for the first time, `/setup` asks you to pick a Profiles are starting points — every setting is independently configurable afterward. +## Commit signing + +After the health summary, `/setup` checks whether `commit.gpgsign` is already enabled in your git config (local or global). If not, it asks whether your project requires signed commits. + +If yes, it verifies a signing key is configured and enables `commit.gpgsign` and `tag.gpgsign` at the repo level. If no signing key exists, it detects the signing format (SSH or GPG) and guides you through providing one. + +This is a git-level configuration — no changes to `.codecannon.yaml` or skill templates are needed. All skills that create commits or tags benefit automatically. + ## Label population Once fully configured, `/setup` fetches your repo's existing GitHub labels and offers to write them to `TICKET_LABELS` in `.codecannon.yaml`. This populates the label pool that `/start` uses when creating issues. diff --git a/skills/setup.md b/skills/setup.md index f6b63b4..45dd7ad 100644 --- a/skills/setup.md +++ b/skills/setup.md @@ -256,7 +256,62 @@ A value counts as "set" if it is present, uncommented, and non-empty in `.codeca --- -### Phase 2 — Label population +### Phase 2 — Commit signing + +Check whether commit signing is already configured at any level (local or global): + +```bash +git config --get commit.gpgsign +``` + +If the output is `true`, display `Commit signing: enabled` in the health summary area and skip to Phase 3. + +If not `true`, ask: **"Does this project require signed commits? (yes/no)"** + +Wait for response. + +- **no / skip** → continue to Phase 3. +- **yes** → proceed with signing setup. + +**Verify a signing key exists:** + +```bash +git config --get user.signingkey +``` + +**If a signing key is found**, enable signing at the repo level: + +```bash +git config commit.gpgsign true +git config tag.gpgsign true +``` + +Display: `Commit signing enabled (key: ). Tags will also be signed.` + +Continue to Phase 3. + +**If no signing key is found**, detect the signing format: + +```bash +git config --get gpg.format +``` + +- If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. +- If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. + +Once the user provides a key value, set it along with signing: + +```bash +git config user.signingkey +git config commit.gpgsign true +git config tag.gpgsign true +``` + +If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." + +--- + +### Phase 3 — Label population Run: @@ -288,7 +343,7 @@ Wait for response. After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again. -If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 3; otherwise leave it unset so `/start` auto-detects." +If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 4; otherwise leave it unset so `/start` auto-detects." Display the results as a numbered list: @@ -306,7 +361,7 @@ Wait for the user's response. - **yes** → use all labels - **numbers** (e.g. `1,3,5`) → use only those labels -- **no / skip / anything else** → skip this phase, continue to Phase 3 +- **no / skip / anything else** → skip this phase, continue to Phase 4 Show the exact change before writing: @@ -322,7 +377,7 @@ Wait for confirmation. Write only on yes. --- -### Phase 3 — Optional config walkthrough (profile-aware) +### Phase 4 — Optional config walkthrough (profile-aware) First, infer the current profile using the same rules as Phase 1. @@ -344,7 +399,7 @@ The walkthrough adapts based on profile. Walk through each applicable unset valu --- -### Phase 4 — Team sharing +### Phase 5 — Team sharing After completing or skipping the config walkthrough, say: @@ -367,5 +422,5 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. +- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. From 414d0075e085d4ed1b20dd16b84067ea53169cbf Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Wed, 15 Apr 2026 08:55:05 -0400 Subject: [PATCH 2/2] Add confirmation gates to Phase 2 signing setup and update hard rules --- .agents/skills/setup/SKILL.md | 38 +++++++++++++++++++++++------------ .claude/commands/setup.md | 38 +++++++++++++++++++++++------------ .cursor/rules/setup.mdc | 38 +++++++++++++++++++++++------------ .gemini/skills/setup/SKILL.md | 38 +++++++++++++++++++++++------------ skills/setup.md | 36 ++++++++++++++++++++++----------- 5 files changed, 124 insertions(+), 64 deletions(-) diff --git a/.agents/skills/setup/SKILL.md b/.agents/skills/setup/SKILL.md index 2d82e09..d8db8d6 100644 --- a/.agents/skills/setup/SKILL.md +++ b/.agents/skills/setup/SKILL.md @@ -281,14 +281,20 @@ Wait for response. git config --get user.signingkey ``` -**If a signing key is found**, enable signing at the repo level: +**If a signing key is found**, show the proposed change and confirm: -```bash -git config commit.gpgsign true -git config tag.gpgsign true +``` +I'll enable commit and tag signing for this repo: + + git config commit.gpgsign true + git config tag.gpgsign true + + Signing key: + +Proceed? (yes/no) ``` -Display: `Commit signing enabled (key: ). Tags will also be signed.` +Wait for confirmation. Write only on yes. If no, skip to Phase 3. Continue to Phase 3. @@ -301,13 +307,19 @@ git config --get gpg.format - If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. - If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. -Once the user provides a key value, set it along with signing: +Once the user provides a key value, show the proposed changes and confirm: -```bash -git config user.signingkey -git config commit.gpgsign true -git config tag.gpgsign true ``` +I'll configure signing for this repo: + + git config user.signingkey + git config commit.gpgsign true + git config tag.gpgsign true + +Proceed? (yes/no) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." @@ -419,11 +431,11 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri ## Hard rules -- Only modify `.codecannon.yaml`. Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). +- Only modify `.codecannon.yaml` and local git config (Phase 2 signing setup). Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). - Do not run `sync.py` without explicit user permission. - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. +- Do not skip any human gate in Phase 2, Phase 3, or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md index cef0c0b..4c219e1 100644 --- a/.claude/commands/setup.md +++ b/.claude/commands/setup.md @@ -276,14 +276,20 @@ Wait for response. git config --get user.signingkey ``` -**If a signing key is found**, enable signing at the repo level: +**If a signing key is found**, show the proposed change and confirm: -```bash -git config commit.gpgsign true -git config tag.gpgsign true +``` +I'll enable commit and tag signing for this repo: + + git config commit.gpgsign true + git config tag.gpgsign true + + Signing key: + +Proceed? (yes/no) ``` -Display: `Commit signing enabled (key: ). Tags will also be signed.` +Wait for confirmation. Write only on yes. If no, skip to Phase 3. Continue to Phase 3. @@ -296,13 +302,19 @@ git config --get gpg.format - If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. - If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. -Once the user provides a key value, set it along with signing: +Once the user provides a key value, show the proposed changes and confirm: -```bash -git config user.signingkey -git config commit.gpgsign true -git config tag.gpgsign true ``` +I'll configure signing for this repo: + + git config user.signingkey + git config commit.gpgsign true + git config tag.gpgsign true + +Proceed? (yes/no) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." @@ -414,11 +426,11 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri ## Hard rules -- Only modify `.codecannon.yaml`. Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). +- Only modify `.codecannon.yaml` and local git config (Phase 2 signing setup). Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). - Do not run `sync.py` without explicit user permission. - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. +- Do not skip any human gate in Phase 2, Phase 3, or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.cursor/rules/setup.mdc b/.cursor/rules/setup.mdc index e8670b9..8162698 100644 --- a/.cursor/rules/setup.mdc +++ b/.cursor/rules/setup.mdc @@ -282,14 +282,20 @@ Wait for response. git config --get user.signingkey ``` -**If a signing key is found**, enable signing at the repo level: +**If a signing key is found**, show the proposed change and confirm: -```bash -git config commit.gpgsign true -git config tag.gpgsign true +``` +I'll enable commit and tag signing for this repo: + + git config commit.gpgsign true + git config tag.gpgsign true + + Signing key: + +Proceed? (yes/no) ``` -Display: `Commit signing enabled (key: ). Tags will also be signed.` +Wait for confirmation. Write only on yes. If no, skip to Phase 3. Continue to Phase 3. @@ -302,13 +308,19 @@ git config --get gpg.format - If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. - If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. -Once the user provides a key value, set it along with signing: +Once the user provides a key value, show the proposed changes and confirm: -```bash -git config user.signingkey -git config commit.gpgsign true -git config tag.gpgsign true ``` +I'll configure signing for this repo: + + git config user.signingkey + git config commit.gpgsign true + git config tag.gpgsign true + +Proceed? (yes/no) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." @@ -420,11 +432,11 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri ## Hard rules -- Only modify `.codecannon.yaml`. Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). +- Only modify `.codecannon.yaml` and local git config (Phase 2 signing setup). Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). - Do not run `sync.py` without explicit user permission. - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. +- Do not skip any human gate in Phase 2, Phase 3, or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.gemini/skills/setup/SKILL.md b/.gemini/skills/setup/SKILL.md index fda7de1..d9686c5 100644 --- a/.gemini/skills/setup/SKILL.md +++ b/.gemini/skills/setup/SKILL.md @@ -281,14 +281,20 @@ Wait for response. git config --get user.signingkey ``` -**If a signing key is found**, enable signing at the repo level: +**If a signing key is found**, show the proposed change and confirm: -```bash -git config commit.gpgsign true -git config tag.gpgsign true +``` +I'll enable commit and tag signing for this repo: + + git config commit.gpgsign true + git config tag.gpgsign true + + Signing key: + +Proceed? (yes/no) ``` -Display: `Commit signing enabled (key: ). Tags will also be signed.` +Wait for confirmation. Write only on yes. If no, skip to Phase 3. Continue to Phase 3. @@ -301,13 +307,19 @@ git config --get gpg.format - If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. - If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. -Once the user provides a key value, set it along with signing: +Once the user provides a key value, show the proposed changes and confirm: -```bash -git config user.signingkey -git config commit.gpgsign true -git config tag.gpgsign true ``` +I'll configure signing for this repo: + + git config user.signingkey + git config commit.gpgsign true + git config tag.gpgsign true + +Proceed? (yes/no) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." @@ -419,11 +431,11 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri ## Hard rules -- Only modify `.codecannon.yaml`. Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). +- Only modify `.codecannon.yaml` and local git config (Phase 2 signing setup). Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). - Do not run `sync.py` without explicit user permission. - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. +- Do not skip any human gate in Phase 2, Phase 3, or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/skills/setup.md b/skills/setup.md index 45dd7ad..f242aac 100644 --- a/skills/setup.md +++ b/skills/setup.md @@ -279,14 +279,20 @@ Wait for response. git config --get user.signingkey ``` -**If a signing key is found**, enable signing at the repo level: +**If a signing key is found**, show the proposed change and confirm: -```bash -git config commit.gpgsign true -git config tag.gpgsign true +``` +I'll enable commit and tag signing for this repo: + + git config commit.gpgsign true + git config tag.gpgsign true + + Signing key: + +Proceed? (yes/no) ``` -Display: `Commit signing enabled (key: ). Tags will also be signed.` +Wait for confirmation. Write only on yes. If no, skip to Phase 3. Continue to Phase 3. @@ -299,13 +305,19 @@ git config --get gpg.format - If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path. - If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID. -Once the user provides a key value, set it along with signing: +Once the user provides a key value, show the proposed changes and confirm: -```bash -git config user.signingkey -git config commit.gpgsign true -git config tag.gpgsign true ``` +I'll configure signing for this repo: + + git config user.signingkey + git config commit.gpgsign true + git config tag.gpgsign true + +Proceed? (yes/no) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing." @@ -417,10 +429,10 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri ## Hard rules -- Only modify `.codecannon.yaml`. Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). +- Only modify `.codecannon.yaml` and local git config (Phase 2 signing setup). Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval). - Do not run `sync.py` without explicit user permission. - Do not create `.codecannon.yaml` without explicit user permission. - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks. - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. -- Do not skip any human gate in Phase 3 or Phase 4 — each write requires confirmation. +- Do not skip any human gate in Phase 2, Phase 3, or Phase 4 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on.