@starlein/paperclip-plugin-company-wizard 0.3.21 → 0.3.23

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@starlein/paperclip-plugin-company-wizard",
-  "version": "0.3.21",
+  "version": "0.3.23",
   "type": "module",
   "description": "AI-powered wizard to bootstrap paperclip agent companies from composable templates (for latest paperclip version)",
   "repository": "https://github.com/starlein/paperclip-plugin-company-wizard",
@@ -28,7 +28,9 @@
   },
   "files": [
     "dist/",
-    "templates/"
+    "templates/",
+    "CHANGELOG.md",
+    "CONTRIBUTING.md"
   ],
   "paperclipPlugin": {
     "manifest": "./dist/manifest.js",

package/templates/modules/pr-review/agents/code-reviewer/skills/code-review.md

@@ -18,7 +18,7 @@ You review PRs for correctness, security, code quality, and simplicity. You are
 2. Record your verdict on your review stage:
    - **approved** if the code meets quality standards
    - **changes_requested** with specific, actionable feedback if not
-3. Optionally mirror the same verdict as a GitHub PR comment for visibility.
+3. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
 
 ## Rules
 

package/templates/modules/pr-review/agents/devops/skills/infra-review.md

@@ -19,7 +19,7 @@ You review PRs for infrastructure impact, performance, security, and operational
 3. Record your verdict on your review stage:
    - **approved** if operationally sound
    - **changes_requested** with specific concerns if not
-4. Optionally mirror the same verdict as a GitHub PR comment for visibility.
+4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
 
 ## Rules
 

package/templates/modules/pr-review/agents/engineer/skills/pr-workflow.md

@@ -8,7 +8,7 @@ When this skill is active, you work in feature branches and open PRs instead of
 2. Create branch: `git checkout -b <prefix>-<N>/<short-description>`
 3. Make your changes, commit with Conventional Commits format
 4. Push branch: `git push -u origin <branch-name>`
-5. Open PR: `gh pr create --title "<type>: <description>" --body "<template>"`
+5. Open PR: write the body (PR Body Template in `docs/pr-conventions.md`) to a file, then `gh pr create --title "<type>: <description>" --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal and the PR renders as `text\ntext` (see *Posting PR Bodies & Comments*).
 6. Set the originating issue's `executionPolicy` to gate the merge on review, ending with your own merge gate:
    - One `review` stage with the **Code Reviewer** as participant (always).
    - Additional `review` stages for any relevant domain reviewer that exists in the team (UI Designer for UI diffs, UX Researcher for flow changes, QA for logic/test-sensitive changes, DevOps for infra/deploy/dependency changes).

package/templates/modules/pr-review/agents/product-owner/skills/product-review.md

@@ -17,7 +17,7 @@ You review PRs for intent alignment, scope discipline, and acceptance criteria.
 2. Record your verdict on your approval stage:
    - **approved** if the change meets product requirements
    - **changes_requested** with specific feedback tied to acceptance criteria
-3. Optionally mirror the same verdict as a GitHub PR comment for visibility.
+3. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
 
 ## Rules
 

package/templates/modules/pr-review/agents/qa/skills/qa-review.md

@@ -19,7 +19,7 @@ You review PRs for test coverage, edge cases, and regression risk. When a PR cha
 3. Record your verdict on your review stage:
    - **approved** if quality is adequate
    - **changes_requested** with specific gaps and suggested test cases if not
-4. Optionally mirror the same verdict as a GitHub PR comment for visibility.
+4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
 
 ## Rules
 

package/templates/modules/pr-review/agents/ui-designer/skills/design-review.md

@@ -19,7 +19,7 @@ You review PRs for visual quality, brand consistency, and accessibility. When a
 3. Record your verdict on your review stage:
    - **approved** if visually sound
    - **changes_requested** with specific, actionable feedback if not
-4. Optionally mirror the same verdict as a GitHub PR comment for visibility.
+4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
 
 ## Rules
 

package/templates/modules/pr-review/agents/ux-researcher/skills/ux-review.md

@@ -19,7 +19,7 @@ You review PRs for usability, user flow integrity, and alignment with user needs
 3. Record your verdict on your review stage:
    - **approved** if usability is sound
    - **changes_requested** with specific, actionable feedback if not
-4. Optionally mirror the same verdict as a GitHub PR comment for visibility.
+4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
 
 ## Rules
 

package/templates/modules/pr-review/docs/pr-conventions.md

@@ -38,6 +38,24 @@ Rules: lowercase after colon, no period, under 72 chars.
 Closes [PREFIX-N]
 ```
 
+## Posting PR Bodies & Comments
+
+Always pass Markdown through a **file** (`--body-file`), never an inline `--body "..."`. A double-quoted shell argument does **not** turn `\n` into a real newline, so an inline body renders on GitHub as literal `text\ntext\ntext` instead of formatted Markdown. Write the body to a file first:
+
+```bash
+# Real newlines + full Markdown (headings, lists, code blocks) preserved.
+cat > /tmp/pr-body.md <<'EOF'
+## What changed
+...
+EOF
+
+gh pr create  --title "<type>: <description>" --body-file /tmp/pr-body.md
+gh pr comment <number> --body-file /tmp/pr-body.md
+gh pr review  <number> --request-changes --body-file /tmp/pr-body.md
+```
+
+Every PR comment opens with a Markdown heading stating the verdict (`## ✅ Approved`, `## 🔄 Changes requested`, or `## 💬 Review notes`), followed by a short summary and bullet points or code blocks.
+
 ## Labels
 
 Apply one primary label: `feature`, `bug`, `docs`, `chore`, `infra`, `agent`.
@@ -52,7 +70,7 @@ Review runs through the issue's native `executionPolicy` (stages), not separate
 4. **Code Reviewer** reviews for correctness, security, code style, simplicity and records `approved` / `changes_requested` on the review stage.
 5. **Domain reviewers** (when present as stages) review their concern and record their verdict.
 6. **Product Owner** reviews for intent match, scope discipline, acceptance criteria, and records the final `approval` verdict.
-7. Verdicts are recorded on the stages and may be mirrored as PR comments.
+7. Verdicts are recorded on the stages and may be mirrored as PR comments (always via `--body-file`; see *Posting PR Bodies & Comments*).
 8. **Engineer** owns the final `approval` stage (merge gate): once every reviewer and the Product Owner has approved, the engineer is woken last, merges the PR, confirms the merge landed, and only then records `approved` — which closes the originating issue to `done`. The merge must happen before the issue is `done`.
 
 ## Review Roles

package/templates/roles/code-reviewer/AGENTS.md

@@ -15,7 +15,7 @@ You report to the CEO.
    - **Security**: Any injection, XSS, credential exposure, or OWASP risks?
    - **Style**: Consistent with existing codebase patterns?
    - **Simplicity**: Is there unnecessary complexity? Could it be simpler?
-6. Post your review using `gh pr review <number> --approve` or `gh pr review <number> --request-changes --body "<feedback>"`.
+6. Post your review: `gh pr review <number> --approve`, or to request changes write your feedback to a Markdown file (start with a heading, e.g. `## 🔄 Changes requested`) and run `gh pr review <number> --request-changes --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext` instead of formatted Markdown.
 7. Post your verdict on the originating issue.
 8. Mark your issue as `done`.