القائمة
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 ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
Selectively stages and commits only the changes related to the current session, skipping unrelated modifications.
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.
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.
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.
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.
| 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 |
Commit, rebase, build, and open/update a pull request — all in one step.
ls ./tmp/done-plans/git diff and git diff --cached to see all staged and unstaged changes.For each changed file:
Grouping rules:
./tmp/ doc changes associated with a plan go in that plan's commit.For each group:
git add <specific files> — never git add . or git add -Atype: 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.
git fetch origin maingit rebase origin/maingit add the resolved files, and git rebase --continue.git log --oneline -10 that history looks correct.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:
npm run db:diff:prod and capture the actual output SQL.BEGIN; ... COMMIT;).If schema.ts was NOT changed, omit the Schema Changes section from the PR template entirely.
Run both builds and fix any errors:
npx nx build @doozy/webapp
npx nx build @doozy/api
For each build:
Commit build fixes as a separate commit: fix: resolve build errors
gh pr view --json number,title,body,url,state 2>/dev/nullgh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
gh pr edit --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
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;
npx nx build @doozy/webapp passesnpx 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: