@oxgeneral/orch 1.0.7 → 1.0.9

package/skills/library/unfreeze.md

@@ -0,0 +1,31 @@
+---
+name: unfreeze
+version: 0.1.0
+description: |
+  Clear the freeze boundary set by /freeze, allowing edits to all directories
+  again. Use when you want to widen edit scope without ending the session.
+  Use when asked to "unfreeze", "unlock edits", "remove freeze", or
+  "allow all edits".
+---
+
+# /unfreeze — Clear Freeze Boundary
+
+Remove the edit restriction set by `/freeze`, allowing edits to all directories.
+
+## Clear the boundary
+
+```bash
+STATE_DIR="${CLAUDE_PLUGIN_DATA:-$HOME/.orch}"
+if [ -f "$STATE_DIR/freeze-dir.txt" ]; then
+  PREV=$(cat "$STATE_DIR/freeze-dir.txt")
+  rm -f "$STATE_DIR/freeze-dir.txt"
+  echo "Freeze boundary cleared (was: $PREV). Edits are now allowed everywhere."
+else
+  echo "No freeze boundary was set."
+fi
+```
+
+Tell the user the result. Note that `/freeze` hooks are still registered for the
+session — they will just allow everything since no state file exists. To re-freeze,
+run `/freeze` again.
+

package/skills/library/upgrade.md

@@ -0,0 +1,220 @@
+---
+name: upgrade
+version: 1.1.0
+description: |
+  Upgrade orch skills to the latest version. Detects global vs vendored install,
+  runs the upgrade, and shows what's new. Use when asked to "upgrade orch",
+  "update orch", or "get latest version".
+---
+
+# /upgrade
+
+Upgrade orch skills to the latest version and show what's new.
+
+## Inline upgrade flow
+
+This section is referenced by all skill preambles when they detect `UPGRADE_AVAILABLE`.
+
+### Step 1: Ask the user (or auto-upgrade)
+
+First, check if auto-upgrade is enabled:
+```bash
+_AUTO=""
+[ "${GSTACK_AUTO_UPGRADE:-}" = "1" ] && _AUTO="true"
+[ -z "$_AUTO" ] && _AUTO=$(# orch config get auto_upgrade 2>/dev/null || true)
+echo "AUTO_UPGRADE=$_AUTO"
+```
+
+**If `AUTO_UPGRADE=true` or `AUTO_UPGRADE=1`:** Skip AskUserQuestion. Log "Auto-upgrading v{old} → v{new}..." and proceed directly to Step 2. If `./setup` fails during auto-upgrade, restore from backup (`.bak` directory) and warn the user: "Auto-upgrade failed — restored previous version. Run `/upgrade` manually to retry."
+
+**Otherwise**, use AskUserQuestion:
+- Question: "**v{new}** is available (you're on v{old}). Upgrade now?"
+- Options: ["Yes, upgrade now", "Always keep me up to date", "Not now", "Never ask again"]
+
+**If "Yes, upgrade now":** Proceed to Step 2.
+
+**If "Always keep me up to date":**
+```bash
+# orch config set auto_upgrade true
+```
+Tell user: "Auto-upgrade enabled. Future updates will install automatically." Then proceed to Step 2.
+
+**If "Not now":** Write snooze state with escalating backoff (first snooze = 24h, second = 48h, third+ = 1 week), then continue with the current skill. Do not mention the upgrade again.
+```bash
+_SNOOZE_FILE=~/.orch/update-snoozed
+_REMOTE_VER="{new}"
+_CUR_LEVEL=0
+if [ -f "$_SNOOZE_FILE" ]; then
+  _SNOOZED_VER=$(awk '{print $1}' "$_SNOOZE_FILE")
+  if [ "$_SNOOZED_VER" = "$_REMOTE_VER" ]; then
+    _CUR_LEVEL=$(awk '{print $2}' "$_SNOOZE_FILE")
+    case "$_CUR_LEVEL" in *[!0-9]*) _CUR_LEVEL=0 ;; esac
+  fi
+fi
+_NEW_LEVEL=$((_CUR_LEVEL + 1))
+[ "$_NEW_LEVEL" -gt 3 ] && _NEW_LEVEL=3
+echo "$_REMOTE_VER $_NEW_LEVEL $(date +%s)" > "$_SNOOZE_FILE"
+```
+Note: `{new}` is the remote version from the `UPGRADE_AVAILABLE` output — substitute it from the update check result.
+
+Tell user the snooze duration: "Next reminder in 24h" (or 48h or 1 week, depending on level). Tip: "Set `auto_upgrade: true` in `~/.orch/config.yaml` for automatic upgrades."
+
+**If "Never ask again":**
+```bash
+# orch config set update_check false
+```
+Tell user: "Update checks disabled. Run `# orch config set update_check true` to re-enable."
+Continue with the current skill.
+
+### Step 2: Detect install type
+
+```bash
+if [ -d "$HOME/.claude/skills/orch/.git" ]; then
+  INSTALL_TYPE="global-git"
+  INSTALL_DIR="$HOME/.claude/skills/orch"
+elif [ -d ".claude/skills/orch/.git" ]; then
+  INSTALL_TYPE="local-git"
+  INSTALL_DIR=".claude/skills/orch"
+elif [ -d ".claude/skills/orch" ]; then
+  INSTALL_TYPE="vendored"
+  INSTALL_DIR=".claude/skills/orch"
+elif [ -d "$HOME/.claude/skills/orch" ]; then
+  INSTALL_TYPE="vendored-global"
+  INSTALL_DIR="$HOME/.claude/skills/orch"
+else
+  echo "ERROR: orch skills not found"
+  exit 1
+fi
+echo "Install type: $INSTALL_TYPE at $INSTALL_DIR"
+```
+
+The install type and directory path printed above will be used in all subsequent steps.
+
+### Step 3: Save old version
+
+Use the install directory from Step 2's output below:
+
+```bash
+OLD_VERSION=$(cat "$INSTALL_DIR/VERSION" 2>/dev/null || echo "unknown")
+```
+
+### Step 4: Upgrade
+
+Use the install type and directory detected in Step 2:
+
+**For git installs** (global-git, local-git):
+```bash
+cd "$INSTALL_DIR"
+STASH_OUTPUT=$(git stash 2>&1)
+git fetch origin
+git reset --hard origin/main
+./setup
+```
+If `$STASH_OUTPUT` contains "Saved working directory", warn the user: "Note: local changes were stashed. Run `git stash pop` in the skill directory to restore them."
+
+**For vendored installs** (vendored, vendored-global):
+```bash
+PARENT=$(dirname "$INSTALL_DIR")
+TMP_DIR=$(mktemp -d)
+git clone --depth 1 <upstream-skill-repo-url> "$TMP_DIR/orch-skills"
+mv "$INSTALL_DIR" "$INSTALL_DIR.bak"
+mv "$TMP_DIR/orch-skills" "$INSTALL_DIR"
+cd "$INSTALL_DIR" && ./setup
+rm -rf "$INSTALL_DIR.bak" "$TMP_DIR"
+```
+
+### Step 4.5: Sync local vendored copy
+
+Use the install directory from Step 2. Check if there's also a local vendored copy that needs updating:
+
+```bash
+_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
+LOCAL_GSTACK=""
+if [ -n "$_ROOT" ] && [ -d "$_ROOT/.claude/skills/orch" ]; then
+  _RESOLVED_LOCAL=$(cd "$_ROOT/.claude/skills/orch" && pwd -P)
+  _RESOLVED_PRIMARY=$(cd "$INSTALL_DIR" && pwd -P)
+  if [ "$_RESOLVED_LOCAL" != "$_RESOLVED_PRIMARY" ]; then
+    LOCAL_GSTACK="$_ROOT/.claude/skills/orch"
+  fi
+fi
+echo "LOCAL_GSTACK=$LOCAL_GSTACK"
+```
+
+If `LOCAL_GSTACK` is non-empty, update it by copying from the freshly-upgraded primary install (same approach as README vendored install):
+```bash
+mv "$LOCAL_GSTACK" "$LOCAL_GSTACK.bak"
+cp -Rf "$INSTALL_DIR" "$LOCAL_GSTACK"
+rm -rf "$LOCAL_GSTACK/.git"
+cd "$LOCAL_GSTACK" && ./setup
+rm -rf "$LOCAL_GSTACK.bak"
+```
+Tell user: "Also updated vendored copy at `$LOCAL_GSTACK` — commit `.claude/skills/orch/` when you're ready."
+
+If `./setup` fails, restore from backup and warn the user:
+```bash
+rm -rf "$LOCAL_GSTACK"
+mv "$LOCAL_GSTACK.bak" "$LOCAL_GSTACK"
+```
+Tell user: "Sync failed — restored previous version at `$LOCAL_GSTACK`. Run `/upgrade` manually to retry."
+
+### Step 5: Write marker + clear cache
+
+```bash
+mkdir -p ~/.orch
+echo "$OLD_VERSION" > ~/.orch/just-upgraded-from
+rm -f ~/.orch/last-update-check
+rm -f ~/.orch/update-snoozed
+```
+
+### Step 6: Show What's New
+
+Read `$INSTALL_DIR/CHANGELOG.md`. Find all version entries between the old version and the new version. Summarize as 5-7 bullets grouped by theme. Don't overwhelm — focus on user-facing changes. Skip internal refactors unless they're significant.
+
+Format:
+```
+v{new} — upgraded from v{old}!
+
+What's new:
+- [bullet 1]
+- [bullet 2]
+- ...
+
+Happy shipping!
+```
+
+### Step 7: Continue
+
+After showing What's New, continue with whatever skill the user originally invoked. The upgrade is done — no further action needed.
+
+---
+
+## Standalone usage
+
+When invoked directly as `/upgrade` (not from a preamble):
+
+1. Force a fresh update check (bypass cache):
+```bash
+# Check for updates (adapt to your update mechanism)
+# Example: compare local VERSION with remote VERSION
+```
+Use the output to determine if an upgrade is available.
+
+2. If `UPGRADE_AVAILABLE <old> <new>`: follow Steps 2-6 above.
+
+3. If no output (primary is up to date): check for a stale local vendored copy.
+
+Run the Step 2 bash block above to detect the primary install type and directory (`INSTALL_TYPE` and `INSTALL_DIR`). Then run the Step 4.5 detection bash block above to check for a local vendored copy (`LOCAL_GSTACK`).
+
+**If `LOCAL_GSTACK` is empty** (no local vendored copy): tell the user "You're already on the latest version (v{version})."
+
+**If `LOCAL_GSTACK` is non-empty**, compare versions:
+```bash
+PRIMARY_VER=$(cat "$INSTALL_DIR/VERSION" 2>/dev/null || echo "unknown")
+LOCAL_VER=$(cat "$LOCAL_GSTACK/VERSION" 2>/dev/null || echo "unknown")
+echo "PRIMARY=$PRIMARY_VER LOCAL=$LOCAL_VER"
+```
+
+**If versions differ:** follow the Step 4.5 sync bash block above to update the local copy from the primary. Tell user: "Global v{PRIMARY_VER} is up to date. Updated local vendored copy from v{LOCAL_VER} → v{PRIMARY_VER}. Commit `.claude/skills/orch/` when you're ready."
+
+**If versions match:** tell the user "You're on the latest version (v{PRIMARY_VER}). Global and local vendored copy are both up to date."
+

package/skills/orch/SKILL.md

@@ -269,6 +269,144 @@ scheduling:
   retry_max_delay_ms: 300000    # Max retry delay (5min)
 ```
 
+## Creating Agents — Sources and Best Practices
+
+### Quick: Use Pre-Built Templates
+
+```bash
+orch agent shop              # Interactive picker — 15 templates
+orch agent shop --list       # Print all templates non-interactively
+orch org deploy <template>   # Deploy a full team with one command
+```
+
+### Agent Shop Templates (src/domain/agent-shop.ts)
+
+Each template includes a detailed role prompt, model, skills, and approval policy:
+
+| Template | Role | Model | Skills |
+|----------|------|-------|--------|
+| `backend-dev` | APIs, services, DB layers | claude-sonnet-4-6 | feature-dev |
+| `frontend-dev` | React UI, components, CSS | claude-sonnet-4-6 | feature-dev, frontend-design |
+| `qa-engineer` | Tests, coverage analysis | claude-sonnet-4-6 | testing-suite |
+| `code-reviewer` | PR review, bugs, security | claude-opus-4-6 | feature-dev:code-reviewer |
+| `architect` | System design, architecture | claude-opus-4-6 | feature-dev:code-architect |
+| `devops-engineer` | CI/CD, infrastructure | claude-sonnet-4-6 | devops-automation |
+| `bug-hunter` | Find bugs, reproduce, fix | claude-sonnet-4-6 | feature-dev |
+| `tech-writer` | Docs, READMEs, API docs | claude-sonnet-4-6 | perfect-readme |
+| `security-auditor` | Security scanning, vulns | claude-opus-4-6 | testing-suite |
+| `performance-engineer` | Optimization, profiling | claude-sonnet-4-6 | testing-suite |
+| `data-engineer` | Data pipelines, ETL | claude-sonnet-4-6 | — |
+| `fullstack-dev` | End-to-end development | claude-sonnet-4-6 | feature-dev |
+| `marketer` | Marketing strategy, copy | claude-sonnet-4-6 | marketing-psychology |
+| `content-creator` | Blog posts, social media | claude-sonnet-4-6 | — |
+| `growth-hacker` | Growth experiments | claude-sonnet-4-6 | marketing-psychology |
+
+### Org Templates (src/domain/org-shop.ts)
+
+Pre-built teams — deploy with `orch org deploy <key> --goal "..."`:
+
+| Template | Agents | Use Case |
+|----------|--------|----------|
+| `startup-mvp` | CTO + 2 Backend + Frontend + QA + Reviewer | Ship MVP fast |
+| `pr-review-corp` | CTO + Security + Performance + Style + QA | Auto-review PRs |
+| `migration-squad` | CTO + 3 Migrators + QA + Reviewer | JS→TS migration |
+| `security-dept` | Lead + Scanner + Secrets + Hunter + Reviewer | Security audit |
+| `test-factory` | Lead + 2 Backend + 3 QA + Reviewer | Coverage boost |
+| `bugfix-dept` | Triager + 3 Fixers + QA + Reviewer | Issue backlog |
+| `docs-team` | Lead + 2 Writers + Editor + Reviewer | Documentation |
+| `content-agency` | Strategist + 2 Writers + Editor + SEO | Content |
+| `data-lab` | Lead Analyst + Data Engineer | Data analysis |
+| `sales-machine` | Director + 2 SDRs + Copywriter + Growth | Outbound |
+
+### Custom Agents: Role Prompt Structure
+
+When creating custom agents with `orch agent add`, follow this proven structure from the shop templates:
+
+```
+# [Role Name]
+
+[One-line description of what this agent does]
+
+## WORKFLOW
+1) READ — understand the task scope
+2) EXPLORE — analyze existing code/data with appropriate skills
+3) PLAN — outline approach before executing
+4) EXECUTE — do the work following conventions
+5) VERIFY — self-review, run tests
+6) REPORT — summarize what was done, flag risks
+
+## RULES
+- [Convention 1]
+- [Convention 2]
+- [Safety guardrail]
+```
+
+### Skills Available for Agents
+
+Assign skills via `--skills` flag or edit agent YAML. You can mix both types: `--skills "review,feature-dev:code-explorer,investigate"`.
+
+#### Library Skills (injected into system prompt — works with ALL adapters)
+
+Content from the skill library is loaded and appended to the agent's system prompt at execution time. Use plain names (no colons):
+
+| Skill | Best For |
+|-------|----------|
+| `review` | Pre-landing code review with auto-fix, checklists, adversarial review |
+| `qa` | Full QA testing + browser testing + bug fixing + health scoring |
+| `qa-only` | QA testing without auto-fixes (report only) |
+| `ship` | Automated ship workflow: merge, test, coverage audit, PR creation |
+| `office-hours` | YC-style product thinking, design docs, premise challenge |
+| `investigate` | Systematic debugging with root cause methodology, 3-strike hypothesis |
+| `careful` | Safety guardrails for destructive commands |
+| `guard` | Full safety mode (careful + freeze combined) |
+| `freeze` | Restrict edits to a specific directory |
+| `unfreeze` | Clear freeze boundary |
+| `design-consultation` | Design system creation, visual language definition |
+| `design-review` | Design review with accessibility, responsiveness checks |
+| `plan-ceo-review` | CEO-level strategic review of plans |
+| `plan-eng-review` | Engineering review of technical plans |
+| `plan-design-review` | Design review of plans |
+| `autoplan` | Auto-review pipeline with decision principles |
+| `land-and-deploy` | Merge PR, wait for CI, verify production health |
+| `canary` | Post-deploy canary monitoring |
+| `document-release` | Auto-update documentation after ship |
+| `retro` | Weekly engineering retrospective with trends |
+| `browse` | Headless browser navigation and testing |
+| `benchmark` | Performance benchmarking with before/after metrics |
+| `codex` | OpenAI Codex cross-review / multi-AI challenge |
+| `setup-deploy` | Configure deployment settings |
+| `setup-browser-cookies` | Import browser cookies for authenticated QA |
+| `upgrade` | Upgrade skills to latest version |
+
+#### Claude Code MCP Skills (native — Claude adapter only)
+
+Handled natively by Claude CLI. Use `package:skill-name` format (with colon):
+
+| Skill | Best For |
+|-------|----------|
+| `feature-dev:feature-dev` | Guided feature development with architecture focus |
+| `feature-dev:code-explorer` | Deep codebase analysis and tracing |
+| `feature-dev:code-architect` | Architecture design and blueprints |
+| `feature-dev:code-reviewer` | Code review with confidence filtering |
+| `testing-suite:generate-tests` | Test generation with edge cases |
+| `testing-suite:test-coverage` | Coverage analysis and gap identification |
+| `testing-suite:e2e-setup` | End-to-end testing configuration |
+| `testing-suite:test-quality-analyzer` | Test suite quality metrics |
+| `devops-automation:cloud-architect` | Cloud infrastructure, Terraform |
+| `frontend-design:frontend-design` | UI/UX design and implementation |
+| `document-skills:frontend-design` | Frontend design (document-skills variant) |
+| `product-manager-toolkit` | RICE prioritization, PRD templates |
+| `marketing-psychology` | Behavioral science for marketing |
+
+### Tips
+
+- Use `claude-opus-4-6` for strategic/review roles (architect, reviewer, lead) — higher quality reasoning
+- Use `claude-sonnet-4-6` for execution roles (developer, QA, writer) — faster, cheaper
+- Set `--approval-policy suggest` for strategic agents so humans review decisions
+- Set `--approval-policy auto` for execution agents for fully autonomous operation
+- Use `--workspace-mode shared` for analysis/strategy agents (they read, don't write code)
+- Use `--workspace-mode worktree` for coding agents (isolated branches, no conflicts)
+
 ## Important Notes
 
 - Always run `orch doctor` first if something seems wrong