diff --git a/.agents/skills/setup/SKILL.md b/.agents/skills/setup/SKILL.md index f86ffc7..d8db8d6 100644 --- a/.agents/skills/setup/SKILL.md +++ b/.agents/skills/setup/SKILL.md @@ -258,7 +258,74 @@ 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**, show the proposed change and confirm: + +``` +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) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. + +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, show the proposed changes and confirm: + +``` +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." + +--- + +### Phase 3 — Label population Run: @@ -290,7 +357,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 +375,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 +391,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 +413,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,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 2 or Phase 3 — 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 15d78d5..4c219e1 100644 --- a/.claude/commands/setup.md +++ b/.claude/commands/setup.md @@ -253,7 +253,74 @@ 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**, show the proposed change and confirm: + +``` +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) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. + +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, show the proposed changes and confirm: + +``` +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." + +--- + +### Phase 3 — Label population Run: @@ -285,7 +352,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 +370,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 +386,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 +408,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: @@ -359,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 2 or Phase 3 — 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 689ece5..8162698 100644 --- a/.cursor/rules/setup.mdc +++ b/.cursor/rules/setup.mdc @@ -259,7 +259,74 @@ 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**, show the proposed change and confirm: + +``` +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) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. + +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, show the proposed changes and confirm: + +``` +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." + +--- + +### Phase 3 — Label population Run: @@ -291,7 +358,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 +376,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 +392,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 +414,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: @@ -365,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 2 or Phase 3 — 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 3ca9690..d9686c5 100644 --- a/.gemini/skills/setup/SKILL.md +++ b/.gemini/skills/setup/SKILL.md @@ -258,7 +258,74 @@ 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**, show the proposed change and confirm: + +``` +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) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. + +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, show the proposed changes and confirm: + +``` +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." + +--- + +### Phase 3 — Label population Run: @@ -290,7 +357,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 +375,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 +391,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 +413,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,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 2 or Phase 3 — 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/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..f242aac 100644 --- a/skills/setup.md +++ b/skills/setup.md @@ -256,7 +256,74 @@ 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**, show the proposed change and confirm: + +``` +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) +``` + +Wait for confirmation. Write only on yes. If no, skip to Phase 3. + +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, show the proposed changes and confirm: + +``` +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." + +--- + +### Phase 3 — Label population Run: @@ -288,7 +355,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 +373,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 +389,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 +411,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: @@ -362,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 2 or Phase 3 — 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.