From 3ef101049b811778b8e1f679489907c3f6e1b968 Mon Sep 17 00:00:00 2001 From: rcourtman Date: Sat, 29 Nov 2025 14:29:44 +0000 Subject: [PATCH] Remove triage rules from repo Move to local-only location outside the codebase. --- .agent/rules/issue-triage.md | 61 ------------------------------------ 1 file changed, 61 deletions(-) delete mode 100644 .agent/rules/issue-triage.md diff --git a/.agent/rules/issue-triage.md b/.agent/rules/issue-triage.md deleted file mode 100644 index 6d2388f..0000000 --- a/.agent/rules/issue-triage.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -trigger: always_on ---- - -# GitHub Issue Triage - -When given a GitHub issue or discussion URL, follow this process: - -## 1. Check Git History FIRST (before reading issue details) - -```bash -# Search for commits referencing the issue number or related keywords -git log --all --since="30 days ago" --format="%h %ai %s" | grep -i "keywords|from|issue" -git log --all --oneline | grep -i "#123\|relevant-keywords" | head -20 -``` - -- Look for commits that reference the issue number -- Check if the issue was already addressed -- Understand recent development context - -## 2. Read ALL Comments - -```bash -gh issue view 123 --repo owner/repo --json comments --jq '.comments[] | "\(.author.login) (\(.createdAt)): \(.body)"' -``` - -- NEVER respond based on partial context -- Later comments often contain critical context -- Check if users confirmed fixes or provided updates - -## 3. Establish Timeline - -- When was the issue created? -- What commits happened after? -- Did users comment after commits to confirm/deny fixes? - -## 4. Challenge the Premise - -- Does this request make sense architecturally? -- What are the security implications? -- Is this solving the right problem? -- Does similar functionality already exist? -- Is there a configuration or documentation solution instead? - -## 5. Commit Message Rules - -- Reference issues: "Related to #123" or "Addresses #123" -- NEVER use auto-close keywords: "Fixes #123", "Closes #123", "Resolves #123" -- Users must verify fixes before issues are closed - -## 6. Comment Style (when writing responses) - -- Direct but user-friendly, write for typical users not developers -- No "we", "us", "our" -- No exclamation marks or enthusiasm -- No bullets/dashes for lists -- No pleasantries ("hope this helps", "let me know") -- Use hedging when uncertain: "might", "could", "possibly" -- For fixes: just say "This will be in the next release" -- NEVER say "build from source" or "pull latest" -- Match the user's effort level in your response