From 08aeb94d02f328d02b4da06b8a208b39990337a0 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sat, 11 Apr 2026 09:20:28 -0400 Subject: [PATCH 1/2] Clarify /start human gate messages with intent classification and 'go' shorthand --- .agents/skills/start/SKILL.md | 28 +++++++++++++++++++--------- .claude/commands/start.md | 28 +++++++++++++++++++--------- .cursor/rules/start.mdc | 28 +++++++++++++++++++--------- .gemini/skills/start/SKILL.md | 28 +++++++++++++++++++--------- skills/start.md | 26 ++++++++++++++++++-------- 5 files changed, 94 insertions(+), 44 deletions(-) diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 92be2cc..3c8989c 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -76,15 +76,20 @@ Read the relevant code. Propose a concrete implementation approach. Be specific ### Step 2 — HUMAN GATE -Say exactly: **"Does this approach sound right? I'll create a GitHub issue and branch before writing any code."** +Say exactly: -Stop. Wait for the user to confirm. +> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** + +Stop. Wait for the user to respond. The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI. -- User says yes → continue to Step 3. -- User redirects → revise approach, ask again. -- User abandons → stop. Nothing to clean up. +**Intent classification (not keyword matching):** + +- **Affirmative with no conditions** ("go", "yes", "looks good", "let's do it") → continue to Step 3. +- **Affirmative with conditions** ("go, but first change X", "yes but can we also...") → treat as discussion. Address the conditions, revise the approach if needed, then re-ask. +- **Questions or pushback** ("what about...", "I'm not sure about...", any adjustment) → discuss, revise approach, re-ask. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Create GitHub Issue @@ -203,10 +208,15 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Continue this ticket, or open a fresh one?"** +Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** + +**Intent classification (not keyword matching):** -- Continue → Step 3. -- New ticket → restart as Case A with a new description. +- **Affirmative with no conditions** ("go", "yes", "continue", "looks right") → proceed to Step 3. +- **Affirmative with conditions** ("go, but first...", "yes but let's also...") → treat as discussion. Address the conditions, then re-ask. +- **Questions or discussion** ("what about...", "can we change...", any adjustment) → discuss, then re-ask. +- **Fresh start** ("open a new one", "start fresh", "new ticket") → restart as Case A with a new description. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Check out branch @@ -254,4 +264,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index 2bd19c1..8a95539 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -71,15 +71,20 @@ Read the relevant code. Propose a concrete implementation approach. Be specific ### Step 2 — HUMAN GATE -Say exactly: **"Does this approach sound right? I'll create a GitHub issue and branch before writing any code."** +Say exactly: -Stop. Wait for the user to confirm. +> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** + +Stop. Wait for the user to respond. The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI. -- User says yes → continue to Step 3. -- User redirects → revise approach, ask again. -- User abandons → stop. Nothing to clean up. +**Intent classification (not keyword matching):** + +- **Affirmative with no conditions** ("go", "yes", "looks good", "let's do it") → continue to Step 3. +- **Affirmative with conditions** ("go, but first change X", "yes but can we also...") → treat as discussion. Address the conditions, revise the approach if needed, then re-ask. +- **Questions or pushback** ("what about...", "I'm not sure about...", any adjustment) → discuss, revise approach, re-ask. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Create GitHub Issue @@ -198,10 +203,15 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Continue this ticket, or open a fresh one?"** +Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** + +**Intent classification (not keyword matching):** -- Continue → Step 3. -- New ticket → restart as Case A with a new description. +- **Affirmative with no conditions** ("go", "yes", "continue", "looks right") → proceed to Step 3. +- **Affirmative with conditions** ("go, but first...", "yes but let's also...") → treat as discussion. Address the conditions, then re-ask. +- **Questions or discussion** ("what about...", "can we change...", any adjustment) → discuss, then re-ask. +- **Fresh start** ("open a new one", "start fresh", "new ticket") → restart as Case A with a new description. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Check out branch @@ -249,4 +259,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index 54ca08c..e6a3dfd 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -77,15 +77,20 @@ Read the relevant code. Propose a concrete implementation approach. Be specific ### Step 2 — HUMAN GATE -Say exactly: **"Does this approach sound right? I'll create a GitHub issue and branch before writing any code."** +Say exactly: -Stop. Wait for the user to confirm. +> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** + +Stop. Wait for the user to respond. The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI. -- User says yes → continue to Step 3. -- User redirects → revise approach, ask again. -- User abandons → stop. Nothing to clean up. +**Intent classification (not keyword matching):** + +- **Affirmative with no conditions** ("go", "yes", "looks good", "let's do it") → continue to Step 3. +- **Affirmative with conditions** ("go, but first change X", "yes but can we also...") → treat as discussion. Address the conditions, revise the approach if needed, then re-ask. +- **Questions or pushback** ("what about...", "I'm not sure about...", any adjustment) → discuss, revise approach, re-ask. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Create GitHub Issue @@ -204,10 +209,15 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Continue this ticket, or open a fresh one?"** +Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** + +**Intent classification (not keyword matching):** -- Continue → Step 3. -- New ticket → restart as Case A with a new description. +- **Affirmative with no conditions** ("go", "yes", "continue", "looks right") → proceed to Step 3. +- **Affirmative with conditions** ("go, but first...", "yes but let's also...") → treat as discussion. Address the conditions, then re-ask. +- **Questions or discussion** ("what about...", "can we change...", any adjustment) → discuss, then re-ask. +- **Fresh start** ("open a new one", "start fresh", "new ticket") → restart as Case A with a new description. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Check out branch @@ -255,4 +265,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index 28593a4..b829f50 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -76,15 +76,20 @@ Read the relevant code. Propose a concrete implementation approach. Be specific ### Step 2 — HUMAN GATE -Say exactly: **"Does this approach sound right? I'll create a GitHub issue and branch before writing any code."** +Say exactly: -Stop. Wait for the user to confirm. +> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** + +Stop. Wait for the user to respond. The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI. -- User says yes → continue to Step 3. -- User redirects → revise approach, ask again. -- User abandons → stop. Nothing to clean up. +**Intent classification (not keyword matching):** + +- **Affirmative with no conditions** ("go", "yes", "looks good", "let's do it") → continue to Step 3. +- **Affirmative with conditions** ("go, but first change X", "yes but can we also...") → treat as discussion. Address the conditions, revise the approach if needed, then re-ask. +- **Questions or pushback** ("what about...", "I'm not sure about...", any adjustment) → discuss, revise approach, re-ask. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Create GitHub Issue @@ -203,10 +208,15 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Continue this ticket, or open a fresh one?"** +Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** + +**Intent classification (not keyword matching):** -- Continue → Step 3. -- New ticket → restart as Case A with a new description. +- **Affirmative with no conditions** ("go", "yes", "continue", "looks right") → proceed to Step 3. +- **Affirmative with conditions** ("go, but first...", "yes but let's also...") → treat as discussion. Address the conditions, then re-ask. +- **Questions or discussion** ("what about...", "can we change...", any adjustment) → discuss, then re-ask. +- **Fresh start** ("open a new one", "start fresh", "new ticket") → restart as Case A with a new description. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Check out branch @@ -254,4 +264,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/skills/start.md b/skills/start.md index 19d448f..90f8bda 100644 --- a/skills/start.md +++ b/skills/start.md @@ -119,15 +119,20 @@ Read the relevant code. Propose a concrete implementation approach. Be specific ### Step 2 — HUMAN GATE -Say exactly: **"Does this approach sound right? I'll create a GitHub issue and branch before writing any code."** +Say exactly: -Stop. Wait for the user to confirm. +> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** + +Stop. Wait for the user to respond. The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI. -- User says yes → continue to Step 3. -- User redirects → revise approach, ask again. -- User abandons → stop. Nothing to clean up. +**Intent classification (not keyword matching):** + +- **Affirmative with no conditions** ("go", "yes", "looks good", "let's do it") → continue to Step 3. +- **Affirmative with conditions** ("go, but first change X", "yes but can we also...") → treat as discussion. Address the conditions, revise the approach if needed, then re-ask. +- **Questions or pushback** ("what about...", "I'm not sure about...", any adjustment) → discuss, revise approach, re-ask. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Create GitHub Issue @@ -262,10 +267,15 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Continue this ticket, or open a fresh one?"** +Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** + +**Intent classification (not keyword matching):** -- Continue → Step 3. -- New ticket → restart as Case A with a new description. +- **Affirmative with no conditions** ("go", "yes", "continue", "looks right") → proceed to Step 3. +- **Affirmative with conditions** ("go, but first...", "yes but let's also...") → treat as discussion. Address the conditions, then re-ask. +- **Questions or discussion** ("what about...", "can we change...", any adjustment) → discuss, then re-ask. +- **Fresh start** ("open a new one", "start fresh", "new ticket") → restart as Case A with a new description. +- **Abandonment** ("never mind", "not now", "stop") → stop. Nothing to clean up. ### Step 3 — Check out branch From ecb534e0ed9dd2b92d39127e79ab8fa5a333ec86 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sat, 11 Apr 2026 09:24:06 -0400 Subject: [PATCH 2/2] Fix nested double quotes in gate messages by using backtick-quoted go --- .agents/skills/start/SKILL.md | 6 +++--- .claude/commands/start.md | 6 +++--- .cursor/rules/start.mdc | 6 +++--- .gemini/skills/start/SKILL.md | 6 +++--- skills/start.md | 4 ++-- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 3c8989c..44a5230 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -78,7 +78,7 @@ Read the relevant code. Propose a concrete implementation approach. Be specific Say exactly: -> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** +> **"Does this approach sound right? Type `go` to create a GitHub issue and branch, or share any questions/adjustments first."** Stop. Wait for the user to respond. @@ -208,7 +208,7 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** +Ask: **"Does this match your understanding? Type `go` to start coding, or share any questions/adjustments first."** **Intent classification (not keyword matching):** @@ -264,4 +264,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index 8a95539..6ad8207 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -73,7 +73,7 @@ Read the relevant code. Propose a concrete implementation approach. Be specific Say exactly: -> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** +> **"Does this approach sound right? Type `go` to create a GitHub issue and branch, or share any questions/adjustments first."** Stop. Wait for the user to respond. @@ -203,7 +203,7 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** +Ask: **"Does this match your understanding? Type `go` to start coding, or share any questions/adjustments first."** **Intent classification (not keyword matching):** @@ -259,4 +259,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index e6a3dfd..50a2546 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -79,7 +79,7 @@ Read the relevant code. Propose a concrete implementation approach. Be specific Say exactly: -> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** +> **"Does this approach sound right? Type `go` to create a GitHub issue and branch, or share any questions/adjustments first."** Stop. Wait for the user to respond. @@ -209,7 +209,7 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** +Ask: **"Does this match your understanding? Type `go` to start coding, or share any questions/adjustments first."** **Intent classification (not keyword matching):** @@ -265,4 +265,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index b829f50..f5121dd 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -78,7 +78,7 @@ Read the relevant code. Propose a concrete implementation approach. Be specific Say exactly: -> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** +> **"Does this approach sound right? Type `go` to create a GitHub issue and branch, or share any questions/adjustments first."** Stop. Wait for the user to respond. @@ -208,7 +208,7 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** +Ask: **"Does this match your understanding? Type `go` to start coding, or share any questions/adjustments first."** **Intent classification (not keyword matching):** @@ -264,4 +264,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/skills/start.md b/skills/start.md index 90f8bda..421c404 100644 --- a/skills/start.md +++ b/skills/start.md @@ -121,7 +121,7 @@ Read the relevant code. Propose a concrete implementation approach. Be specific Say exactly: -> **"Does this approach sound right? Type "go" to create a GitHub issue and branch, or share any questions/adjustments first."** +> **"Does this approach sound right? Type `go` to create a GitHub issue and branch, or share any questions/adjustments first."** Stop. Wait for the user to respond. @@ -267,7 +267,7 @@ Tell the user: - What was previously done (from agent notes if present) - What appears to remain -Ask: **"Does this match your understanding? Type "go" to start coding, or share any questions/adjustments first."** +Ask: **"Does this match your understanding? Type `go` to start coding, or share any questions/adjustments first."** **Intent classification (not keyword matching):**