@fro.bot/systematic 2.2.0 → 2.3.0

package/skills/ce-review/references/subagent-template.md

@@ -0,0 +1,84 @@
+# Sub-agent Prompt Template
+
+This template is used by the orchestrator to spawn each reviewer sub-agent. Variable substitution slots are filled at spawn time.
+
+---
+
+## Template
+
+```
+You are a specialist code reviewer.
+
+<persona>
+{persona_file}
+</persona>
+
+<scope-rules>
+{diff_scope_rules}
+</scope-rules>
+
+<output-contract>
+Return ONLY valid JSON matching the findings schema below. No prose, no markdown, no explanation outside the JSON object.
+
+{schema}
+
+Confidence rubric (0.0-1.0 scale):
+- 0.00-0.29: Not confident / likely false positive. Do not report.
+- 0.30-0.49: Somewhat confident. Do not report -- too speculative for actionable review.
+- 0.50-0.59: Moderately confident. Real but uncertain. Do not report unless P0 severity.
+- 0.60-0.69: Confident enough to flag. Include only when the issue is clearly actionable.
+- 0.70-0.84: Highly confident. Real and important. Report with full evidence.
+- 0.85-1.00: Certain. Verifiable from the code alone. Report.
+
+Suppress threshold: 0.60. Do not emit findings below 0.60 confidence (except P0 at 0.50+).
+
+False-positive categories to actively suppress:
+- Pre-existing issues unrelated to this diff (mark pre_existing: true for unchanged code the diff does not interact with; if the diff makes it newly relevant, it is secondary, not pre-existing)
+- Pedantic style nitpicks that a linter/formatter would catch
+- Code that looks wrong but is intentional (check comments, commit messages, PR description for intent)
+- Issues already handled elsewhere in the codebase (check callers, guards, middleware)
+- Suggestions that restate what the code already does in different words
+- Generic "consider adding" advice without a concrete failure mode
+
+Rules:
+- Every finding MUST include at least one evidence item grounded in the actual code.
+- Set pre_existing to true ONLY for issues in unchanged code that are unrelated to this diff. If the diff makes the issue newly relevant, it is NOT pre-existing.
+- You are operationally read-only. You may use non-mutating inspection commands, including read-oriented `git` / `gh` commands, to gather evidence. Do not edit files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
+- Set `autofix_class` accurately -- not every finding is `advisory`. Use this decision guide:
+  - `safe_auto`: The fix is local and deterministic — the fixer can apply it mechanically without design judgment. Examples: extracting a duplicated helper, adding a missing nil/null check, fixing an off-by-one, adding a missing test for an untested code path, removing dead code.
+  - `gated_auto`: A concrete fix exists but it changes contracts, permissions, or crosses a module boundary in a way that deserves explicit approval. Examples: adding authentication to an unprotected endpoint, changing a public API response shape, switching from soft-delete to hard-delete.
+  - `manual`: Actionable work that requires design decisions or cross-cutting changes. Examples: redesigning a data model, choosing between two valid architectural approaches, adding pagination to an unbounded query.
+  - `advisory`: Report-only items that should not become code-fix work. Examples: noting a design asymmetry the PR improves but doesn't fully resolve, flagging a residual risk, deployment notes.
+  Do not default to `advisory` when uncertain -- if a concrete fix is obvious, classify it as `safe_auto` or `gated_auto`.
+- Set `owner` to the default next actor for this finding: `review-fixer`, `downstream-resolver`, `human`, or `release`.
+- Set `requires_verification` to true whenever the likely fix needs targeted tests, a focused re-review, or operational validation before it should be trusted.
+- suggested_fix is optional. Only include it when the fix is obvious and correct. A bad suggestion is worse than none.
+- If you find no issues, return an empty findings array. Still populate residual_risks and testing_gaps if applicable.
+- **Intent verification:** Compare the code changes against the stated intent (and PR title/body when available). If the code does something the intent does not describe, or fails to do something the intent promises, flag it as a finding. Mismatches between stated intent and actual code are high-value findings.
+</output-contract>
+
+<pr-context>
+{pr_metadata}
+</pr-context>
+
+<review-context>
+Intent: {intent_summary}
+
+Changed files: {file_list}
+
+Diff:
+{diff}
+</review-context>
+```
+
+## Variable Reference
+
+| Variable | Source | Description |
+|----------|--------|-------------|
+| `{persona_file}` | Agent markdown file content | The full persona definition (identity, failure modes, calibration, suppress conditions) |
+| `{diff_scope_rules}` | `references/diff-scope.md` content | Primary/secondary/pre-existing tier rules |
+| `{schema}` | `references/findings-schema.json` content | The JSON schema reviewers must conform to |
+| `{intent_summary}` | Stage 2 output | 2-3 line description of what the change is trying to accomplish |
+| `{pr_metadata}` | Stage 1 output | PR title, body, and URL when reviewing a PR. Empty string when reviewing a branch or standalone checkout |
+| `{file_list}` | Stage 1 output | List of changed files from the scope step |
+| `{diff}` | Stage 1 output | The actual diff content to review |

package/skills/claude-permissions-optimizer/scripts/extract-commands.mjs

@@ -93,7 +93,7 @@ function matchGlob(pattern, command) {
   if (normalized.endsWith(' *')) {
     const base = normalized.slice(0, -2)
     const escaped = base.replace(/[.+^${}()|[\]\\]/g, '\\$&')
-    regexStr = `^${escaped}($| .*)`
+    regexStr = '^' + escaped + '($| .*)'
   } else {
     regexStr =
       '^' +
@@ -530,7 +530,7 @@ for (const [command, data] of commands) {
     continue
   }
 
-  const pattern = `Bash(${normalize(command)})`
+  const pattern = 'Bash(' + normalize(command) + ')'
   const { tier, reason } = classify(command)
 
   const existing = patternGroups.get(pattern)

package/skills/claude-permissions-optimizer/scripts/normalize.mjs

@@ -47,20 +47,20 @@ export function normalize(command) {
 
   // Handle pnpm --filter <pkg> <subcommand> specially
   const pnpmFilter = command.match(/^pnpm\s+--filter\s+\S+\s+(\S+)/)
-  if (pnpmFilter) return `pnpm --filter * ${pnpmFilter[1]} *`
+  if (pnpmFilter) return 'pnpm --filter * ' + pnpmFilter[1] + ' *'
 
   // Handle sed specially -- preserve the mode flag to keep safe patterns narrow.
   // sed -i (in-place) is destructive; sed -n, sed -e, bare sed are read-only.
   if (/^sed\s/.test(command)) {
     if (/\s-i\b/.test(command)) return 'sed -i *'
     const sedFlag = command.match(/^sed\s+(-[a-zA-Z])\s/)
-    return sedFlag ? `sed ${sedFlag[1]} *` : 'sed *'
+    return sedFlag ? 'sed ' + sedFlag[1] + ' *' : 'sed *'
   }
 
   // Handle ast-grep specially -- preserve --rewrite flag.
   if (/^(ast-grep|sg)\s/.test(command)) {
     const base = command.startsWith('sg') ? 'sg' : 'ast-grep'
-    return /\s--rewrite\b/.test(command) ? `${base} --rewrite *` : `${base} *`
+    return /\s--rewrite\b/.test(command) ? base + ' --rewrite *' : base + ' *'
   }
 
   // Handle find specially -- preserve key action flags.
@@ -70,12 +70,12 @@ export function normalize(command) {
     if (/\s-exec\s/.test(command)) return 'find -exec *'
     // Extract the first predicate flag for a narrower safe pattern
     const findFlag = command.match(/\s(-(?:name|type|path|iname))\s/)
-    return findFlag ? `find ${findFlag[1]} *` : 'find *'
+    return findFlag ? 'find ' + findFlag[1] + ' *' : 'find *'
   }
 
   // Handle git -C <dir> <subcommand> -- strip the -C <dir> and normalize the git subcommand
   const gitC = command.match(/^git\s+-C\s+\S+\s+(.+)$/)
-  if (gitC) return normalize(`git ${gitC[1]}`)
+  if (gitC) return normalize('git ' + gitC[1])
 
   // Split on compound operators -- normalize the first command only
   const compoundMatch = command.match(/^(.+?)\s*(&&|\|\||;)\s*(.+)$/)
@@ -123,7 +123,7 @@ export function normalize(command) {
   let argStart = 1
 
   if (multiWordBases.includes(base) && parts.length > 1) {
-    prefix = `${base} ${parts[1]}`
+    prefix = base + ' ' + parts[1]
     argStart = 2
   }
 
@@ -141,11 +141,11 @@ export function normalize(command) {
   }
 
   const flagStr =
-    preservedFlags.length > 0 ? ` ${preservedFlags.join(' ')}` : ''
+    preservedFlags.length > 0 ? ' ' + preservedFlags.join(' ') : ''
   const hasVaryingArgs = parts.length > argStart + preservedFlags.length
 
   if (hasVaryingArgs) {
-    return `${prefix + flagStr} *`
+    return prefix + flagStr + ' *'
   }
   return prefix + flagStr
 }

package/skills/document-review/references/findings-schema.json

@@ -0,0 +1,109 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Document Review Findings",
+  "description": "Structured output schema for document review persona agents",
+  "type": "object",
+  "required": ["reviewer", "findings", "residual_risks", "deferred_questions"],
+  "properties": {
+    "reviewer": {
+      "type": "string",
+      "description": "Persona name that produced this output (e.g., 'coherence', 'feasibility', 'product-lens')"
+    },
+    "findings": {
+      "type": "array",
+      "description": "List of document review findings. Empty array if no issues found.",
+      "items": {
+        "type": "object",
+        "required": [
+          "title",
+          "severity",
+          "section",
+          "why_it_matters",
+          "finding_type",
+          "autofix_class",
+          "confidence",
+          "evidence"
+        ],
+        "properties": {
+          "title": {
+            "type": "string",
+            "description": "Short, specific issue title. 10 words or fewer.",
+            "maxLength": 100
+          },
+          "severity": {
+            "type": "string",
+            "enum": ["P0", "P1", "P2", "P3"],
+            "description": "Issue severity level"
+          },
+          "section": {
+            "type": "string",
+            "description": "Document section where the issue appears (e.g., 'Requirements Trace', 'Implementation Unit 3', 'Overview')"
+          },
+          "why_it_matters": {
+            "type": "string",
+            "description": "Impact statement -- not 'what is wrong' but 'what goes wrong if not addressed'"
+          },
+          "autofix_class": {
+            "type": "string",
+            "enum": ["auto", "present"],
+            "description": "How this issue should be handled. auto = one clear correct fix that can be applied silently (terminology, formatting, cross-references, completeness corrections, additions mechanically implied by other content). present = requires individual user judgment."
+          },
+          "finding_type": {
+            "type": "string",
+            "enum": ["error", "omission"],
+            "description": "Whether the finding is a mistake in what the document says (error) or something the document forgot to say (omission). Errors are design tensions, contradictions, or incorrect statements. Omissions are missing mechanical steps, forgotten list entries, or absent details."
+          },
+          "suggested_fix": {
+            "type": ["string", "null"],
+            "description": "Concrete fix text. Omit or null if no good fix is obvious -- a bad suggestion is worse than none."
+          },
+          "confidence": {
+            "type": "number",
+            "description": "Reviewer confidence in this finding, calibrated per persona",
+            "minimum": 0.0,
+            "maximum": 1.0
+          },
+          "evidence": {
+            "type": "array",
+            "description": "Quoted text from the document that supports this finding. At least 1 item.",
+            "items": { "type": "string" },
+            "minItems": 1
+          }
+        }
+      }
+    },
+    "residual_risks": {
+      "type": "array",
+      "description": "Risks the reviewer noticed but could not confirm as findings (below confidence threshold)",
+      "items": { "type": "string" }
+    },
+    "deferred_questions": {
+      "type": "array",
+      "description": "Questions that should be resolved in a later workflow stage (planning, implementation)",
+      "items": { "type": "string" }
+    }
+  },
+
+  "_meta": {
+    "confidence_thresholds": {
+      "suppress": "Below 0.50 -- do not report. Finding is speculative noise.",
+      "flag": "0.50-0.69 -- include only when the persona's calibration says the issue is actionable at that confidence.",
+      "report": "0.70+ -- report with full confidence."
+    },
+    "severity_definitions": {
+      "P0": "Contradictions or gaps that would cause building the wrong thing. Must fix before proceeding.",
+      "P1": "Significant gap likely hit during planning or implementation. Should fix.",
+      "P2": "Moderate issue with meaningful downside. Fix if straightforward.",
+      "P3": "Minor improvement. User's discretion."
+    },
+    "autofix_classes": {
+      "_principle": "Autofix class is independent of severity. A P1 finding can be auto if the fix is obvious. The test: is there one clear correct fix, or does resolving this require judgment?",
+      "auto": "One clear correct fix -- applied silently. Includes both internal reconciliation (summary/detail mismatches, wrong counts, stale cross-references, terminology drift) and additions mechanically implied by other content (missing steps, unstated thresholds, completeness gaps where the correct content is obvious). Must include suggested_fix.",
+      "present": "Requires individual user judgment -- strategic questions, design tradeoffs, or findings where reasonable people could disagree on the right action."
+    },
+    "finding_types": {
+      "error": "Something the document says that is wrong -- contradictions, incorrect statements, design tensions, incoherent tradeoffs. These are mistakes in what exists.",
+      "omission": "Something the document forgot to say -- missing mechanical steps, absent list entries, undefined thresholds, forgotten cross-references. These are gaps in completeness."
+    }
+  }
+}

package/skills/document-review/references/review-output-template.md

@@ -0,0 +1,89 @@
+# Document Review Output Template
+
+Use this **exact format** when presenting synthesized review findings. Findings are grouped by severity, not by reviewer.
+
+**IMPORTANT:** Use pipe-delimited markdown tables (`| col | col |`). Do NOT use ASCII box-drawing characters.
+
+## Example
+
+```markdown
+## Document Review Results
+
+**Document:** docs/plans/2026-03-15-feat-user-auth-plan.md
+**Type:** plan
+**Reviewers:** coherence, feasibility, security-lens, scope-guardian
+- security-lens -- plan adds public API endpoint with auth flow
+- scope-guardian -- plan has 15 requirements across 3 priority levels
+
+Applied 5 auto-fixes. 4 findings to consider (2 errors, 2 omissions).
+
+### Auto-fixes Applied
+
+- Standardized "pipeline"/"workflow" terminology to "pipeline" throughout (coherence)
+- Fixed cross-reference: Section 4 referenced "Section 3.2" which is actually "Section 3.1" (coherence)
+- Updated unit count from "6 units" to "7 units" to match listed units (coherence)
+- Added "update API rate-limit config" step to Unit 4 -- implied by Unit 3's rate-limit introduction (feasibility)
+- Added auth token refresh to test scenarios -- required by Unit 2's token expiry handling (security-lens)
+
+### P0 -- Must Fix
+
+#### Errors
+
+| # | Section | Issue | Reviewer | Confidence |
+|---|---------|-------|----------|------------|
+| 1 | Requirements Trace | Goal states "offline support" but technical approach assumes persistent connectivity | coherence | 0.92 |
+
+### P1 -- Should Fix
+
+#### Errors
+
+| # | Section | Issue | Reviewer | Confidence |
+|---|---------|-------|----------|------------|
+| 2 | Scope Boundaries | 8 of 12 units build admin infrastructure; only 2 touch stated goal | scope-guardian | 0.80 |
+
+#### Omissions
+
+| # | Section | Issue | Reviewer | Confidence |
+|---|---------|-------|----------|------------|
+| 3 | Implementation Unit 3 | Plan proposes custom auth but does not mention existing Devise setup or migration path | feasibility | 0.85 |
+
+### P2 -- Consider Fixing
+
+#### Omissions
+
+| # | Section | Issue | Reviewer | Confidence |
+|---|---------|-------|----------|------------|
+| 4 | API Design | Public webhook endpoint has no rate limiting mentioned | security-lens | 0.75 |
+
+### Residual Concerns
+
+| # | Concern | Source |
+|---|---------|--------|
+| 1 | Migration rollback strategy not addressed for Phase 2 data changes | feasibility |
+
+### Deferred Questions
+
+| # | Question | Source |
+|---|---------|--------|
+| 1 | Should the API use versioned endpoints from launch? | feasibility, security-lens |
+
+### Coverage
+
+| Persona | Status | Findings | Auto | Present | Residual |
+|---------|--------|----------|------|---------|----------|
+| coherence | completed | 4 | 3 | 1 | 0 |
+| feasibility | completed | 2 | 1 | 1 | 1 |
+| security-lens | completed | 2 | 1 | 1 | 0 |
+| scope-guardian | completed | 1 | 0 | 1 | 0 |
+| product-lens | not activated | -- | -- | -- | -- |
+| design-lens | not activated | -- | -- | -- | -- |
+```
+
+## Section Rules
+
+- **Summary line**: Always present after the reviewer list. Format: "Applied N auto-fixes. K findings to consider (X errors, Y omissions)." Omit any zero clause.
+- **Auto-fixes Applied**: List all fixes that were applied automatically (auto class). Include enough detail per fix to convey the substance -- especially for fixes that add content or touch document meaning. Omit section if none.
+- **P0-P3 sections**: Only include sections that have findings. Omit empty severity levels. Within each severity, separate into **Errors** and **Omissions** sub-headers. Omit a sub-header if that severity has none of that type.
+- **Residual Concerns**: Findings below confidence threshold that were promoted by cross-persona corroboration, plus unpromoted residual risks. Omit if none.
+- **Deferred Questions**: Questions for later workflow stages. Omit if none.
+- **Coverage**: Always include. All counts are **post-synthesis**. **Findings** must equal Auto + Present exactly -- if deduplication merged a finding across personas, attribute it to the persona with the highest confidence and reduce the other persona's count. **Residual** = count of `residual_risks` from this persona's raw output (not the promoted subset in the Residual Concerns section).

package/skills/document-review/references/subagent-template.md

@@ -0,0 +1,57 @@
+# Document Review Sub-agent Prompt Template
+
+This template is used by the document-review orchestrator to spawn each reviewer sub-agent. Variable substitution slots are filled at dispatch time.
+
+---
+
+## Template
+
+```
+You are a specialist document reviewer.
+
+<persona>
+{persona_file}
+</persona>
+
+<output-contract>
+Return ONLY valid JSON matching the findings schema below. No prose, no markdown, no explanation outside the JSON object.
+
+{schema}
+
+Rules:
+- Suppress any finding below your stated confidence floor (see your Confidence calibration section).
+- Every finding MUST include at least one evidence item -- a direct quote from the document.
+- You are operationally read-only. Analyze the document and produce findings. Do not edit the document, create files, or make changes. You may use non-mutating tools (file reads, glob, grep, git log) to gather context about the codebase when evaluating feasibility or existing patterns.
+- Set `finding_type` for every finding:
+  - `error`: Something the document says that is wrong -- contradictions, incorrect statements, design tensions, incoherent tradeoffs.
+  - `omission`: Something the document forgot to say -- missing mechanical steps, absent list entries, undefined thresholds, forgotten cross-references.
+- Set `autofix_class` based on whether there is one clear correct fix, not on severity. A P1 finding can be `auto` if the fix is obvious:
+  - `auto`: One clear correct fix. Applied silently without asking. The test: is there only one reasonable way to resolve this? If yes, it is auto. Two categories:
+    - Internal reconciliation: one part of the document is authoritative over another -- reconcile toward the authority. Examples: summary/detail mismatches, wrong counts, missing list entries derivable from elsewhere, stale cross-references, terminology drift, prose/diagram contradictions where prose is authoritative.
+    - Implied additions: the correct content is mechanically obvious from the document's own context. Examples: adding a missing implementation step implied by other content, defining a threshold implied but never stated, completeness gaps where what to add is clear.
+    Always include `suggested_fix` for auto findings.
+    NOT auto (the gap is clear but more than one reasonable fix exists): choosing an implementation approach when the document states a need without constraining how (e.g., "support offline mode" could mean service workers, local-first database, or queue-and-sync -- there is no single obvious answer), changing scope or priority where the author may have weighed tradeoffs the reviewer can't see (e.g., promoting a P2 to P1, or cutting a feature the document intentionally keeps at a lower tier).
+  - `present`: Requires judgment -- strategic questions, tradeoffs, design tensions where reasonable people could disagree, findings where the right action is unclear.
+- `suggested_fix` is required for `auto` findings. For `present` findings, `suggested_fix` is optional -- include it only when the fix is obvious, and frame as a question when the right action is unclear.
+- If you find no issues, return an empty findings array. Still populate residual_risks and deferred_questions if applicable.
+- Use your suppress conditions. Do not flag issues that belong to other personas.
+</output-contract>
+
+<review-context>
+Document type: {document_type}
+Document path: {document_path}
+
+Document content:
+{document_content}
+</review-context>
+```
+
+## Variable Reference
+
+| Variable | Source | Description |
+|----------|--------|-------------|
+| `{persona_file}` | Agent markdown file content | The full persona definition (identity, analysis protocol, calibration, suppress conditions) |
+| `{schema}` | `references/findings-schema.json` content | The JSON schema reviewers must conform to |
+| `{document_type}` | Orchestrator classification | Either "requirements" or "plan" |
+| `{document_path}` | Skill input | Path to the document being reviewed |
+| `{document_content}` | File read | The full document text |

package/skills/git-clean-gone-branches/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: git-clean-gone-branches
+description: Clean up local branches whose remote tracking branch is gone. Use when the user says "clean up branches", "delete gone branches", "prune local branches", "clean gone", or wants to remove stale local branches that no longer exist on the remote. Also handles removing associated worktrees for branches that have them.
+---
+
+# Clean Gone Branches
+
+Delete local branches whose remote tracking branch has been deleted, including any associated worktrees.
+
+## Workflow
+
+### Step 1: Discover gone branches
+
+Run the discovery script to fetch the latest remote state and identify gone branches:
+
+```bash
+bash scripts/clean-gone
+```
+
+[scripts/clean-gone](./scripts/clean-gone)
+
+The script runs `git fetch --prune` first, then parses `git branch -vv` for branches marked `: gone]`.
+
+If the script outputs `__NONE__`, report that no stale branches were found and stop.
+
+### Step 2: Present branches and ask for confirmation
+
+Show the user the list of branches that will be deleted. Format as a simple list:
+
+```
+These local branches have been deleted from the remote:
+
+  - feature/old-thing
+  - bugfix/resolved-issue
+  - experiment/abandoned
+
+Delete all of them? (y/n)
+```
+
+Wait for the user's answer using the platform's question tool (e.g., `question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the list and wait for the user's reply before proceeding.
+
+This is a yes-or-no decision on the entire list -- do not offer multi-selection or per-branch choices.
+
+### Step 3: Delete confirmed branches
+
+If the user confirms, delete each branch. For each branch:
+
+1. Check if it has an associated worktree (`git worktree list | grep "\\[$branch\\]"`)
+2. If a worktree exists and is not the main repo root, remove it first: `git worktree remove --force "$worktree_path"`
+3. Delete the branch: `git branch -D "$branch"`
+
+Report results as you go:
+
+```
+Removed worktree: .worktrees/feature/old-thing
+Deleted branch: feature/old-thing
+Deleted branch: bugfix/resolved-issue
+Deleted branch: experiment/abandoned
+
+Cleaned up 3 branches.
+```
+
+If the user declines, acknowledge and stop without deleting anything.

package/skills/git-clean-gone-branches/scripts/clean-gone

@@ -0,0 +1,48 @@
+#!/usr/bin/env bash
+# clean-gone: List local branches whose remote tracking branch is gone.
+# Outputs one branch name per line, or nothing if none found.
+
+set -euo pipefail
+
+# Ensure we have current remote state
+git fetch --prune 2>/dev/null
+
+# Find branches marked [gone] in tracking info.
+# `git branch -vv` output format:
+#   * main           abc1234 [origin/main] commit msg
+#   + feature-x      def5678 [origin/feature-x: gone] commit msg
+#     old-branch     789abcd [origin/old-branch: gone] commit msg
+#
+# The leading column can be: ' ' (normal), '*' (current), '+' (worktree).
+# We match lines containing ": gone]" to find branches whose remote is deleted.
+
+gone_branches=()
+
+while IFS= read -r line; do
+  # Skip the currently checked-out branch (marked with '*').
+  # git branch -D cannot delete the active branch, and attempting it
+  # would halt cleanup before other stale branches are processed.
+  if [[ "$line" =~ ^\* ]]; then
+    continue
+  fi
+
+  # Strip the leading marker character(s) and whitespace
+  # The branch name is the first non-whitespace token after the marker
+  branch_name=$(echo "$line" | sed 's/^[+* ]*//' | awk '{print $1}')
+
+  # Validate: skip empty, skip if it looks like a hash or flag, skip HEAD
+  if [[ -z "$branch_name" ]] || [[ "$branch_name" =~ ^[0-9a-f]{7,}$ ]] || [[ "$branch_name" == "HEAD" ]]; then
+    continue
+  fi
+
+  gone_branches+=("$branch_name")
+done < <(git branch -vv 2>/dev/null | grep ': gone]')
+
+if [[ ${#gone_branches[@]} -eq 0 ]]; then
+  echo "__NONE__"
+  exit 0
+fi
+
+for branch in "${gone_branches[@]}"; do
+  echo "$branch"
+done

package/skills/git-commit/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: git-commit
+description: Create a git commit with a clear, value-communicating message. Use when the user says "commit", "commit this", "save my changes", "create a commit", or wants to commit staged or unstaged work. Produces well-structured commit messages that follow repo conventions when they exist, and defaults to conventional commit format otherwise.
+---
+
+# Git Commit
+
+Create a single, well-crafted git commit from the current working tree changes.
+
+## Context
+
+**If you are not OpenCode**, skip to the "Context fallback" section below and run the command there to gather context.
+
+**If you are OpenCode**, the five labeled sections below (Git status, Working tree diff, Current branch, Recent commits, Remote default branch) contain pre-populated data. Use them directly throughout this skill -- do not re-run these commands.
+
+**Git status:**
+!`git status`
+
+**Working tree diff:**
+!`git diff HEAD`
+
+**Current branch:**
+!`git branch --show-current`
+
+**Recent commits:**
+!`git log --oneline -10`
+
+**Remote default branch:**
+!`git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'`
+
+### Context fallback
+
+**If you are OpenCode, skip this section — the data above is already available.**
+
+Run this single command to gather all context:
+
+```bash
+printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'
+```
+
+---
+
+## Workflow
+
+### Step 1: Gather context
+
+Use the context above (git status, working tree diff, current branch, recent commits, remote default branch). All data needed for this step is already available -- do not re-run those commands.
+
+The remote default branch value returns something like `origin/main`. Strip the `origin/` prefix to get the branch name. If it returned `__DEFAULT_BRANCH_UNRESOLVED__` or a bare `HEAD`, try:
+
+```bash
+gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
+```
+
+If both fail, fall back to `main`.
+
+If the git status from the context above shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.
+
+If the current branch from the context above is empty, the repository is in detached HEAD state. Explain that a branch is required before committing if the user wants this work attached to a branch. Ask whether to create a feature branch now. Use the platform's blocking question tool (`question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding.
+
+- If the user chooses to create a branch, derive the name from the change content, create it with `git checkout -b <branch-name>`, then run `git branch --show-current` again and use that result as the current branch name for the rest of the workflow.
+- If the user declines, continue with the detached HEAD commit.
+
+### Step 2: Determine commit message convention
+
+Follow this priority order:
+
+1. **Repo conventions already in context** -- If project instructions (AGENTS.md, AGENTS.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.
+2. **Recent commit history** -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.
+3. **Default: conventional commits** -- If neither source provides a pattern, use conventional commit format: `type(scope): description` where type is one of `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `style`, `build`.
+
+### Step 3: Consider logical commits
+
+Before staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.
+
+Keep this lightweight:
+- Group at the **file level only** -- do not use `git add -p` or try to split hunks within a file.
+- If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.
+- Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.
+
+### Step 4: Stage and commit
+
+If the current branch from the context above is `main`, `master`, or the resolved default branch from Step 1, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool (`question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding. If the user chooses to create a branch, derive the name from the change content, create it with `git checkout -b <branch-name>`, then continue.
+
+Write the commit message:
+- **Subject line**: Concise, imperative mood, focused on *why* not *what*. Follow the convention determined in Step 2.
+- **Body** (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.
+
+For each commit group, stage and commit in a single call. Prefer staging specific files by name over `git add -A` or `git add .` to avoid accidentally including sensitive files (.env, credentials) or unrelated changes. Use a heredoc to preserve formatting:
+
+```bash
+git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
+type(scope): subject line here
+
+Optional body explaining why this change was made,
+not just what changed.
+EOF
+)"
+```
+
+### Step 5: Confirm
+
+Run `git status` after the commit to verify success. Report the commit hash(es) and subject line(s).