ワンクリックでManusで任意のスキルを実行

prepare-pr

スター284

フォーク190

更新日2026年4月21日 17:52

Commits changes grouped by done-plans, rebases main, builds API and webapp, then creates or updates a PR. Replaces the commit command. Use when you're ready to open or update a pull request.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

dcouple

dcouple/Pane

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Prepare PR Agent

Commit, rebase, build, and open/update a pull request — all in one step.

Step 1: Commit Changes Grouped by Done-Plans

Gather info

List all done plans: ls ./tmp/done-plans/
Read each done-plan to understand what files and features it covers.
Run git diff and git diff --cached to see all staged and unstaged changes.

Associate changes with plans

For each changed file:

Read the diff to understand what changed.
Match to a done-plan by topic, referenced files, or feature area.
Group into logical commit units — one commit per plan.

Grouping rules:

Files related to the same done-plan go in one commit.
Infrastructure/config supporting a plan goes with that plan's commit.
./tmp/ doc changes associated with a plan go in that plan's commit.
Unrelated changes (no matching plan) get their own commit with a descriptive message.

Create commits

For each group:

git add <specific files> — never git add . or git add -A
Review staged diff for secrets or credentials — warn the user if found.
Commit with message: type: short description (feat, fix, refactor, docs, chore). Under 72 chars. Imperative mood.

Conventions: Reference the plan name in the commit body if helpful. Keep subjects concise.

Step 2: Rebase Main onto Current Branch

Fetch latest main: git fetch origin main
Rebase: git rebase origin/main
If conflicts occur:
- Read the conflicting files and the incoming vs current changes.
- If the resolution is obvious (e.g., non-overlapping additions, trivial formatting), resolve it yourself, git add the resolved files, and git rebase --continue.
- If the resolution is ambiguous (e.g., both sides changed the same logic, semantic conflicts), show the user the conflict with context and ask them how to resolve it. Wait for their response before continuing.
After rebase completes, verify with git log --oneline -10 that history looks correct.

Step 2.5: Generate Production Migration SQL (If Schema Changed)

Check if apps/api/src/shared/db/schema.ts was modified in any commit on this branch (vs origin/main):

git diff origin/main...HEAD --name-only | grep schema.ts

If schema.ts was changed:

Run npm run db:diff:prod and capture the actual output SQL.
Wrap it in a transaction block (BEGIN; ... COMMIT;).
Include the actual SQL in the PR description under the Schema Changes section — not instructions to run a command.
Only include additive SQL (CREATE, ADD). If destructive SQL (DROP, ALTER type) appears, flag it for the user to review and confirm.

If schema.ts was NOT changed, omit the Schema Changes section from the PR template entirely.

Step 3: Build and Fix Errors

Run both builds and fix any errors:

Build webapp

npx nx build @doozy/webapp

Build API

npx nx build @doozy/api

For each build:

If it passes, move on.
If it fails, read the error output carefully:
- Fix type errors, missing imports, and build issues.
- After fixing, re-run the failing build to confirm the fix.
- Repeat until both builds pass.
If a fix requires non-trivial changes (architectural issues, missing dependencies), tell the user and ask how to proceed.

Commit build fixes as a separate commit: fix: resolve build errors

Step 4: Create or Update Pull Request

Check for existing PR: gh pr view --json number,title,body,url,state 2>/dev/null

If no PR exists — create one

gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

If PR already exists — update it

gh pr edit --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

PR Description Template

Build the PR description from the done-plans. List work in chronological order based on plan dates (the YYYY-MM-DD prefix in filenames). When updating an existing PR, append new work to the existing description — never overwrite previous entries.

## Summary
[1-3 sentence overview derived from done-plans and context.md]

## Work Completed
### 1. [Plan/Feature Name from earliest done-plan]
- Key changes and what they accomplish

### 2. [Plan/Feature Name from next done-plan]
- Key changes and what they accomplish

### 3. [Plan/Feature Name from latest done-plan]
- Key changes and what they accomplish

## Pre-Merge Testing
- [ ] [Short, specific thing to test based on the changes — e.g., "Verify new endpoint returns 200 with valid payload"]
- [ ] [Another key behavior to verify]
- [ ] [Edge case or integration point worth checking]

## Schema Changes
<!-- Only include this section if schema.ts was modified -->
- [ ] Migration SQL reviewed
- [ ] Migration applied to staging
- [ ] Migration applied to production

### Production Migration SQL
⚠️ Run this SQL against the production database BEFORE deploying:
```sql
BEGIN;
-- actual generated SQL from npm run db:diff:prod goes here
COMMIT;

Build Verification

npx nx build @doozy/webapp passes
npx nx build @doozy/api passes


Use `$ARGUMENTS` as the PR title if provided, otherwise derive one from the done-plans.

## Step 5: Push to Remote

1. Push the branch: `git push -u origin <branch> --force-with-lease`
   - Use `--force-with-lease` since we rebased (safer than `--force`).
2. If `--force-with-lease` fails (remote has new commits not in local), tell the user and ask how to proceed.

## Step 6: Summary

Present the final result:

PR ready.

Commits:

Build: webapp: PASS api: PASS

PR: Branch: (rebased on main)

Done-plans included:

このリポジトリの他の Skills

同じリポジトリ

implement

dcouple/Pane

Executes an approved plan with one primary implementation stream by default, using bounded parallel sidecars only when the write scopes are truly disjoint. Supports default Claude execution or an explicit Codex executor option. Automatically reviews the result for completeness and intent fidelity. Use after a plan is approved.

2026-04-25284

commit

dcouple/Pane

Selectively stages and commits only the changes related to the current session, skipping unrelated modifications.

2026-04-25284

implement

dcouple/Pane

Executes an approved plan directly in Codex with one primary implementation stream by default, bounded sidecars only when write scopes are truly disjoint, and mandatory review gates for completeness and intent fidelity. Use after a plan is approved.

2026-04-25284

implementation-reviewer

dcouple/Pane

Review completed code changes against a plan, run quality checks, and call out gaps, regressions, or missing integrations. Use when implementation work needs a plan-based review.

2026-04-25284

implementer

dcouple/Pane

Carry out a structured implementation plan carefully and systematically, following existing repo patterns, preserving intent, and running quality checks as work progresses. Use when a plan already exists and the goal is execution.

2026-04-25284

plan-reviewer

dcouple/Pane

Review an implementation plan for repo accuracy, fact purity, intent fidelity, reconciliation quality, and completeness. Use when a plan needs a correctness and completeness pass.

2026-04-25284

name	prepare-pr
description	Commits changes grouped by done-plans, rebases main, builds API and webapp, then creates or updates a PR. Replaces the commit command. Use when you're ready to open or update a pull request.
argument-hint	[optional: PR title or description]
disable-model-invocation	true

Prepare PR Agent

Commit, rebase, build, and open/update a pull request — all in one step.

Step 1: Commit Changes Grouped by Done-Plans

Gather info

List all done plans: ls ./tmp/done-plans/
Read each done-plan to understand what files and features it covers.
Run git diff and git diff --cached to see all staged and unstaged changes.

Associate changes with plans

For each changed file:

Read the diff to understand what changed.
Match to a done-plan by topic, referenced files, or feature area.
Group into logical commit units — one commit per plan.

Grouping rules:

Files related to the same done-plan go in one commit.
Infrastructure/config supporting a plan goes with that plan's commit.
./tmp/ doc changes associated with a plan go in that plan's commit.
Unrelated changes (no matching plan) get their own commit with a descriptive message.

Create commits

For each group:

git add <specific files> — never git add . or git add -A
Review staged diff for secrets or credentials — warn the user if found.
Commit with message: type: short description (feat, fix, refactor, docs, chore). Under 72 chars. Imperative mood.

Conventions: Reference the plan name in the commit body if helpful. Keep subjects concise.

Step 2: Rebase Main onto Current Branch

Fetch latest main: git fetch origin main
Rebase: git rebase origin/main
If conflicts occur:
- Read the conflicting files and the incoming vs current changes.
- If the resolution is obvious (e.g., non-overlapping additions, trivial formatting), resolve it yourself, git add the resolved files, and git rebase --continue.
- If the resolution is ambiguous (e.g., both sides changed the same logic, semantic conflicts), show the user the conflict with context and ask them how to resolve it. Wait for their response before continuing.
After rebase completes, verify with git log --oneline -10 that history looks correct.

Step 2.5: Generate Production Migration SQL (If Schema Changed)

Check if apps/api/src/shared/db/schema.ts was modified in any commit on this branch (vs origin/main):

git diff origin/main...HEAD --name-only | grep schema.ts

If schema.ts was changed:

Run npm run db:diff:prod and capture the actual output SQL.
Wrap it in a transaction block (BEGIN; ... COMMIT;).
Include the actual SQL in the PR description under the Schema Changes section — not instructions to run a command.
Only include additive SQL (CREATE, ADD). If destructive SQL (DROP, ALTER type) appears, flag it for the user to review and confirm.

If schema.ts was NOT changed, omit the Schema Changes section from the PR template entirely.

Step 3: Build and Fix Errors

Run both builds and fix any errors:

Build webapp

npx nx build @doozy/webapp

Build API

npx nx build @doozy/api

For each build:

If it passes, move on.
If it fails, read the error output carefully:
- Fix type errors, missing imports, and build issues.
- After fixing, re-run the failing build to confirm the fix.
- Repeat until both builds pass.
If a fix requires non-trivial changes (architectural issues, missing dependencies), tell the user and ask how to proceed.

Commit build fixes as a separate commit: fix: resolve build errors

Step 4: Create or Update Pull Request

Check for existing PR: gh pr view --json number,title,body,url,state 2>/dev/null

If no PR exists — create one

gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

If PR already exists — update it

gh pr edit --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

PR Description Template

## Summary
[1-3 sentence overview derived from done-plans and context.md]

## Work Completed
### 1. [Plan/Feature Name from earliest done-plan]
- Key changes and what they accomplish

### 2. [Plan/Feature Name from next done-plan]
- Key changes and what they accomplish

### 3. [Plan/Feature Name from latest done-plan]
- Key changes and what they accomplish

## Pre-Merge Testing
- [ ] [Short, specific thing to test based on the changes — e.g., "Verify new endpoint returns 200 with valid payload"]
- [ ] [Another key behavior to verify]
- [ ] [Edge case or integration point worth checking]

## Schema Changes
<!-- Only include this section if schema.ts was modified -->
- [ ] Migration SQL reviewed
- [ ] Migration applied to staging
- [ ] Migration applied to production

### Production Migration SQL
⚠️ Run this SQL against the production database BEFORE deploying:
```sql
BEGIN;
-- actual generated SQL from npm run db:diff:prod goes here
COMMIT;

Build Verification

npx nx build @doozy/webapp passes
npx nx build @doozy/api passes


Use `$ARGUMENTS` as the PR title if provided, otherwise derive one from the done-plans.

## Step 5: Push to Remote

1. Push the branch: `git push -u origin <branch> --force-with-lease`
   - Use `--force-with-lease` since we rebased (safer than `--force`).
2. If `--force-with-lease` fails (remote has new commits not in local), tell the user and ask how to proceed.

## Step 6: Summary

Present the final result:

PR ready.

Commits:

Build: webapp: PASS api: PASS

PR: Branch: (rebased on main)

Done-plans included: