@mizyoel/mercury-mesh 0.9.4

package/.copilot/skills/economy-mode/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: "economy-mode"
+description: "Shifts Layer 3 model selection to cost-optimized alternatives when economy mode is active."
+---
+
+## SCOPE
+
+✅ THIS SKILL PRODUCES:
+- A modified Layer 3 model selection table applied when economy mode is active
+- `economyMode: true` written to `.mesh/config.json` when activated persistently
+- Spawn acknowledgments with `💰` indicator when economy mode is active
+
+❌ THIS SKILL DOES NOT PRODUCE:
+- Code, tests, or documentation
+- Cost reports or billing artifacts
+- Changes to Layer 0, Layer 1, or Layer 2 resolution (user intent always wins)
+
+## Context
+
+Economy mode shifts Layer 3 (Task-Aware Auto-Selection) to lower-cost alternatives. It does NOT override persistent config (`defaultModels`, `defaultModel`, `agentModelOverrides`) or per-agent charter preferences — those represent explicit user intent and always take priority. Economy routes must come from config rather than hardcoded model IDs.
+
+Use this skill when the user wants to reduce costs across an entire session or permanently, without manually specifying models for each agent.
+
+## Activation Methods
+
+| Method | How |
+|--------|-----|
+| Session phrase | "use economy mode", "save costs", "go cheap", "reduce costs" |
+| Persistent config | `"economyMode": true` in `.mesh/config.json` |
+| CLI flag | `Mercury Mesh --economy` |
+
+**Deactivation:** "turn off economy mode", "disable economy mode", or remove `economyMode` from `config.json`.
+
+## Economy Model Selection Table
+
+When economy mode is **active**, Layer 3 auto-selection uses `modelRouting.economy.taskTypes` and `modelRouting.economy.fallbacks` from config. If those keys are absent, reuse the normal `modelRouting` block rather than falling back to hardcoded model IDs.
+
+## AGENT WORKFLOW
+
+### On Session Start
+
+1. READ the active runtime config (`.mesh/config.json` or `.mesh/config.json`)
+2. CHECK for `economyMode: true` — if present, activate economy mode for the session
+3. STORE economy mode state in session context
+
+### On User Phrase Trigger
+
+**Session-only (no config change):** "use economy mode", "save costs", "go cheap"
+
+1. SET economy mode active for this session
+2. ACKNOWLEDGE: `✅ Economy mode active — using cost-optimized models this session. (Layer 0 and Layer 2 preferences still apply)`
+
+**Persistent:** "always use economy mode", "save economy mode"
+
+1. WRITE `economyMode: true` to the active `config.json` (merge, don't overwrite other fields)
+2. ACKNOWLEDGE: `✅ Economy mode saved — cost-optimized models will be used until disabled.`
+
+### On Every Agent Spawn (Economy Mode Active)
+
+1. CHECK Layer 0 first (`agentModelOverrides`, `defaultModels`, `defaultModel`) — if set, use that. Economy mode does NOT override Layer 0.
+2. CHECK Layer 1 (session directive for a specific model) — if set, use that. Economy mode does NOT override explicit session directives.
+3. CHECK Layer 2 (charter preference) — if set, use that. Economy mode does NOT override charter preferences.
+4. APPLY `modelRouting.economy` at Layer 3 instead of normal `modelRouting` when present.
+5. INCLUDE `💰` in spawn acknowledgment: `🔧 {Name} ({model} · 💰 economy) — {task}`
+
+### On Deactivation
+
+**Trigger phrases:** "turn off economy mode", "disable economy mode", "use normal models"
+
+1. REMOVE `economyMode` from the active `config.json` (if it was persisted)
+2. CLEAR session economy mode state
+3. ACKNOWLEDGE: `✅ Economy mode disabled — returning to standard model selection.`
+
+### STOP
+
+After updating economy mode state and including the `💰` indicator in spawn acknowledgments, this skill is done. Do NOT:
+- Change Layer 0, Layer 1, or Layer 2 model choices
+- Override charter-specified models
+- Generate cost reports or comparisons
+- Fall back to premium models via economy mode (economy mode never bumps UP)
+
+## Config Schema
+
+`.mesh/config.json` economy-related fields:
+
+```json
+{
+  "version": 1,
+  "economyMode": true
+}
+```
+
+- `economyMode` — when `true`, Layer 3 uses the economy table. Optional; absent = economy mode off.
+- Combines with `defaultModels`, `defaultModel`, and `agentModelOverrides` — Layer 0 always wins.
+
+## Anti-Patterns
+
+- **Don't override Layer 0 in economy mode.** If the user set `defaultModels: ["gpt-5.4", "claude-opus-4.6"]`, they want that chain honored. Economy mode only affects Layer 3 auto-selection.
+- **Don't silently apply economy mode.** Always acknowledge when activated or deactivated.
+- **Don't treat economy mode as permanent by default.** Session phrases activate session-only; only "always" or `config.json` persist it.
+- **Don't bump premium tasks down too far.** Architecture and security reviews shift from opus to sonnet in economy mode — they do NOT go to fast/cheap models.

package/.copilot/skills/external-comms/SKILL.md

@@ -0,0 +1,331 @@
+---
+name: "external-comms"
+description: "PAO workflow for scanning, drafting, and presenting community responses in Mercury Mesh voice with a human command gate"
+metadata:
+  domain: "community, communication, workflow"
+  confidence: "low"
+  source: "manual (RFC #426 — PAO External Communications)"
+  tools:
+    - name: "github-mcp-server-list_issues"
+      description: "List open issues for scan candidates and lightweight triage"
+      when: "Use for recent open issue scans before thread-level review"
+    - name: "github-mcp-server-issue_read"
+      description: "Read the full issue, comments, and labels before drafting"
+      when: "Use after selecting a candidate so PAO has complete thread context"
+    - name: "github-mcp-server-search_issues"
+      description: "Search for candidate issues or prior Mercury Mesh responses"
+      when: "Use when filtering by keywords, labels, or duplicate response checks"
+    - name: "gh CLI"
+      description: "Fallback for GitHub issue comments and discussions workflows"
+      when: "Use gh issue list/comment and gh api or gh api graphql when MCP coverage is incomplete"
+---
+
+## Context
+
+Phase 1 is **draft-only mode**.
+
+- PAO scans issues and discussions, drafts responses with the humanizer skill, and presents a review table for human approval.
+- **Human review gate is mandatory** — PAO never posts autonomously.
+- Every action is logged to `.mesh/comms/audit/`.
+- This workflow is triggered manually only ("PAO, check community") — no automated or Ralph-triggered activation in Phase 1.
+- The draft voice must obey `docs/brand-language.md` and `docs/persona-manifesto.md`: no apologies, no filler, direct telemetry, command-bridge cadence.
+
+## Patterns
+
+### 1. Scan
+
+Find unanswered community items with GitHub MCP tools first, or `gh issue list` / `gh api` as fallback for issues and discussions.
+
+- Include **open** issues and discussions only.
+- Filter for items with **no Mercury Mesh team response**.
+- Limit to items created in the last 7 days.
+- Exclude items labeled `Mercury Mesh:internal` or `wontfix`.
+- Include discussions **and** issues in the same sweep.
+- Phase 1 scope is **issues and discussions only** — do not draft PR replies.
+
+### Discussion Handling (Phase 1)
+
+Discussions use the GitHub Discussions API, which differs from issues:
+
+- **Scan:** `gh api /repos/{owner}/{repo}/discussions --jq '.[] | select(.answer_chosen_at == null)'` to find unanswered discussions
+- **Categories:** Filter by Q&A and General categories only (skip Announcements, Show and Tell)
+- **Answers vs comments:** In Q&A discussions, PAO drafts an "answer" (not a comment). The human marks it as accepted answer after posting.
+- **Phase 1 scope:** Issues and Discussions ONLY. No PR comments.
+
+### 2. Classify
+
+Determine the response type before drafting.
+
+- Welcome (new contributor)
+- Troubleshooting (bug/help)
+- Feature guidance (feature request/how-to)
+- Redirect (wrong repo/scope)
+- Acknowledgment (confirmed, no fix)
+- Closing (resolved)
+- Technical uncertainty (unknown cause)
+- Empathetic disagreement (pushback on a decision or design)
+- Information request (need more reproduction details or context)
+
+### Template Selection Guide
+
+| Signal in Issue/Discussion | → Response Type | Template |
+|---------------------------|-----------------|----------|
+| New contributor (0 prior issues) | Welcome | T1 |
+| Error message, stack trace, "doesn't work" | Troubleshooting | T2 |
+| "How do I...?", "Can Mercury Mesh...?", "Is there a way to...?" | Feature Guidance | T3 |
+| Wrong repo, out of scope for Mercury Mesh | Redirect | T4 |
+| Confirmed bug, no fix available yet | Acknowledgment | T5 |
+| Fix shipped, PR merged that resolves issue | Closing | T6 |
+| Unclear cause, needs investigation | Technical Uncertainty | T7 |
+| Author disagrees with a decision or design | Empathetic Disagreement | T8 |
+| Need more reproduction info or context | Information Request | T9 |
+
+Use exactly one template as the base draft. Replace placeholders with issue-specific details, then apply the humanizer patterns. If the thread spans multiple signals, choose the highest-risk template and capture the nuance in the thread summary.
+
+### Confidence Classification
+
+| Confidence | Criteria | Example |
+|-----------|----------|---------|
+| 🟢 High | Answer exists in Mercury Mesh docs or FAQ, similar question answered before, no technical ambiguity | "How do I install Mercury Mesh?" |
+| 🟡 Medium | Technical answer is sound but involves judgment calls, OR docs exist but don't perfectly match the question, OR tone is tricky | "Can Mercury Mesh work with Azure DevOps?" (yes, but setup is nuanced) |
+| 🔴 Needs Review | Technical uncertainty, policy/roadmap question, potential reputational risk, author is frustrated/angry, question about unreleased features | "When will Mercury Mesh support Claude?" |
+
+**Auto-escalation rules:**
+- Any mention of competitors → 🔴
+- Any mention of pricing/licensing → 🔴
+- Author has >3 follow-up comments without resolution → 🔴
+- Question references a closed-wontfix issue → 🔴
+
+### 3. Draft
+
+Use the humanizer skill for every draft.
+
+- Complete **Thread-Read Verification** before writing.
+- Read the **full thread**, including all comments, before writing.
+- Select the matching template from the **Template Selection Guide** and record the template ID in the review notes.
+- Treat templates as reusable drafting assets: keep the structure, replace placeholders, and only improvise when the thread truly requires it.
+- Validate the draft against the humanizer anti-patterns.
+- Flag long threads (`>10` comments) with `⚠️`.
+
+### Thread-Read Verification
+
+Before drafting, PAO MUST verify complete thread coverage:
+
+1. **Count verification:** Compare API comment count with actually-read comments. If mismatch, abort draft.
+2. **Deleted comment check:** Use `gh api` timeline to detect deleted comments. If found, flag as ⚠️ in review table.
+3. **Thread summary:** Include in every draft: "Thread: {N} comments, last activity {date}, {summary of key points}"
+4. **Long thread flag:** If >10 comments, add ⚠️ to review table and include condensed thread summary
+5. **Evidence line in review table:** Each draft row includes "Read: {N}/{total} comments" column
+
+### 4. Present
+
+Show drafts for review in this exact format:
+
+```text
+📝 PAO — Community Response Drafts
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+| # | Item | Author | Type | Confidence | Read | Preview |
+|---|------|--------|------|------------|------|---------|
+| 1 | Issue #N | @user | Type | 🟢/🟡/🔴 | N/N | "First words..." |
+
+Confidence: 🟢 High | 🟡 Medium | 🔴 Needs review
+
+Full drafts below ▼
+```
+
+Each full draft must begin with the thread summary line:
+`Thread: {N} comments, last activity {date}, {summary of key points}`
+
+### 5. Human Action
+
+Wait for explicit human direction before anything is posted.
+
+- `pao approve 1 3` — approve drafts 1 and 3
+- `pao edit 2` — edit draft 2
+- `pao skip` — skip all
+- `banana` — freeze all pending (safe word)
+
+### Rollback — Bad Post Recovery
+
+If a posted response turns out to be wrong, inappropriate, or needs correction:
+
+1. **Delete the comment:**
+   - Issues: `gh api -X DELETE /repos/{owner}/{repo}/issues/comments/{comment_id}`
+   - Discussions: `gh api graphql -f query='mutation { deleteDiscussionComment(input: {id: "{node_id}"}) { comment { id } } }'`
+2. **Log the deletion:** Write audit entry with action `delete`, include reason and original content
+3. **Draft replacement** (if needed): PAO drafts a corrected response, goes through normal review cycle
+4. **Postmortem:** If the error reveals a pattern gap, update humanizer anti-patterns or add a new test case
+
+**Safe word — `banana`:**
+- Immediately freezes all pending drafts in the review queue
+- No new scans or drafts until `pao resume` is issued
+- Audit entry logged with halter identity and reason
+
+### 6. Post
+
+After approval:
+
+- Human posts via `gh issue comment` for issues or `gh api` for discussion answers/comments.
+- PAO helps by preparing the CLI command.
+- Write the audit entry after the posting action.
+
+### 7. Audit
+
+Log every action.
+
+- Location: `.mesh/comms/audit/{timestamp}.md`
+- Required fields vary by action — see `.mesh/comms/templates/audit-entry.md` Conditional Fields table
+- Universal required fields: `timestamp`, `action`
+- All other fields are conditional on the action type
+
+## Examples
+
+These are reusable templates. Keep the structure, replace placeholders, and adjust only where the thread requires it.
+
+### Example scan command
+
+```bash
+gh issue list --state open --json number,title,author,labels,comments --limit 20
+```
+
+### Example review table
+
+```text
+📝 PAO — Community Response Drafts
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+| # | Item | Author | Type | Confidence | Read | Preview |
+|---|------|--------|------|------------|------|---------|
+| 1 | Issue #426 | @newdev | Welcome | 🟢 | 1/1 | "@newdev, signal received. Welcome aboard..." |
+| 2 | Discussion #18 | @builder | Feature guidance | 🟡 | 4/4 | "Vector received. Current CLI path..." |
+| 3 | Issue #431 ⚠️ | @debugger | Technical uncertainty | 🔴 | 12/12 | "Signal received, @debugger. Root cause..." |
+
+Confidence: 🟢 High | 🟡 Medium | 🔴 Needs review
+
+Full drafts below ▼
+```
+
+### Example audit entry (post action)
+
+```markdown
+---
+timestamp: "2026-03-16T21:30:00Z"
+action: "post"
+item_number: 426
+draft_id: 1
+reviewer: "@bradygaster"
+---
+
+## Context (draft, approve, edit, skip, post, delete actions)
+- Thread depth: 3
+- Response type: welcome
+- Confidence: 🟢
+- Long thread flag: false
+
+## Draft Content (draft, edit, post actions)
+Thread: 3 comments, last activity 2026-03-16, reporter hit a preview-build regression after install.
+
+@newdev, signal received. Welcome aboard.
+We reproduced the fault in preview builds. Regression point is under telemetry now.
+Transmit the command you ran right before the failure.
+
+## Post Result (post, delete actions)
+https://github.com/bradygaster/Mercury Mesh/issues/426#issuecomment-123456
+```
+
+### T1 — Welcome
+
+```text
+{author}, signal received. Welcome aboard.
+{specific acknowledgment or first answer}
+Telemetry remains open if the thread picks up drift.
+```
+
+### T2 — Troubleshooting
+
+```text
+Telemetry locked, {author}.
+Current read: {explanation}
+{steps or workaround}
+If the drift persists, transmit {specific ask}.
+```
+
+### T3 — Feature Guidance
+
+```text
+Vector received. {context on current state}
+{guidance or workaround}
+Queued on the flight path: {tracking info if applicable}.
+```
+
+### T4 — Redirect
+
+```text
+Routing correction, {author}. This belongs in {correct location}.
+{brief explanation of why}
+Open the thread there and carry this context forward: {handoff note}.
+```
+
+### T5 — Acknowledgment
+
+```text
+Confirmed, {author}. Real fault.
+{what we know so far}
+Patch is not in the burn yet. Telemetry will update here when it is.
+```
+
+### T6 — Closing
+
+```text
+Patch landed in {version/PR}.
+{brief summary of what changed}
+Re-enter the burn and confirm hull integrity.
+```
+
+### T7 — Technical Uncertainty
+
+```text
+Signal received, {author}. Root cause is still in the dark.
+Ruled out: {list}
+Transmit {specific ask}.
+That narrows the drift. Telemetry will update when the fault resolves.
+```
+
+### T8 — Empathetic Disagreement
+
+```text
+Signal received, {author}. The concern is valid.
+
+The current design holds because {reason}. It will not fit every use case.
+
+{what alternatives exist or what trade-off was made}
+
+If your use case breaks that geometry, open a discussion with the boundary conditions.
+```
+
+### T9 — Information Request
+
+```text
+Telemetry incomplete, {author}.
+
+Transmit:
+- {specific ask 1}
+- {specific ask 2}
+- {specific ask 3, if applicable}
+
+That signal is enough to narrow the fault.
+```
+
+## Anti-Patterns
+
+- ❌ Posting without human review (NEVER — this is the cardinal rule)
+- ❌ Drafting without reading full thread (context is everything)
+- ❌ Ignoring confidence flags (🔴 items need Flight/human review)
+- ❌ Scanning closed issues (only open items)
+- ❌ Responding to issues labeled `Mercury Mesh:internal` or `wontfix`
+- ❌ Skipping audit logging (every action must be recorded)
+- ❌ Drafting for issues where a Mercury Mesh member already responded (avoid duplicates)
+- ❌ Drafting pull request responses in Phase 1 (issues/discussions only)
+- ❌ Treating templates like loose examples instead of reusable drafting assets
+- ❌ Asking for more info without specific requests

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

@@ -0,0 +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 Mercury Mesh 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/Mercury Mesh, Upstream: bradygaster/Mercury Mesh
+# 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/Mercury Mesh --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 `.mesh/` 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.