@bradygaster/squad-cli 0.9.3-insider.1 → 0.9.4

package/templates/skills/gh-auth-isolation/SKILL.md

@@ -1,183 +1,183 @@
----
-name: "gh-auth-isolation"
-description: "Safely manage multiple GitHub identities (EMU + personal) in agent workflows"
-domain: "security, github-integration, authentication, multi-account"
-confidence: "high"
-source: "earned (production usage across 50+ sessions with EMU corp + personal GitHub accounts)"
-tools:
-  - name: "gh"
-    description: "GitHub CLI for authenticated operations"
-    when: "When accessing GitHub resources requiring authentication"
----
-
-## Context
-
-Many developers use GitHub through an Enterprise Managed User (EMU) account at work while maintaining a personal GitHub account for open-source contributions. AI agents spawned by Squad inherit the shell's default `gh` authentication — which is usually the EMU account. This causes failures when agents try to push to personal repos, create PRs on forks, or interact with resources outside the enterprise org.
-
-This skill teaches agents how to detect the active identity, switch contexts safely, and avoid mixing credentials across operations.
-
-## Patterns
-
-### Detect Current Identity
-
-Before any GitHub operation, check which account is active:
-
-```bash
-gh auth status
-```
-
-Look for:
-- `Logged in to github.com as USERNAME` — the active account
-- `Token scopes: ...` — what permissions are available
-- Multiple accounts will show separate entries
-
-### Extract a Specific Account's Token
-
-When you need to operate as a specific user (not the default):
-
-```bash
-# Get the personal account token (by username)
-gh auth token --user personaluser
-
-# Get the EMU account token
-gh auth token --user corpalias_enterprise
-```
-
-**Use case:** Push to a personal fork while the default `gh` auth is the EMU account.
-
-### Push to Personal Repos from EMU Shell
-
-The most common scenario: your shell defaults to the EMU account, but you need to push to a personal GitHub repo.
-
-```bash
-# 1. Extract the personal token
-$token = gh auth token --user personaluser
-
-# 2. Push using token-authenticated HTTPS
-git push https://personaluser:$token@github.com/personaluser/repo.git branch-name
-```
-
-**Why this works:** `gh auth token --user` reads from `gh`'s credential store without switching the active account. The token is used inline for a single operation and never persisted.
-
-### Create PRs on Personal Forks
-
-When the default `gh` context is EMU but you need to create a PR from a personal fork:
-
-```bash
-# Option 1: Use --repo flag (works if token has access)
-gh pr create --repo upstream/repo --head personaluser:branch --title "..." --body "..."
-
-# Option 2: Temporarily set GH_TOKEN for one command
-$env:GH_TOKEN = $(gh auth token --user personaluser)
-gh pr create --repo upstream/repo --head personaluser:branch --title "..."
-Remove-Item Env:\GH_TOKEN
-```
-
-### Config Directory Isolation (Advanced)
-
-For complete isolation between accounts, use separate `gh` config directories:
-
-```bash
-# Personal account operations
-$env:GH_CONFIG_DIR = "$HOME/.config/gh-public"
-gh auth login  # Login with personal account (one-time setup)
-gh repo clone personaluser/repo
-
-# EMU account operations (default)
-Remove-Item Env:\GH_CONFIG_DIR
-gh auth status  # Back to EMU account
-```
-
-**Setup (one-time):**
-```bash
-# Create isolated config for personal account
-mkdir ~/.config/gh-public
-$env:GH_CONFIG_DIR = "$HOME/.config/gh-public"
-gh auth login --web --git-protocol https
-```
-
-### Shell Aliases for Quick Switching
-
-Add to your shell profile for convenience:
-
-```powershell
-# PowerShell profile
-function ghp { $env:GH_CONFIG_DIR = "$HOME/.config/gh-public"; gh @args; Remove-Item Env:\GH_CONFIG_DIR }
-function ghe { gh @args }  # Default EMU
-
-# Usage:
-# ghp repo clone personaluser/repo   # Uses personal account
-# ghe issue list                       # Uses EMU account
-```
-
-```bash
-# Bash/Zsh profile
-alias ghp='GH_CONFIG_DIR=~/.config/gh-public gh'
-alias ghe='gh'
-
-# Usage:
-# ghp repo clone personaluser/repo
-# ghe issue list
-```
-
-## Examples
-
-### ✓ Correct: Agent pushes blog post to personal GitHub Pages
-
-```powershell
-# Agent needs to push to personaluser.github.io (personal repo)
-# Default gh auth is corpalias_enterprise (EMU)
-
-$token = gh auth token --user personaluser
-git remote set-url origin https://personaluser:$token@github.com/personaluser/personaluser.github.io.git
-git push origin main
-
-# Clean up — don't leave token in remote URL
-git remote set-url origin https://github.com/personaluser/personaluser.github.io.git
-```
-
-### ✓ Correct: Agent creates a PR from personal fork to upstream
-
-```powershell
-# Fork: personaluser/squad, Upstream: bradygaster/squad
-# Agent is on branch contrib/fix-docs in the fork clone
-
-git push origin contrib/fix-docs  # Pushes to fork (may need token auth)
-
-# Create PR targeting upstream
-gh pr create --repo bradygaster/squad --head personaluser:contrib/fix-docs `
-  --title "docs: fix installation guide" `
-  --body "Fixes #123"
-```
-
-### ✗ Incorrect: Blindly pushing with wrong account
-
-```bash
-# BAD: Agent assumes default gh auth works for personal repos
-git push origin main
-# ERROR: Permission denied — EMU account has no access to personal repo
-
-# BAD: Hardcoding tokens in scripts
-git push https://personaluser:ghp_xxxxxxxxxxxx@github.com/personaluser/repo.git main
-# SECURITY RISK: Token exposed in command history and process list
-```
-
-### ✓ Correct: Check before you push
-
-```bash
-# Always verify which account has access before operations
-gh auth status
-# If wrong account, use token extraction:
-$token = gh auth token --user personaluser
-git push https://personaluser:$token@github.com/personaluser/repo.git main
-```
-
-## Anti-Patterns
-
-- ❌ **Hardcoding tokens** in scripts, environment variables, or committed files. Use `gh auth token --user` to extract at runtime.
-- ❌ **Assuming the default `gh` auth works** for all repos. EMU accounts can't access personal repos and vice versa.
-- ❌ **Switching `gh auth login`** globally mid-session. This changes the default for ALL processes and can break parallel agents.
-- ❌ **Storing personal tokens in `.env`** or `.squad/` files. These get committed by Scribe. Use `gh`'s credential store.
-- ❌ **Ignoring token cleanup** after inline HTTPS pushes. Always reset the remote URL to avoid persisting tokens.
-- ❌ **Using `gh auth switch`** in multi-agent sessions. One agent switching affects all others sharing the shell.
-- ❌ **Mixing EMU and personal operations** in the same git clone. Use separate clones or explicit remote URLs per operation.
+---
+name: "gh-auth-isolation"
+description: "Safely manage multiple GitHub identities (EMU + personal) in agent workflows"
+domain: "security, github-integration, authentication, multi-account"
+confidence: "high"
+source: "earned (production usage across 50+ sessions with EMU corp + personal GitHub accounts)"
+tools:
+  - name: "gh"
+    description: "GitHub CLI for authenticated operations"
+    when: "When accessing GitHub resources requiring authentication"
+---
+
+## Context
+
+Many developers use GitHub through an Enterprise Managed User (EMU) account at work while maintaining a personal GitHub account for open-source contributions. AI agents spawned by Squad inherit the shell's default `gh` authentication — which is usually the EMU account. This causes failures when agents try to push to personal repos, create PRs on forks, or interact with resources outside the enterprise org.
+
+This skill teaches agents how to detect the active identity, switch contexts safely, and avoid mixing credentials across operations.
+
+## Patterns
+
+### Detect Current Identity
+
+Before any GitHub operation, check which account is active:
+
+```bash
+gh auth status
+```
+
+Look for:
+- `Logged in to github.com as USERNAME` — the active account
+- `Token scopes: ...` — what permissions are available
+- Multiple accounts will show separate entries
+
+### Extract a Specific Account's Token
+
+When you need to operate as a specific user (not the default):
+
+```bash
+# Get the personal account token (by username)
+gh auth token --user personaluser
+
+# Get the EMU account token
+gh auth token --user corpalias_enterprise
+```
+
+**Use case:** Push to a personal fork while the default `gh` auth is the EMU account.
+
+### Push to Personal Repos from EMU Shell
+
+The most common scenario: your shell defaults to the EMU account, but you need to push to a personal GitHub repo.
+
+```bash
+# 1. Extract the personal token
+$token = gh auth token --user personaluser
+
+# 2. Push using token-authenticated HTTPS
+git push https://personaluser:$token@github.com/personaluser/repo.git branch-name
+```
+
+**Why this works:** `gh auth token --user` reads from `gh`'s credential store without switching the active account. The token is used inline for a single operation and never persisted.
+
+### Create PRs on Personal Forks
+
+When the default `gh` context is EMU but you need to create a PR from a personal fork:
+
+```bash
+# Option 1: Use --repo flag (works if token has access)
+gh pr create --repo upstream/repo --head personaluser:branch --title "..." --body "..."
+
+# Option 2: Temporarily set GH_TOKEN for one command
+$env:GH_TOKEN = $(gh auth token --user personaluser)
+gh pr create --repo upstream/repo --head personaluser:branch --title "..."
+Remove-Item Env:\GH_TOKEN
+```
+
+### Config Directory Isolation (Advanced)
+
+For complete isolation between accounts, use separate `gh` config directories:
+
+```bash
+# Personal account operations
+$env:GH_CONFIG_DIR = "$HOME/.config/gh-public"
+gh auth login  # Login with personal account (one-time setup)
+gh repo clone personaluser/repo
+
+# EMU account operations (default)
+Remove-Item Env:\GH_CONFIG_DIR
+gh auth status  # Back to EMU account
+```
+
+**Setup (one-time):**
+```bash
+# Create isolated config for personal account
+mkdir ~/.config/gh-public
+$env:GH_CONFIG_DIR = "$HOME/.config/gh-public"
+gh auth login --web --git-protocol https
+```
+
+### Shell Aliases for Quick Switching
+
+Add to your shell profile for convenience:
+
+```powershell
+# PowerShell profile
+function ghp { $env:GH_CONFIG_DIR = "$HOME/.config/gh-public"; gh @args; Remove-Item Env:\GH_CONFIG_DIR }
+function ghe { gh @args }  # Default EMU
+
+# Usage:
+# ghp repo clone personaluser/repo   # Uses personal account
+# ghe issue list                       # Uses EMU account
+```
+
+```bash
+# Bash/Zsh profile
+alias ghp='GH_CONFIG_DIR=~/.config/gh-public gh'
+alias ghe='gh'
+
+# Usage:
+# ghp repo clone personaluser/repo
+# ghe issue list
+```
+
+## Examples
+
+### ✓ Correct: Agent pushes blog post to personal GitHub Pages
+
+```powershell
+# Agent needs to push to personaluser.github.io (personal repo)
+# Default gh auth is corpalias_enterprise (EMU)
+
+$token = gh auth token --user personaluser
+git remote set-url origin https://personaluser:$token@github.com/personaluser/personaluser.github.io.git
+git push origin main
+
+# Clean up — don't leave token in remote URL
+git remote set-url origin https://github.com/personaluser/personaluser.github.io.git
+```
+
+### ✓ Correct: Agent creates a PR from personal fork to upstream
+
+```powershell
+# Fork: personaluser/squad, Upstream: bradygaster/squad
+# Agent is on branch contrib/fix-docs in the fork clone
+
+git push origin contrib/fix-docs  # Pushes to fork (may need token auth)
+
+# Create PR targeting upstream
+gh pr create --repo bradygaster/squad --head personaluser:contrib/fix-docs `
+  --title "docs: fix installation guide" `
+  --body "Fixes #123"
+```
+
+### ✗ Incorrect: Blindly pushing with wrong account
+
+```bash
+# BAD: Agent assumes default gh auth works for personal repos
+git push origin main
+# ERROR: Permission denied — EMU account has no access to personal repo
+
+# BAD: Hardcoding tokens in scripts
+git push https://personaluser:ghp_xxxxxxxxxxxx@github.com/personaluser/repo.git main
+# SECURITY RISK: Token exposed in command history and process list
+```
+
+### ✓ Correct: Check before you push
+
+```bash
+# Always verify which account has access before operations
+gh auth status
+# If wrong account, use token extraction:
+$token = gh auth token --user personaluser
+git push https://personaluser:$token@github.com/personaluser/repo.git main
+```
+
+## Anti-Patterns
+
+- ❌ **Hardcoding tokens** in scripts, environment variables, or committed files. Use `gh auth token --user` to extract at runtime.
+- ❌ **Assuming the default `gh` auth works** for all repos. EMU accounts can't access personal repos and vice versa.
+- ❌ **Switching `gh auth login`** globally mid-session. This changes the default for ALL processes and can break parallel agents.
+- ❌ **Storing personal tokens in `.env`** or `.squad/` files. These get committed by Scribe. Use `gh`'s credential store.
+- ❌ **Ignoring token cleanup** after inline HTTPS pushes. Always reset the remote URL to avoid persisting tokens.
+- ❌ **Using `gh auth switch`** in multi-agent sessions. One agent switching affects all others sharing the shell.
+- ❌ **Mixing EMU and personal operations** in the same git clone. Use separate clones or explicit remote URLs per operation.

package/templates/skills/humanizer/SKILL.md

@@ -1,105 +1,105 @@
----
-name: "humanizer"
-description: "Tone enforcement patterns for external-facing community responses"
-domain: "communication, tone, community"
-confidence: "low"
-source: "manual (RFC #426 — PAO External Communications)"
----
-
-## Context
-
-Use this skill whenever PAO drafts external-facing responses for issues or discussions.
-
-- Tone must be warm, helpful, and human-sounding — never robotic or corporate.
-- Brady's constraint applies everywhere: **Humanized tone is mandatory**.
-- This applies to **all external-facing content** drafted by PAO in Phase 1 issues/discussions workflows.
-
-## Patterns
-
-1. **Warm opening** — Start with acknowledgment ("Thanks for reporting this", "Great question!")
-2. **Active voice** — "We're looking into this" not "This is being investigated"
-3. **Second person** — Address the person directly ("you" not "the user")
-4. **Conversational connectors** — "That said...", "Here's what we found...", "Quick note:"
-5. **Specific, not vague** — "This affects the casting module in v0.8.x" not "We are aware of issues"
-6. **Empathy markers** — "I can see how that would be frustrating", "Good catch!"
-7. **Action-oriented closes** — "Let us know if that helps!" not "Please advise if further assistance is required"
-8. **Uncertainty is OK** — "We're not 100% sure yet, but here's what we think is happening..." is better than false confidence
-9. **Profanity filter** — Never include profanity, slurs, or aggressive language, even when quoting
-10. **Baseline comparison** — Responses should align with tone of 5-10 "gold standard" responses (>80% similarity threshold)
-11. **Empathetic disagreement** — "We hear you. That's a fair concern." before explaining the reasoning
-12. **Information request** — Ask for specific details, not open-ended "can you provide more info?"
-13. **No link-dumping** — Don't just paste URLs. Provide context: "Check out the [getting started guide](url) — specifically the section on routing" not just a bare link
-
-## Examples
-
-### 1. Welcome
-
-```text
-Hey {author}! Welcome to Squad 👋 Thanks for opening this.
-{substantive response}
-Let us know if you have questions — happy to help!
-```
-
-### 2. Troubleshooting
-
-```text
-Thanks for the detailed report, {author}!
-Here's what we think is happening: {explanation}
-{steps or workaround}
-Let us know if that helps, or if you're seeing something different.
-```
-
-### 3. Feature guidance
-
-```text
-Great question! {context on current state}
-{guidance or workaround}
-We've noted this as a potential improvement — {tracking info if applicable}.
-```
-
-### 4. Redirect
-
-```text
-Thanks for reaching out! This one is actually better suited for {correct location}.
-{brief explanation of why}
-Feel free to open it there — they'll be able to help!
-```
-
-### 5. Acknowledgment
-
-```text
-Good catch, {author}. We've confirmed this is a real issue.
-{what we know so far}
-We'll update this thread when we have a fix. Thanks for flagging it!
-```
-
-### 6. Closing
-
-```text
-This should be resolved in {version/PR}! 🎉
-{brief summary of what changed}
-Thanks for reporting this, {author} — it made Squad better.
-```
-
-### 7. Technical uncertainty
-
-```text
-Interesting find, {author}. We're not 100% sure what's causing this yet.
-Here's what we've ruled out: {list}
-We'd love more context if you have it — {specific ask}.
-We'll dig deeper and update this thread.
-```
-
-## Anti-Patterns
-
-- ❌ Corporate speak: "We appreciate your patience as we investigate this matter"
-- ❌ Marketing hype: "Squad is the BEST way to..." or "This amazing feature..."
-- ❌ Passive voice: "It has been determined that..." or "The issue is being tracked"
-- ❌ Dismissive: "This works as designed" without empathy
-- ❌ Over-promising: "We'll ship this next week" without commitment from the team
-- ❌ Empty acknowledgment: "Thanks for your feedback" with no substance
-- ❌ Robot signatures: "Best regards, PAO" or "Sincerely, The Squad Team"
-- ❌ Excessive emoji: More than 1-2 emoji per response
-- ❌ Quoting profanity: Even when the original issue contains it, paraphrase instead
-- ❌ Link-dumping: Pasting URLs without context ("See: https://...")
-- ❌ Open-ended info requests: "Can you provide more information?" without specifying what information
+---
+name: "humanizer"
+description: "Tone enforcement patterns for external-facing community responses"
+domain: "communication, tone, community"
+confidence: "low"
+source: "manual (RFC #426 — PAO External Communications)"
+---
+
+## Context
+
+Use this skill whenever PAO drafts external-facing responses for issues or discussions.
+
+- Tone must be warm, helpful, and human-sounding — never robotic or corporate.
+- Brady's constraint applies everywhere: **Humanized tone is mandatory**.
+- This applies to **all external-facing content** drafted by PAO in Phase 1 issues/discussions workflows.
+
+## Patterns
+
+1. **Warm opening** — Start with acknowledgment ("Thanks for reporting this", "Great question!")
+2. **Active voice** — "We're looking into this" not "This is being investigated"
+3. **Second person** — Address the person directly ("you" not "the user")
+4. **Conversational connectors** — "That said...", "Here's what we found...", "Quick note:"
+5. **Specific, not vague** — "This affects the casting module in v0.8.x" not "We are aware of issues"
+6. **Empathy markers** — "I can see how that would be frustrating", "Good catch!"
+7. **Action-oriented closes** — "Let us know if that helps!" not "Please advise if further assistance is required"
+8. **Uncertainty is OK** — "We're not 100% sure yet, but here's what we think is happening..." is better than false confidence
+9. **Profanity filter** — Never include profanity, slurs, or aggressive language, even when quoting
+10. **Baseline comparison** — Responses should align with tone of 5-10 "gold standard" responses (>80% similarity threshold)
+11. **Empathetic disagreement** — "We hear you. That's a fair concern." before explaining the reasoning
+12. **Information request** — Ask for specific details, not open-ended "can you provide more info?"
+13. **No link-dumping** — Don't just paste URLs. Provide context: "Check out the [getting started guide](url) — specifically the section on routing" not just a bare link
+
+## Examples
+
+### 1. Welcome
+
+```text
+Hey {author}! Welcome to Squad 👋 Thanks for opening this.
+{substantive response}
+Let us know if you have questions — happy to help!
+```
+
+### 2. Troubleshooting
+
+```text
+Thanks for the detailed report, {author}!
+Here's what we think is happening: {explanation}
+{steps or workaround}
+Let us know if that helps, or if you're seeing something different.
+```
+
+### 3. Feature guidance
+
+```text
+Great question! {context on current state}
+{guidance or workaround}
+We've noted this as a potential improvement — {tracking info if applicable}.
+```
+
+### 4. Redirect
+
+```text
+Thanks for reaching out! This one is actually better suited for {correct location}.
+{brief explanation of why}
+Feel free to open it there — they'll be able to help!
+```
+
+### 5. Acknowledgment
+
+```text
+Good catch, {author}. We've confirmed this is a real issue.
+{what we know so far}
+We'll update this thread when we have a fix. Thanks for flagging it!
+```
+
+### 6. Closing
+
+```text
+This should be resolved in {version/PR}! 🎉
+{brief summary of what changed}
+Thanks for reporting this, {author} — it made Squad better.
+```
+
+### 7. Technical uncertainty
+
+```text
+Interesting find, {author}. We're not 100% sure what's causing this yet.
+Here's what we've ruled out: {list}
+We'd love more context if you have it — {specific ask}.
+We'll dig deeper and update this thread.
+```
+
+## Anti-Patterns
+
+- ❌ Corporate speak: "We appreciate your patience as we investigate this matter"
+- ❌ Marketing hype: "Squad is the BEST way to..." or "This amazing feature..."
+- ❌ Passive voice: "It has been determined that..." or "The issue is being tracked"
+- ❌ Dismissive: "This works as designed" without empathy
+- ❌ Over-promising: "We'll ship this next week" without commitment from the team
+- ❌ Empty acknowledgment: "Thanks for your feedback" with no substance
+- ❌ Robot signatures: "Best regards, PAO" or "Sincerely, The Squad Team"
+- ❌ Excessive emoji: More than 1-2 emoji per response
+- ❌ Quoting profanity: Even when the original issue contains it, paraphrase instead
+- ❌ Link-dumping: Pasting URLs without context ("See: https://...")
+- ❌ Open-ended info requests: "Can you provide more information?" without specifying what information