@bradygaster/squad-sdk 0.9.0 → 0.9.1

package/templates/skills/git-workflow/SKILL.md

@@ -1,204 +1,204 @@
----
-name: "git-workflow"
-description: "Squad branching model: dev-first workflow with insiders preview channel"
-domain: "version-control"
-confidence: "high"
-source: "team-decision"
----
-
-## Context
-
-Squad uses a three-branch model. **All feature work starts from `dev`, not `main`.**
-
-| Branch | Purpose | Publishes |
-|--------|---------|-----------|
-| `main` | Released, tagged, in-npm code only | `npm publish` on tag |
-| `dev` | Integration branch — all feature work lands here | `npm publish --tag preview` on merge |
-| `insiders` | Early-access channel — synced from dev | `npm publish --tag insiders` on sync |
-
-## Branch Naming Convention
-
-Issue branches MUST use: `squad/{issue-number}-{kebab-case-slug}`
-
-Examples:
-- `squad/195-fix-version-stamp-bug`
-- `squad/42-add-profile-api`
-
-## Workflow for Issue Work
-
-1. **Branch from dev:**
-   ```bash
-   git checkout dev
-   git pull origin dev
-   git checkout -b squad/{issue-number}-{slug}
-   ```
-
-2. **Mark issue in-progress:**
-   ```bash
-   gh issue edit {number} --add-label "status:in-progress"
-   ```
-
-3. **Create draft PR targeting dev:**
-   ```bash
-   gh pr create --base dev --title "{description}" --body "Closes #{issue-number}" --draft
-   ```
-
-4. **Do the work.** Make changes, write tests, commit with issue reference.
-
-5. **Push and mark ready:**
-   ```bash
-   git push -u origin squad/{issue-number}-{slug}
-   gh pr ready
-   ```
-
-6. **After merge to dev:**
-   ```bash
-   git checkout dev
-   git pull origin dev
-   git branch -d squad/{issue-number}-{slug}
-   git push origin --delete squad/{issue-number}-{slug}
-   ```
-
-## Parallel Multi-Issue Work (Worktrees)
-
-When the coordinator routes multiple issues simultaneously (e.g., "fix bugs X, Y, and Z"), use `git worktree` to give each agent an isolated working directory. No filesystem collisions, no branch-switching overhead.
-
-### When to Use Worktrees vs Sequential
-
-| Scenario | Strategy |
-|----------|----------|
-| Single issue | Standard workflow above — no worktree needed |
-| 2+ simultaneous issues in same repo | Worktrees — one per issue |
-| Work spanning multiple repos | Separate clones as siblings (see Multi-Repo below) |
-
-### Setup
-
-From the main clone (must be on dev or any branch):
-
-```bash
-# Ensure dev is current
-git fetch origin dev
-
-# Create a worktree per issue — siblings to the main clone
-git worktree add ../squad-195 -b squad/195-fix-stamp-bug origin/dev
-git worktree add ../squad-193 -b squad/193-refactor-loader origin/dev
-```
-
-**Naming convention:** `../{repo-name}-{issue-number}` (e.g., `../squad-195`, `../squad-pr-42`).
-
-Each worktree:
-- Has its own working directory and index
-- Is on its own `squad/{issue-number}-{slug}` branch from dev
-- Shares the same `.git` object store (disk-efficient)
-
-### Per-Worktree Agent Workflow
-
-Each agent operates inside its worktree exactly like the single-issue workflow:
-
-```bash
-cd ../squad-195
-
-# Work normally — commits, tests, pushes
-git add -A && git commit -m "fix: stamp bug (#195)"
-git push -u origin squad/195-fix-stamp-bug
-
-# Create PR targeting dev
-gh pr create --base dev --title "fix: stamp bug" --body "Closes #195" --draft
-```
-
-All PRs target `dev` independently. Agents never interfere with each other's filesystem.
-
-### .squad/ State in Worktrees
-
-The `.squad/` directory exists in each worktree as a copy. This is safe because:
-- `.gitattributes` declares `merge=union` on append-only files (history.md, decisions.md, logs)
-- Each agent appends to its own section; union merge reconciles on PR merge to dev
-- **Rule:** Never rewrite or reorder `.squad/` files in a worktree — append only
-
-### Cleanup After Merge
-
-After a worktree's PR is merged to dev:
-
-```bash
-# From the main clone
-git worktree remove ../squad-195
-git worktree prune          # clean stale metadata
-git branch -d squad/195-fix-stamp-bug
-git push origin --delete squad/195-fix-stamp-bug
-```
-
-If a worktree was deleted manually (rm -rf), `git worktree prune` recovers the state.
-
----
-
-## Multi-Repo Downstream Scenarios
-
-When work spans multiple repositories (e.g., squad-cli changes need squad-sdk changes, or a user's app depends on squad):
-
-### Setup
-
-Clone downstream repos as siblings to the main repo:
-
-```
-~/work/
-  squad-pr/          # main repo
-  squad-sdk/         # downstream dependency
-  user-app/          # consumer project
-```
-
-Each repo gets its own issue branch following its own naming convention. If the downstream repo also uses Squad conventions, use `squad/{issue-number}-{slug}`.
-
-### Coordinated PRs
-
-- Create PRs in each repo independently
-- Link them in PR descriptions:
-  ```
-  Closes #42
-
-  **Depends on:** squad-sdk PR #17 (squad-sdk changes required for this feature)
-  ```
-- Merge order: dependencies first (e.g., squad-sdk), then dependents (e.g., squad-cli)
-
-### Local Linking for Testing
-
-Before pushing, verify cross-repo changes work together:
-
-```bash
-# Node.js / npm
-cd ../squad-sdk && npm link
-cd ../squad-pr && npm link squad-sdk
-
-# Go
-# Use replace directive in go.mod:
-# replace github.com/org/squad-sdk => ../squad-sdk
-
-# Python
-cd ../squad-sdk && pip install -e .
-```
-
-**Important:** Remove local links before committing. `npm link` and `go replace` are dev-only — CI must use published packages or PR-specific refs.
-
-### Worktrees + Multi-Repo
-
-These compose naturally. You can have:
-- Multiple worktrees in the main repo (parallel issues)
-- Separate clones for downstream repos
-- Each combination operates independently
-
----
-
-## Anti-Patterns
-
-- ❌ Branching from main (branch from dev)
-- ❌ PR targeting main directly (target dev)
-- ❌ Non-conforming branch names (must be squad/{number}-{slug})
-- ❌ Committing directly to main or dev (use PRs)
-- ❌ Switching branches in the main clone while worktrees are active (use worktrees instead)
-- ❌ Using worktrees for cross-repo work (use separate clones)
-- ❌ Leaving stale worktrees after PR merge (clean up immediately)
-
-## Promotion Pipeline
-
-- dev → insiders: Automated sync on green build
-- dev → main: Manual merge when ready for stable release, then tag
-- Hotfixes: Branch from main as `hotfix/{slug}`, PR to dev, cherry-pick to main if urgent
+---
+name: "git-workflow"
+description: "Squad branching model: dev-first workflow with insiders preview channel"
+domain: "version-control"
+confidence: "high"
+source: "team-decision"
+---
+
+## Context
+
+Squad uses a three-branch model. **All feature work starts from `dev`, not `main`.**
+
+| Branch | Purpose | Publishes |
+|--------|---------|-----------|
+| `main` | Released, tagged, in-npm code only | `npm publish` on tag |
+| `dev` | Integration branch — all feature work lands here | `npm publish --tag preview` on merge |
+| `insiders` | Early-access channel — synced from dev | `npm publish --tag insiders` on sync |
+
+## Branch Naming Convention
+
+Issue branches MUST use: `squad/{issue-number}-{kebab-case-slug}`
+
+Examples:
+- `squad/195-fix-version-stamp-bug`
+- `squad/42-add-profile-api`
+
+## Workflow for Issue Work
+
+1. **Branch from dev:**
+   ```bash
+   git checkout dev
+   git pull origin dev
+   git checkout -b squad/{issue-number}-{slug}
+   ```
+
+2. **Mark issue in-progress:**
+   ```bash
+   gh issue edit {number} --add-label "status:in-progress"
+   ```
+
+3. **Create draft PR targeting dev:**
+   ```bash
+   gh pr create --base dev --title "{description}" --body "Closes #{issue-number}" --draft
+   ```
+
+4. **Do the work.** Make changes, write tests, commit with issue reference.
+
+5. **Push and mark ready:**
+   ```bash
+   git push -u origin squad/{issue-number}-{slug}
+   gh pr ready
+   ```
+
+6. **After merge to dev:**
+   ```bash
+   git checkout dev
+   git pull origin dev
+   git branch -d squad/{issue-number}-{slug}
+   git push origin --delete squad/{issue-number}-{slug}
+   ```
+
+## Parallel Multi-Issue Work (Worktrees)
+
+When the coordinator routes multiple issues simultaneously (e.g., "fix bugs X, Y, and Z"), use `git worktree` to give each agent an isolated working directory. No filesystem collisions, no branch-switching overhead.
+
+### When to Use Worktrees vs Sequential
+
+| Scenario | Strategy |
+|----------|----------|
+| Single issue | Standard workflow above — no worktree needed |
+| 2+ simultaneous issues in same repo | Worktrees — one per issue |
+| Work spanning multiple repos | Separate clones as siblings (see Multi-Repo below) |
+
+### Setup
+
+From the main clone (must be on dev or any branch):
+
+```bash
+# Ensure dev is current
+git fetch origin dev
+
+# Create a worktree per issue — siblings to the main clone
+git worktree add ../squad-195 -b squad/195-fix-stamp-bug origin/dev
+git worktree add ../squad-193 -b squad/193-refactor-loader origin/dev
+```
+
+**Naming convention:** `../{repo-name}-{issue-number}` (e.g., `../squad-195`, `../squad-pr-42`).
+
+Each worktree:
+- Has its own working directory and index
+- Is on its own `squad/{issue-number}-{slug}` branch from dev
+- Shares the same `.git` object store (disk-efficient)
+
+### Per-Worktree Agent Workflow
+
+Each agent operates inside its worktree exactly like the single-issue workflow:
+
+```bash
+cd ../squad-195
+
+# Work normally — commits, tests, pushes
+git add -A && git commit -m "fix: stamp bug (#195)"
+git push -u origin squad/195-fix-stamp-bug
+
+# Create PR targeting dev
+gh pr create --base dev --title "fix: stamp bug" --body "Closes #195" --draft
+```
+
+All PRs target `dev` independently. Agents never interfere with each other's filesystem.
+
+### .squad/ State in Worktrees
+
+The `.squad/` directory exists in each worktree as a copy. This is safe because:
+- `.gitattributes` declares `merge=union` on append-only files (history.md, decisions.md, logs)
+- Each agent appends to its own section; union merge reconciles on PR merge to dev
+- **Rule:** Never rewrite or reorder `.squad/` files in a worktree — append only
+
+### Cleanup After Merge
+
+After a worktree's PR is merged to dev:
+
+```bash
+# From the main clone
+git worktree remove ../squad-195
+git worktree prune          # clean stale metadata
+git branch -d squad/195-fix-stamp-bug
+git push origin --delete squad/195-fix-stamp-bug
+```
+
+If a worktree was deleted manually (rm -rf), `git worktree prune` recovers the state.
+
+---
+
+## Multi-Repo Downstream Scenarios
+
+When work spans multiple repositories (e.g., squad-cli changes need squad-sdk changes, or a user's app depends on squad):
+
+### Setup
+
+Clone downstream repos as siblings to the main repo:
+
+```
+~/work/
+  squad-pr/          # main repo
+  squad-sdk/         # downstream dependency
+  user-app/          # consumer project
+```
+
+Each repo gets its own issue branch following its own naming convention. If the downstream repo also uses Squad conventions, use `squad/{issue-number}-{slug}`.
+
+### Coordinated PRs
+
+- Create PRs in each repo independently
+- Link them in PR descriptions:
+  ```
+  Closes #42
+
+  **Depends on:** squad-sdk PR #17 (squad-sdk changes required for this feature)
+  ```
+- Merge order: dependencies first (e.g., squad-sdk), then dependents (e.g., squad-cli)
+
+### Local Linking for Testing
+
+Before pushing, verify cross-repo changes work together:
+
+```bash
+# Node.js / npm
+cd ../squad-sdk && npm link
+cd ../squad-pr && npm link squad-sdk
+
+# Go
+# Use replace directive in go.mod:
+# replace github.com/org/squad-sdk => ../squad-sdk
+
+# Python
+cd ../squad-sdk && pip install -e .
+```
+
+**Important:** Remove local links before committing. `npm link` and `go replace` are dev-only — CI must use published packages or PR-specific refs.
+
+### Worktrees + Multi-Repo
+
+These compose naturally. You can have:
+- Multiple worktrees in the main repo (parallel issues)
+- Separate clones for downstream repos
+- Each combination operates independently
+
+---
+
+## Anti-Patterns
+
+- ❌ Branching from main (branch from dev)
+- ❌ PR targeting main directly (target dev)
+- ❌ Non-conforming branch names (must be squad/{number}-{slug})
+- ❌ Committing directly to main or dev (use PRs)
+- ❌ Switching branches in the main clone while worktrees are active (use worktrees instead)
+- ❌ Using worktrees for cross-repo work (use separate clones)
+- ❌ Leaving stale worktrees after PR merge (clean up immediately)
+
+## Promotion Pipeline
+
+- dev → insiders: Automated sync on green build
+- dev → main: Manual merge when ready for stable release, then tag
+- Hotfixes: Branch from main as `hotfix/{slug}`, PR to dev, cherry-pick to main if urgent

package/templates/skills/github-multi-account/SKILL.md

@@ -1,95 +1,95 @@
----
-name: github-multi-account
-description: Detect and set up account-locked gh aliases for multi-account GitHub. The AI reads this skill, detects accounts, asks the user which is personal/work, and runs the setup automatically.
-confidence: high
-source: https://github.com/tamirdresher/squad-skills/tree/main/plugins/github-multi-account
-author: tamirdresher
----
-
-# GitHub Multi-Account — AI-Driven Setup
-
-## When to Activate
-When the user has multiple GitHub accounts (check with `gh auth status`). If you see 2+ accounts listed, this skill applies.
-
-## What to Do (as the AI agent)
-
-### Step 1: Detect accounts
-Run: `gh auth status`
-Look for multiple accounts. Note which usernames are listed.
-
-### Step 2: Ask the user
-Ask: "I see you have multiple GitHub accounts: {list them}. Which one is your personal account and which is your work/EMU account?"
-
-### Step 3: Run the setup automatically
-Once the user confirms, do ALL of this for them:
-
-```powershell
-# 1. Define the functions
-$personal = "THEIR_PERSONAL_USERNAME"
-$work = "THEIR_WORK_USERNAME"
-
-# 2. Add to PowerShell profile
-$profilePath = $PROFILE.CurrentUserAllHosts
-if (!(Test-Path $profilePath)) { New-Item -Path $profilePath -Force | Out-Null }
-$existing = Get-Content $profilePath -Raw -ErrorAction SilentlyContinue
-if ($existing -notmatch "gh-personal") {
-    $block = @"
-
-# === GitHub Multi-Account Aliases ===
-function gh-personal { gh auth switch --user $personal 2>`$null | Out-Null; gh @args }
-function gh-work { gh auth switch --user $work 2>`$null | Out-Null; gh @args }
-Set-Alias ghp gh-personal
-Set-Alias ghw gh-work
-"@
-    Add-Content -Path $profilePath -Value $block
-}
-
-# 3. Create CMD wrappers
-$binDir = Join-Path $env:USERPROFILE ".squad\bin"
-if (!(Test-Path $binDir)) { New-Item -ItemType Directory -Path $binDir -Force | Out-Null }
-"@echo off`ngh auth switch --user $personal >nul 2>&1`ngh %*" | Out-File "$binDir\ghp.cmd" -Encoding ascii
-"@echo off`ngh auth switch --user $work >nul 2>&1`ngh %*" | Out-File "$binDir\ghw.cmd" -Encoding ascii
-
-# 4. Add to PATH
-$userPath = [Environment]::GetEnvironmentVariable("PATH", "User")
-if ($userPath -notmatch [regex]::Escape($binDir)) {
-    [Environment]::SetEnvironmentVariable("PATH", "$binDir;$userPath", "User")
-    $env:PATH = "$binDir;$env:PATH"
-}
-
-# 5. Load in current session
-function gh-personal { gh auth switch --user $personal 2>$null | Out-Null; gh @args }
-function gh-work { gh auth switch --user $work 2>$null | Out-Null; gh @args }
-Set-Alias ghp gh-personal
-Set-Alias ghw gh-work
-```
-
-### Step 4: Verify for the user
-Run these and show the results:
-```powershell
-ghp api user --jq '.login'   # should show personal username
-ghw api user --jq '.login'   # should show work username
-```
-
-### Step 5: Tell the user
-"All set! From now on use `ghp` for personal repos and `ghw` for work repos. I'll use them too."
-
-## After Setup — Usage Rules
-
-1. **NEVER** use bare `gh` for repo operations — always `ghp` or `ghw`
-2. **NEVER** manually `gh auth switch` — the aliases handle it
-3. Determine alias by repo owner:
-   - Personal account repos → `ghp` / `gh-personal`
-   - Work/EMU account repos → `ghw` / `gh-work`
-
-## Repo-Specific Account Binding
-
-This repo (`bradygaster/squad`) is bound to the **bradygaster** (personal) account.
-All `gh` operations in this repo MUST use `ghp` / `gh-personal`.
-
-## For Squad Agents
-At the TOP of any script touching GitHub, define:
-```powershell
-function gh-personal { gh auth switch --user bradygaster 2>$null | Out-Null; gh @args }
-function gh-work { gh auth switch --user bradyg_microsoft 2>$null | Out-Null; gh @args }
-```
+---
+name: github-multi-account
+description: Detect and set up account-locked gh aliases for multi-account GitHub. The AI reads this skill, detects accounts, asks the user which is personal/work, and runs the setup automatically.
+confidence: high
+source: https://github.com/tamirdresher/squad-skills/tree/main/plugins/github-multi-account
+author: tamirdresher
+---
+
+# GitHub Multi-Account — AI-Driven Setup
+
+## When to Activate
+When the user has multiple GitHub accounts (check with `gh auth status`). If you see 2+ accounts listed, this skill applies.
+
+## What to Do (as the AI agent)
+
+### Step 1: Detect accounts
+Run: `gh auth status`
+Look for multiple accounts. Note which usernames are listed.
+
+### Step 2: Ask the user
+Ask: "I see you have multiple GitHub accounts: {list them}. Which one is your personal account and which is your work/EMU account?"
+
+### Step 3: Run the setup automatically
+Once the user confirms, do ALL of this for them:
+
+```powershell
+# 1. Define the functions
+$personal = "THEIR_PERSONAL_USERNAME"
+$work = "THEIR_WORK_USERNAME"
+
+# 2. Add to PowerShell profile
+$profilePath = $PROFILE.CurrentUserAllHosts
+if (!(Test-Path $profilePath)) { New-Item -Path $profilePath -Force | Out-Null }
+$existing = Get-Content $profilePath -Raw -ErrorAction SilentlyContinue
+if ($existing -notmatch "gh-personal") {
+    $block = @"
+
+# === GitHub Multi-Account Aliases ===
+function gh-personal { gh auth switch --user $personal 2>`$null | Out-Null; gh @args }
+function gh-work { gh auth switch --user $work 2>`$null | Out-Null; gh @args }
+Set-Alias ghp gh-personal
+Set-Alias ghw gh-work
+"@
+    Add-Content -Path $profilePath -Value $block
+}
+
+# 3. Create CMD wrappers
+$binDir = Join-Path $env:USERPROFILE ".squad\bin"
+if (!(Test-Path $binDir)) { New-Item -ItemType Directory -Path $binDir -Force | Out-Null }
+"@echo off`ngh auth switch --user $personal >nul 2>&1`ngh %*" | Out-File "$binDir\ghp.cmd" -Encoding ascii
+"@echo off`ngh auth switch --user $work >nul 2>&1`ngh %*" | Out-File "$binDir\ghw.cmd" -Encoding ascii
+
+# 4. Add to PATH
+$userPath = [Environment]::GetEnvironmentVariable("PATH", "User")
+if ($userPath -notmatch [regex]::Escape($binDir)) {
+    [Environment]::SetEnvironmentVariable("PATH", "$binDir;$userPath", "User")
+    $env:PATH = "$binDir;$env:PATH"
+}
+
+# 5. Load in current session
+function gh-personal { gh auth switch --user $personal 2>$null | Out-Null; gh @args }
+function gh-work { gh auth switch --user $work 2>$null | Out-Null; gh @args }
+Set-Alias ghp gh-personal
+Set-Alias ghw gh-work
+```
+
+### Step 4: Verify for the user
+Run these and show the results:
+```powershell
+ghp api user --jq '.login'   # should show personal username
+ghw api user --jq '.login'   # should show work username
+```
+
+### Step 5: Tell the user
+"All set! From now on use `ghp` for personal repos and `ghw` for work repos. I'll use them too."
+
+## After Setup — Usage Rules
+
+1. **NEVER** use bare `gh` for repo operations — always `ghp` or `ghw`
+2. **NEVER** manually `gh auth switch` — the aliases handle it
+3. Determine alias by repo owner:
+   - Personal account repos → `ghp` / `gh-personal`
+   - Work/EMU account repos → `ghw` / `gh-work`
+
+## Repo-Specific Account Binding
+
+This repo (`bradygaster/squad`) is bound to the **bradygaster** (personal) account.
+All `gh` operations in this repo MUST use `ghp` / `gh-personal`.
+
+## For Squad Agents
+At the TOP of any script touching GitHub, define:
+```powershell
+function gh-personal { gh auth switch --user bradygaster 2>$null | Out-Null; gh @args }
+function gh-work { gh auth switch --user bradyg_microsoft 2>$null | Out-Null; gh @args }
+```

package/templates/skills/history-hygiene/SKILL.md

@@ -1,36 +1,36 @@
----
-name: history-hygiene
-description: Record final outcomes to history.md, not intermediate requests or reversed decisions
-domain: documentation, team-collaboration
-confidence: high
-source: earned (Kobayashi v0.6.0 incident, team intervention)
----
-
-## Context
-
-History files (.md files tracking decisions, spawns, outcomes) are read cold by future agents. Stale or incorrect entries poison decision-making downstream. The Kobayashi incident proved this: history said "Brady decided v0.6.0" when Brady had reversed that to v0.8.17. Future spawns read the wrong truth and repeated the mistake.
-
-## Patterns
-
-- **Record the final outcome**, not the initial request.
-- **Wait for confirmation** before writing to history — don't log intermediate states.
-- **If a decision reverses**, update the entry immediately — don't leave stale data.
-- **One read = one truth.** A future agent should never need to cross-reference other files to understand what actually happened.
-
-## Examples
-
-✓ **Correct:**
-- "Migration target: v0.8.17 (initially discussed as v0.6.0, corrected by Brady)"
-- "Reverted to Node 18 per Brady's explicit request on 2024-01-15"
-
-✗ **Incorrect:**
-- "Brady directed v0.6.0" (when later reversed)
-- Recording what was *requested* instead of what *actually happened*
-- Logging entries before outcome is confirmed
-
-## Anti-Patterns
-
-- Writing intermediate or "for now" states to disk
-- Attributing decisions without confirming final direction
-- Treating history like a draft — history is the source of truth
-- Assuming readers will cross-reference or verify; they won't
+---
+name: history-hygiene
+description: Record final outcomes to history.md, not intermediate requests or reversed decisions
+domain: documentation, team-collaboration
+confidence: high
+source: earned (Kobayashi v0.6.0 incident, team intervention)
+---
+
+## Context
+
+History files (.md files tracking decisions, spawns, outcomes) are read cold by future agents. Stale or incorrect entries poison decision-making downstream. The Kobayashi incident proved this: history said "Brady decided v0.6.0" when Brady had reversed that to v0.8.17. Future spawns read the wrong truth and repeated the mistake.
+
+## Patterns
+
+- **Record the final outcome**, not the initial request.
+- **Wait for confirmation** before writing to history — don't log intermediate states.
+- **If a decision reverses**, update the entry immediately — don't leave stale data.
+- **One read = one truth.** A future agent should never need to cross-reference other files to understand what actually happened.
+
+## Examples
+
+✓ **Correct:**
+- "Migration target: v0.8.17 (initially discussed as v0.6.0, corrected by Brady)"
+- "Reverted to Node 18 per Brady's explicit request on 2024-01-15"
+
+✗ **Incorrect:**
+- "Brady directed v0.6.0" (when later reversed)
+- Recording what was *requested* instead of what *actually happened*
+- Logging entries before outcome is confirmed
+
+## Anti-Patterns
+
+- Writing intermediate or "for now" states to disk
+- Attributing decisions without confirming final direction
+- Treating history like a draft — history is the source of truth
+- Assuming readers will cross-reference or verify; they won't