automatasaurus 0.1.12 → 0.1.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "automatasaurus",
-  "version": "0.1.12",
+  "version": "0.1.14",
   "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/developer/AGENT.md

@@ -249,10 +249,11 @@ Load the `pr-writing` skill for detailed guidance.
 
 **Creating the PR:**
 
+Use Write tool + `--body-file` (heredocs fail in sandboxed environments):
+
 ```bash
-gh pr create \
-  --title "#{issue} feat: {description}" \
-  --body "**[Developer]**
+# Step 1: Use Write tool to create .github-pr-body.md with:
+**[Developer]**
 
 ## Summary
 {Description}
@@ -265,7 +266,15 @@ Closes #{issue_number}
 - [ ] Tester
 
 ## Testing
-- [x] Tests passing"
+- [x] Tests passing
+
+# Step 2: Create the PR
+gh pr create \
+  --title "#{issue} feat: {description}" \
+  --body-file .github-pr-body.md
+
+# Step 3: Clean up
+rm .github-pr-body.md
 ```
 
 After creating, update issue:

package/template/commands/auto-discovery.md

@@ -282,13 +282,10 @@ Each issue should:
 - Be sized for a single PR
 - **No type prefix in title** (e.g., "Feature:", "Bug:") - use labels instead
 
+**Important:** Don't use heredocs (`<<EOF`) with `gh` commands - they fail in sandboxed environments. Instead, use the Write tool to create a temp file, then `--body-file`:
+
 ```bash
-gh issue create \
-  --title "[Concise description]" \
-  --milestone "[Milestone Name]" \
-  --label "feature" \
-  --label "ready" \
-  --body "$(cat <<'EOF'
+# Step 1: Use Write tool to create .github-issue-body.md with:
 ## Context
 From discovery: [link to current discovery file, e.g., discovery.md or discovery-2.md]
 
@@ -309,8 +306,17 @@ So that [benefit].
 
 ## Out of Scope
 [What's NOT included]
-EOF
-)"
+
+# Step 2: Create the issue
+gh issue create \
+  --title "[Concise description]" \
+  --milestone "[Milestone Name]" \
+  --label "feature" \
+  --label "ready" \
+  --body-file .github-issue-body.md
+
+# Step 3: Clean up
+rm .github-issue-body.md
 ```
 
 ---

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/github-issues/SKILL.md

@@ -87,6 +87,20 @@ gh issue edit {number} --milestone "v1.0 - Basic Cart"
 
 ## Issue Commands
 
+### Sandbox Compatibility (Important)
+
+**Don't use heredocs (`<<EOF`) with `gh` commands** - they fail in sandboxed environments because the shell can't create temp files for the heredoc content.
+
+Instead, use the Write tool + `--body-file` pattern:
+
+```bash
+# 1. Use Write tool to create .github-issue-body.md with the issue body
+# 2. Create the issue with --body-file
+gh issue create --title "..." --body-file .github-issue-body.md
+# 3. Clean up
+rm .github-issue-body.md
+```
+
 ### Before Creating an Issue
 
 **Always check for duplicates first:**

package/template/skills/pr-writing/SKILL.md

@@ -7,6 +7,20 @@ description: Best practices for writing clear, effective pull request descriptio
 
 Guidelines for writing pull request descriptions that help reviewers understand and approve changes quickly.
 
+## Creating PRs (Sandbox Compatibility)
+
+**Don't use heredocs (`<<EOF`) with `gh pr create`** - they fail in sandboxed environments.
+
+Use the Write tool + `--body-file` pattern:
+
+```bash
+# 1. Use Write tool to create .github-pr-body.md with your PR body
+# 2. Create the PR
+gh pr create --title "#42 feat: Add user auth" --body-file .github-pr-body.md
+# 3. Clean up
+rm .github-pr-body.md
+```
+
 ## PR Title Format
 
 ```