@maestria/pi 0.4.0 → 0.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/package.json +1 -1
  2. package/prompts/orchestrator.md +7 -3
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@maestria/pi",
3
- "version": "0.4.0",
3
+ "version": "0.4.1",
4
4
  "description": "Maestria extension for the Pi coding agent",
5
5
  "keywords": [
6
6
  "agent-orchestration",
package/prompts/orchestrator.md CHANGED
@@ -25,14 +25,18 @@ These apply on every invocation without exception:
25
25
  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.
26
26
  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.
27
27
  10. **Use Conventional Commits for commit messages** - when composing commit messages, use the most specific prefix:
28
- - `feat`: New feature or capability
29
- - `refactor`: Changes to existing behavior (restructuring, permission changes)
28
+
29
+ ### Preferred order (most common first)
30
+ - `refactor`: Changes to existing behavior (restructuring, permission changes, internal improvements). **Default when unsure.**
30
31
  - `fix`: Bug fix
32
+ - `feat`: New **user-facing** feature or capability. Not for internal refactoring, dependency updates, or skill configuration.
31
33
  - `chore`: Maintenance, tooling, dependencies
32
34
  - `docs`: Documentation only
33
35
  - `ci`: CI/CD changes
34
36
  - `test`: Test additions or changes
35
37
 
38
+ **Decision rule:** If a change doesn't introduce a new user-facing capability, it's `refactor`, not `feat`.
39
+
36
40
  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.
37
41
 
38
42
  12. **!!! Ship docs with code** - Every functional change needs a docs audit before committing (see step 1a). Don't wait to be asked.
@@ -59,7 +63,7 @@ When a logical unit of work is complete (implementation done, tests pass, valida
59
63
  - If on any other branch (feature branch): push automatically after successful validation. Do not ask.
60
64
  - Do not push every intermediate commit - push when a meaningful batch is ready or before creating a PR.
61
65
 
62
- 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?"
66
+ 7. **PR** - After pushing to a feature branch (non-main/master) where no PR exists yet, create a PR 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. The user can edit after creation.
63
67
 
64
68
  ## Workflow Mode Override
65
69