القائمة
Push the current branch and create a production-ready PR with a complete description (What, Why, How to test). Runs /review-pr first if not already done. Use when implementation is complete.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Launch and drive the Gatherly app locally (FastAPI backend + Next.js frontend) and verify it renders. Use when asked to run, start, launch, or screenshot the app, or to confirm a change works in the real running app.
Scan code for security violations S1-S8 (auth, tenant isolation, RBAC, rate limiting, audit logging, raw SQL, secrets, HTTP timeouts). Use before commit on any code touching endpoints, services, or data access.
Run the event-readiness checklist against an event. Evaluates the readiness checks, produces findings, and routes them to the host. Use when the user asks to audit, score, or check the readiness of an event.
Commit changes with the dev-gatherly git identity using Conventional Commits format. Use after every atomic step in the REPL loop.
Monitor CI/CD pipeline runs, diagnose failures, and route fixes to the right phase. Use after pushing a branch or when a pipeline turns red.
Read-only deep-dive into the codebase to understand patterns, data flow, and integration points before modifying anything. Use before any non-trivial change.
| name | create-pr |
| description | Push the current branch and create a production-ready PR with a complete description (What, Why, How to test). Runs /review-pr first if not already done. Use when implementation is complete. |
| allowed-tools | Bash, Read |
Local setup: requires a GitHub remote +
ghCLI, which aren't configured here (local-only git). With no remote, run/review-pr, leave the work on its feature branch, and hand it to a human for review/merge — never merge yourself.
You ship the current branch as a PR ready for human review. Production-ready means: tests pass, lint passes, audit-security clean, review-pr clean of CRITICAL/HIGH bugs.
main or mastermain (rebase if needed; conflicts → ask user)make lint && make test (backend if touched)pnpm lint && pnpm build (frontend if touched)/audit-security on the changes/review-pr if not already run for this branch
git push -u origin <branch>gh pr create and the structured description below## What
<2-3 sentences describing what this PR delivers, in user-facing terms.>
Closes #<issue-number> <if applicable>
Refs F-<feature-id>
## Why
<2-3 sentences explaining the problem this solves and why now.>
## How to test
<Step-by-step instructions a reviewer can follow on their machine.>
```bash
# Backend
cd gatherly-be
make dev
# Frontend (in another terminal)
cd gatherly-fe
pnpm dev
Then:
admin@acme.dev (password: dev)<List any DB schema changes (Gatherly uses SQLite, no Alembic migrations) and whether they're backward-compatible with existing data.>
events.location column — nullable, backward-compatible with existing rows.<Optional: tickets created for non-blocking improvements>
## Refusing to create a PR
You refuse if:
- Tests are failing
- Audit-security has CRITICAL or HIGH violations
- The branch is `main`
- Uncommitted changes exist
- The diff is suspiciously empty or huge without explanation
## Output format
✅ PR created: https://github.com//gatherly/pull/87
Title: feat(be): add event editing from the detail page Branch: feat/F-12-event-editing → main Files: 11 changed, +487 / -23 Tests: 12 new, all green Reviewers: @platform-team
Pipeline started. Use /devops watch to monitor.
## What you must NOT do
- Push with `--force` or `--force-with-lease` without explicit user approval
- Create a draft PR unless requested (we want full review)
- Auto-assign reviewers without checking the team conventions
- Skip the description fields. "Self-explanatory" is never an acceptable PR description.
- Merge the PR. Human approval is mandatory.