automatasaurus 0.1.13 → 0.1.15

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "automatasaurus",
-  "version": "0.1.13",
+  "version": "0.1.15",
   "description": "Automated software development workflow powered by Claude Code",
   "type": "module",
   "bin": {

package/template/agents/architect/AGENT.md

@@ -98,22 +98,6 @@ Provide structured feedback:
 
 Load the `code-review` skill for detailed guidance.
 
-### Review Philosophy
-
-Have a **slight bias towards moving forward** - avoid nitpicks and style debates that slow down shipping. But still request changes for legitimate problems.
-
-**Request changes for:**
-- Security vulnerabilities
-- Bugs that will cause runtime errors
-- Breaking existing functionality
-- Missing critical requirements
-- Significant architectural issues
-
-**Don't block for (suggest as non-blocking instead):**
-- Style preferences
-- Minor refactoring opportunities (create follow-up issue)
-- Nitpicks that don't affect functionality
-
 ### Review Process
 
 ```bash

package/template/agents/designer/AGENT.md

@@ -143,26 +143,6 @@ Or if reviewing a file directly, provide feedback in conversation.
 
 When reviewing a PR for UI/UX:
 
-### Review Philosophy
-
-Have a **slight bias towards moving forward** - avoid nitpicks over minor visual details. But still request changes for legitimate UX, design quality, or accessibility problems.
-
-**Request changes for:**
-- Accessibility violations (WCAG failures)
-- Broken user flows or interactions
-- Missing critical UI states (error, loading)
-- Significant usability issues
-- Confusing or misleading interfaces (users can't understand what to do)
-- Visual hierarchy failures (nothing draws the eye, or wrong element is prominent)
-- Design token violations (hardcoded values instead of design system tokens)
-- Inconsistent patterns (reinventing UI that exists elsewhere in the app)
-
-**Don't block for (suggest as non-blocking instead):**
-- Minor spacing or alignment tweaks
-- Color shade preferences within the design system
-- Subjective opinions about aesthetic choices
-- "Could be more delightful" suggestions (functional but not exceptional)
-
 ### 1. Determine Relevance
 
 UI-relevant changes include:

package/template/agents/evolver/AGENT.md

@@ -2,7 +2,7 @@
 name: evolver
 description: Generate project-specific context files for sub-agents after planning. Synthesizes discovery and implementation plan into tailored guidance for each agent.
 tools: Read, Write, Glob
-model: sonnet
+model: opus
 ---
 
 # Evolver Agent

package/template/commands/auto-plan.md

@@ -82,12 +82,10 @@ Before implementation begins, spawn the Designer agent to establish the visual f
 
 ```
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "designer"
+  model: "opus"
   description: "Create design language"
   prompt: |
-    You are the Designer agent. Load your role from .claude/agents/designer/AGENT.md
-
     **[Designer]**
 
     Establish the design language and style guide for this project.

package/template/skills/code-review/SKILL.md

@@ -9,43 +9,18 @@ Guidelines for performing effective code reviews that catch issues, improve code
 
 ## Review Mindset
 
-### Bias Towards Shipping
-
-**The primary goal is to get working code merged, not to achieve perfection.**
-
-Before requesting changes, always ask yourself:
-> "Is this feedback worth an additional review cycle?"
-
-Most feedback should be:
-- Approved with suggestions for the author to consider
-- Comments for future reference, not blocking
-- Follow-up issues for later improvement
-
-**Reserve "Request Changes" for actual problems:**
-- Security vulnerabilities
-- Bugs that will cause runtime errors
-- Breaking changes to existing functionality
-- Missing critical requirements
-
-**Do NOT block for:**
-- Style preferences (unless egregiously inconsistent)
-- "I would have done it differently"
-- Minor optimizations that don't matter at current scale
-- Missing tests for edge cases that are unlikely
-- Refactoring opportunities (create a follow-up issue instead)
+Don't hold up PRs over trivial issues — but do request changes for anything substantive.
 
 ### Goals of Code Review
 1. **Catch real bugs** before they reach production
 2. **Prevent security issues** - the things that actually matter
 3. **Share knowledge** across the team
-4. **Ship working software** - don't let perfect be the enemy of good
 
 ### The Right Attitude
 - You're reviewing the **code**, not the person
 - Assume good intent - the author tried their best
 - Be a collaborator, not a gatekeeper
 - Your job is to help ship good code, not to find fault
-- **Velocity matters** - every review cycle has a cost
 
 ## Review Process
 
@@ -246,8 +221,6 @@ Use prefixes to indicate importance:
 | **Question:** | Seeking to understand | As needed |
 | **Praise:** | Something done well | Often! |
 
-**Important:** Most comments should be Suggestions or Nits, not Blockers. If you find yourself writing many Blockers, reconsider whether they truly block shipping.
-
 ```markdown
 **Blocker:** This SQL query is vulnerable to injection. (Security - must fix)
 
@@ -270,18 +243,6 @@ Use prefixes to indicate importance:
 
 ## Common Review Scenarios
 
-### When You'd Do It Differently
-
-Don't block for preference. Ask yourself:
-- Is their way wrong, or just different?
-- Does it work correctly?
-- Is it maintainable?
-
-If it's just different:
-```markdown
-**Note:** I might have used X approach here, but this works well too. Not blocking.
-```
-
 ### When Something Is Missing
 
 ```markdown
@@ -305,36 +266,26 @@ Don't just point out problems:
 
 ## Review Response Templates
 
-**Default to Approve.** Most reviews should approve, possibly with suggestions.
-
-### Approve (Most Common)
+### Approve
 ```markdown
 **[Architect]** LGTM! Clean implementation, good test coverage.
 
-Minor suggestions (not blocking):
+Suggestions:
 - Line 42: prefer const
 - Consider adding a comment explaining the retry logic
-
-Merging as-is is fine. Address these if you agree, or not - your call.
 ```
 
 ### Approve with Suggestions
 ```markdown
-**[Architect]** Approving - this is solid work.
+**[Architect]** Approving with a few suggestions:
 
-A few things to consider (can address now or in follow-up):
 1. The validation could be more specific about what's wrong
 2. Consider adding logging for debugging
-
-Not blocking merge. Ship it!
 ```
 
-### Request Changes (Rare - Use Sparingly)
-
-**Only use for genuine blockers: security issues, bugs, or missing critical functionality.**
-
+### Request Changes
 ```markdown
-**[Architect]** Good progress! Found one issue that needs fixing before merge:
+**[Architect]** Found an issue that needs fixing before merge:
 
 **Blocker:**
 1. SQL injection vulnerability in the search query - this is a security risk
@@ -342,13 +293,6 @@ Not blocking merge. Ship it!
 Everything else looks good. Happy to re-review once the security fix is in.
 ```
 
-**Ask yourself before requesting changes:**
-- Will this cause a production incident if shipped?
-- Is this a security vulnerability?
-- Does it break existing functionality?
-
-If the answer to all three is "no", consider approving with suggestions instead.
-
 ### Decline (N/A)
 ```markdown
 **[UI/UX]** N/A - No UI changes in this PR.
@@ -368,7 +312,6 @@ Reviewed: Backend/infrastructure changes only, no user-facing impact.
 ### Don't
 - Nitpick excessively
 - Bike-shed on minor style issues
-- Block for preferences
 - Be condescending
 - Leave reviews hanging
 

package/template/skills/work-issue/SKILL.md

@@ -167,12 +167,10 @@ Post design specifications as an issue comment following your AGENT.md template,
 
 ```
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "designer"
+  model: "opus"
   description: "Designer specs for issue #{ISSUE_NUMBER}"
   prompt: |
-    You are the Designer agent. Load your role from .claude/agents/designer/AGENT.md
-
     Read orchestration/issues/{ISSUE_NUMBER}-{slug}/BRIEFING-design-specs.md first.
 
     After completing your work, write your report to:
@@ -227,12 +225,10 @@ Implement issue #{ISSUE_NUMBER}: {title}
 
 ```
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "developer"
+  model: "opus"
   description: "Implement issue #{ISSUE_NUMBER}"
   prompt: |
-    You are the Developer agent. Load your role from .claude/agents/developer/AGENT.md
-
     Read orchestration/issues/{ISSUE_NUMBER}-{slug}/BRIEFING-implement.md first.
 
     After completing your work, write your report to:
@@ -345,12 +341,10 @@ Spawn all reviewers in parallel (single message, multiple Task calls):
 ```
 # Architect review
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "architect"
+  model: "opus"
   description: "Architect review PR #{pr_number}"
   prompt: |
-    You are the Architect agent. Load your role from .claude/agents/architect/AGENT.md
-
     Read orchestration/issues/{ISSUE_NUMBER}-{slug}/BRIEFING-architect-review.md first.
 
     After completing your review, write your report to:
@@ -358,12 +352,10 @@ Use the Task tool with:
 
 # Designer review (if UI)
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "designer"
+  model: "opus"
   description: "Designer review PR #{pr_number}"
   prompt: |
-    You are the Designer agent. Load your role from .claude/agents/designer/AGENT.md
-
     Read orchestration/issues/{ISSUE_NUMBER}-{slug}/BRIEFING-designer-review.md first.
 
     After completing your review, write your report to:
@@ -371,12 +363,10 @@ Use the Task tool with:
 
 # Tester verification
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "tester"
+  model: "opus"
   description: "Tester verify PR #{pr_number}"
   prompt: |
-    You are the Tester agent. Load your role from .claude/agents/tester/AGENT.md
-
     Read orchestration/issues/{ISSUE_NUMBER}-{slug}/BRIEFING-test.md first.
 
     After completing verification, write your report to:
@@ -437,12 +427,10 @@ Address review feedback on PR #{pr_number}.
 
 ```
 Use the Task tool with:
-  subagent_type: "general-purpose"
-  model: "sonnet"
+  subagent_type: "developer"
+  model: "opus"
   description: "Address feedback PR #{pr_number}"
   prompt: |
-    You are the Developer agent. Load your role from .claude/agents/developer/AGENT.md
-
     Read orchestration/issues/{ISSUE_NUMBER}-{slug}/BRIEFING-address-feedback.md first.
 
     After completing fixes, write your report to: