pg-implementlisted

Execute a PostgreSQL `planning/<slug>/plan.md` phase-by-phase under upstream-grade discipline — Phase 3 of the PG planner suite. Per-phase commits, per-phase regress/iso/TAP runs, plan-linked commit messages, and a running notes log; enforces .claude/rules/pg-implement-discipline.md (R1-R12 — every commit references the plan slug + phase number; every code claim has a file:line cite; phase-end check must pass before the next phase starts). Use when the user says "/pg-implement <slug>", "implement the plan", "let's start implementing the X plan", "execute the planning/<slug>/plan.md", or has a finalized planning/<slug>/plan.md ready to execute. Skip for ad-hoc coding without a plan (no phase structure), non-PG implementation (app code, infra, scripts), the generic /implement flow (multi-project, doesn't enforce PG R1-R12 rules), and exploratory hacking where the plan is still being shaped (use pg-feature-plan instead).
matejformanek/postgres-claude · ★ 0 · AI & Automation · score 70

Install: claude install-skill matejformanek/postgres-claude

# pg-implement — Phase 3 of the PG planner suite The third stage. Brainstorm narrowed the design space; Plan made it implementable; **Implement walks the plan phase-by-phase** while enforcing the discipline rules. The pairing: - Phase 1 — `pg-feature-brainstorm` (sketch) - Phase 2 — `pg-feature-plan` (heavy plan) - **Phase 3 — `pg-implement`** (this skill, executes the plan) ## When to use vs the generic `/implement` | Project | Use | |---|---| | Anything PG-related with a `planning/<slug>/plan.md` | **`/pg-implement`** | | Generic project plan, not PG | Generic `/implement` | | Ad-hoc PG coding, no plan | Neither — write a plan first via `/pg-plan` | The PG variant exists because PG implementation has unusual constraints the generic `/implement` doesn't enforce: - Per-phase test runs against the dev cluster - File:line citation discipline (knowledge corpus must stay accurate) - Plan-linked commit messages (commits reference the plan + phase) - Upstream-vs-meta commit-message-style split - Catalog/catversion/WAL-format pre-flight before any touching edit - `/pg-restart` cadence after backend code changes ## Inputs - **Slug** (required): the planning directory under `planning/<slug>/`. Examples in this repo: `sp2-pgstr-maxalloc`, `cb1-pgcrypto-bomb`, `sp7-tablefunc-quoting`. The `dev/` branch mirrors the slug (e.g. `feature_sp2_pgstr_maxalloc`, `feature_server_side_vars`). - Must contain `plan.md` produced by `pg-feature-plan`. - May contain `brainstorm.md` (Phas