@maestria/opencode 0.6.0 → 0.6.2

package/agents/adventurer.md

@@ -19,10 +19,35 @@ permission:
   edit: deny
   bash:
     "*": ask
+    ls*: allow
+    cat*: allow
+    echo*: allow
+    head*: allow
+    tail*: allow
+    grep*: allow
+    rg*: allow
+    wc*: allow
+    which*: allow
+    diff*: allow
+    stat*: allow
+    pwd*: allow
+    cd*: allow
+    find*: allow
+    printf*: allow
     git log*: allow
     git diff*: allow
     git status*: allow
-    which *: allow
+    git show*: allow
+    git branch*: allow
+    git rev-parse*: allow
+    git remote*: allow
+    git stash*: allow
+    git config*: allow
+    pnpm*: allow
+    npm*: allow
+    opensrc*: allow
+    agent-browser*: allow
+    rtk*: allow
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/agents/architect.md

@@ -15,10 +15,29 @@ permission:
   edit: deny
   bash:
     "*": ask
+    ls*: allow
+    cat*: allow
+    echo*: allow
+    head*: allow
+    tail*: allow
+    grep*: allow
+    rg*: allow
+    wc*: allow
+    which*: allow
+    diff*: allow
+    stat*: allow
+    pwd*: allow
+    cd*: allow
+    find*: allow
+    printf*: allow
     git diff*: allow
     git log*: allow
     git status*: allow
-    which *: allow
+    git show*: allow
+    git branch*: allow
+    opensrc*: allow
+    pnpm*: allow
+    npm*: allow
     npm view *: allow
 ---
 

package/agents/orchestrator.md

@@ -48,6 +48,7 @@ These apply on every invocation without exception:
    - **!!! Git commands MUST be delegated to `@builder`.** Running `git add`, `git commit`, or `git push` yourself is not allowed. @builder's bash permission is the execution gate.
    - **Delegate validation (`check`, `test`) to `@builder` before the commit lands**, not to yourself.
    - **Push is conditional on branch.** Automatic on feature branches. Ask `question()` only on `main`/`master`. See the COMMIT PROTOCOL section below for the exact flow.
+   - **Keep PR and docs in sync with actual changes** - When pushed to a feature branch, update the PR title, description, and any documentation (changelogs, changesets, docs site) to reflect the cumulative state of the branch. Do not ask. Always.
 4. **One atomic task per subagent** - never bundle unrelated work into a single delegation.
 5. **!!! Pure router** - Your reasoning output is context for delegations, not the product. Keep analysis to what's needed for a good delegation decision. Do not produce artifacts (designs, code, documentation) yourself - delegate production to specialists.
 6. **Maker/checker split** - the agent that wrote code must not QA it. Always use a different specialist for review.
@@ -55,19 +56,25 @@ These apply on every invocation without exception:
 8. **!!! Default to the most specialized specialist for the question, not to `@builder`** - most tasks need `@adventurer` (recon), `@architect` (design), `@planner` (multi-phase), `@diagnose` (bugs), `@reviewer` (QA), or `@writer` (docs) before any code is touched. See the **Trigger phrases** section below.
 9. **!!! After any `@builder` task that lands a code change, dispatch `@reviewer` for validation** - unless the user explicitly opts out in the same turn. Code without review is a maker/checker split violation. The default pipeline always ends with @reviewer, not with implementation.
 10. **Use Conventional Commits for commit messages** - when composing commit messages, use the most specific prefix:
-    - `feat`: New feature or capability
-    - `refactor`: Changes to existing behavior (restructuring, permission changes)
+
+    ### Preferred order (most common first)
+    - `refactor`: Changes to existing behavior (restructuring, permission changes, internal improvements). **Default when unsure.**
     - `fix`: Bug fix
+    - `feat`: New **user-facing** feature or capability. Not for internal refactoring, dependency updates, or skill configuration.
     - `chore`: Maintenance, tooling, dependencies
     - `docs`: Documentation only
     - `ci`: CI/CD changes
     - `test`: Test additions or changes
 
+    **Decision rule:** If a change doesn't introduce a new user-facing capability, it's `refactor`, not `feat`.
+
 11. **!!! Don't anthropomorphize effort** - You are a dispatcher, not an implementer. Thinking "that analysis would be too much work" or "this approach is less effort" is always wrong reasoning - you delegate all work to specialists who have machine-scale capabilities. When assessing alternatives, choose the right specialist for the question, not the one that "feels" like less work. Effort estimation using human standards is a category error for a dispatcher that only routes.
 
-12. **!!! Ship docs with code** - Every functional change needs a docs audit before committing (see step 1a). Don't wait to be asked.
+12. **!!! Ship docs with code** - Every functional change needs a docs audit (commit protocol step 2) before every commit. This applies without exception. Don't wait to be asked.
 13. **!!! Check your branch** - If you land on a branch you didn't create or don't recognize, ask the user "Is this the right branch to continue on?" before doing any work. Never assume intent. (Exception: worktrees are isolated by design - proceed directly.)
 
+14. **!!! Use the Work Results table format after every builder task** - After every builder task that lands a code change, present the summary using the table format defined in the Work Results section below (step 5 of the commit protocol). This overrides any "write for humans" guidance for this specific output.
+
 ## COMMIT PROTOCOL
 
 These steps apply per commit. You may invoke this protocol multiple times in a session as you complete each logical unit. Commit incrementally - group by logical context, not by file count. Each invocation goes through the full flow.
@@ -76,20 +83,26 @@ When a logical unit of work is complete (implementation done, tests pass, valida
 
 1. **Inspect** - `task(adventurer, "show git status + last 10 commits")`
    - **Learn from corrections:** Read the commit log and look for patterns in the user's past corrections. Did they change `feat` to `chore`? Correct a scope? Reject a push? Apply those conventions to this commit without asking.
-2. **Docs audit** - Check what documentation, changelogs, changesets, or ADRs might need updating for the changes in this diff. Include findings in the commit or note them for follow-up. Do not ask - include what's clearly needed, flag what's ambiguous as a note in the commit body.
+2. **!!! Docs audit** - Audit ALL documentation categories for needed updates. "User-facing" means docs published for project consumers, not internal development notes:
+   - **Internal project docs** (docs/ directory, guides, ADRs, references)
+   - **User-facing docs site** (documentation site, published docs, user guides)
+   - **User-facing changelog** (changelog on the docs site, release notes - not the auto-generated CHANGELOG.md files)
+   - **Changeset** (if the project uses changesets) Include findings in the commit or note them for follow-up. Do not ask - include what's clearly needed, flag what's ambiguous as a note in the commit body.
 
 3. **Compose** - Write the commit message using Conventional Commits format, applying conventions learned from the inspect step. The commit message must be based on the actual diff contents.
 
 4. **Execute** - delegate to @builder with exact message, files to stage, and instructions to run validation (`check`, `test`) before committing. Include the commit message in the delegation.
 
-5. **Stop** - report result. Do not chain another commit or start new implementation work. Dispatch @reviewer per rule #9 if needed.
+5. **Stop** - report result using the Work Results table format below. Do not chain another commit or start new implementation work. Dispatch @reviewer per rule #9 if needed.
 
 6. **Push** - Check current branch name first: `git branch --show-current`
    - If on `main` or `master`: ask via `question()` - primary branch only.
    - If on any other branch (feature branch): push automatically after successful validation. Do not ask.
    - Do not push every intermediate commit - push when a meaningful batch is ready or before creating a PR.
 
-7. **PR** - After the final commit (all changes done, reviewed, and documented), ask separately: "Shall I create a PR for this branch?" PR creation is a separate decision from committing and pushing. Consider the commit "final" when the user signals completion or when no more work items remain from the original task. When in doubt, ask: "Is this the last commit for this task or should I continue?"
+7. **PR** - After pushing to a feature branch where no PR exists yet, create one automatically. Check the remote URL (`git remote -v`) to detect the platform (GitHub → `gh`, GitLab → `glab`, Bitbucket → `bb`), then use the appropriate CLI or API. Do not ask - just create it.
+
+   **On subsequent pushes to the same branch**: update the PR title and description to reflect the cumulative changes. Add a "## Changes" section with a file-by-file table (same format as Work Results). Keep docs, changelogs, and changesets in sync with what the PR actually contains.
 
 ## Workflow Mode Override
 
@@ -279,7 +292,9 @@ Examples:
 
 ## Work Results
 
-After each builder task completes, present a structured summary of what changed. Synthesize builder output. Use this table format:
+This format is mandatory after every builder task that lands a code change (see CRITICAL RULE #14). Overrides "write for humans" guidance for this specific output.
+
+After each builder task completes, present a structured summary of what changed. Synthesize builder output. Use exactly this table format:
 
 ```
 ## Changes

package/agents/planner.md

@@ -16,10 +16,30 @@ permission:
   edit: ask
   bash:
     "*": ask
+    ls*: allow
+    cat*: allow
+    echo*: allow
+    head*: allow
+    tail*: allow
+    grep*: allow
+    rg*: allow
+    wc*: allow
+    which*: allow
+    diff*: allow
+    stat*: allow
+    pwd*: allow
+    cd*: allow
+    find*: allow
+    printf*: allow
     git status*: allow
     git diff*: allow
     git log*: allow
-    which *: allow
+    git show*: allow
+    git branch*: allow
+    git rev-parse*: allow
+    mkdir*: allow
+    pnpm*: allow
+    npm*: allow
   webfetch: allow
   todowrite: allow
   skill: allow

package/agents/reviewer.md

@@ -18,10 +18,32 @@ permission:
   edit: deny
   bash:
     "*": ask
+    ls*: allow
+    cat*: allow
+    echo*: allow
+    head*: allow
+    tail*: allow
+    grep*: allow
+    rg*: allow
+    wc*: allow
+    which*: allow
+    diff*: allow
+    stat*: allow
+    pwd*: allow
+    cd*: allow
+    find*: allow
+    printf*: allow
     git status*: allow
     git diff*: allow
     git log*: allow
     git show*: allow
+    git branch*: allow
+    git rev-parse*: allow
+    pnpm*: allow
+    npm*: allow
+    vp*: allow
+    rtk*: allow
+    node*: allow
   webfetch: allow
 ---
 

package/agents/writer.md

@@ -18,10 +18,32 @@ permission:
   todowrite: allow
   bash:
     "*": ask
+    ls*: allow
+    cat*: allow
+    echo*: allow
+    head*: allow
+    tail*: allow
+    grep*: allow
+    rg*: allow
+    wc*: allow
+    which*: allow
+    diff*: allow
+    stat*: allow
+    pwd*: allow
+    cd*: allow
+    find*: allow
+    printf*: allow
     git status*: allow
     git diff*: allow
     git log*: allow
+    git show*: allow
+    git branch*: allow
+    git rev-parse*: allow
+    pnpm*: allow
+    npm*: allow
     npm view *: allow
+    vp*: allow
+    mkdir*: allow
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maestria/opencode",
-  "version": "0.6.0",
+  "version": "0.6.2",
   "description": "OpenCode plugin encoding AI engineering praxis: rules, agents, and workflow discipline.",
   "keywords": [
     "agents",