# Companion Prompts — Godsfavour Okpara Portfolio CMS

Use these alongside `MASTER-PROMPT.md` when running the build in Claude Code.

**Setup before the first run:**
1. Put the PRD in the repository at `docs/prd/` (the `.docx` is fine; the agent converts it).
2. Save `MASTER-PROMPT.md` at `docs/implementation/MASTER-PROMPT.md`. Prompt 2 depends on this file existing.

**Typical run order:**
1. Paste the master prompt. The agent stops at the Phase 2 gate.
2. Review its documents, then send Prompt 1.
3. Run Prompt 3 after each phase.
4. Use Prompt 2 whenever a session resets.
5. Finish with Prompt 4.

---

## 1. Phase-gate approval

Paste this after reviewing `01-DISCOVERY.md` and `ARCHITECTURE.md`.

```
Architecture review complete. Decisions:

- APPROVED as proposed, except for the changes below.
- Changes: [list any, e.g. "use Filament Repeater-over-relationship for sections, not Builder sync"; "skip custom_embed block entirely"; "analytics default driver: Plausible"]
- Open questions answered: [answer any questions the agent raised]

Record these decisions in docs/architecture/DECISIONS.md, update ARCHITECTURE.md and TRACEABILITY.md to match, then begin PHASE 3 — FOUNDATION.

Work through Phases 3 to 6 without stopping for approval, EXCEPT:
- before any destructive or data-affecting operation;
- before installing a package not named in the approved architecture;
- if a package is incompatible and the alternative changes the architecture.

At the end of each phase: run tests and Pint, update PROGRESS.md, and give me a short summary before continuing.
```

---

## 2. Session resume

Paste this at the start of every new Claude Code session.

```
You are resuming the Godsfavour Okpara Portfolio CMS build (Laravel + Filament). The original master prompt is saved at docs/implementation/MASTER-PROMPT.md and remains the governing instruction set. The PRD at docs/prd/portfolio-prd.md is the functional source of truth.

Before writing any code:
1. Read, in order: docs/implementation/MASTER-PROMPT.md, docs/implementation/PROGRESS.md, docs/architecture/ARCHITECTURE.md, docs/architecture/DECISIONS.md, docs/implementation/TRACEABILITY.md.
2. Run `git status` and `git log --oneline -20`, and run the test suite. Report the current phase, the last completed step, failing tests, uncommitted changes, and open TODO(portfolio) markers.
3. Check that the codebase matches what PROGRESS.md claims. Where they disagree, trust the code, then correct PROGRESS.md.
4. State the next three concrete steps, then continue from where the previous session stopped.

Do not redo completed work. Do not re-architect approved decisions. If a decision must change, propose it as a new ADR and wait for approval.
```

---

## 3. Phase audit

Paste this at the end of each phase, ideally in a fresh session so the reviewer isn't the author.

```
Act as an independent senior reviewer. Do NOT write new features. Audit the work completed for PHASE [N] against docs/implementation/MASTER-PROMPT.md and the PRD.

Check and report with file/line evidence:
1. Hardcoded professional content in Blade/PHP/JS/CSS (any string that should come from the CMS).
2. Business logic in controllers, Filament resources, or Blade templates instead of Actions/Services/Queries.
3. Missing policies or permission checks, including Filament bulk actions and relation managers.
4. Unsanitised {!! !!} output or unvalidated block payloads.
5. N+1 queries and missing eager loads (run the suite with lazy-loading prevention on).
6. Missing indexes, foreign keys, or unique constraints in this phase's migrations.
7. Any Section 0.4 invariant touched by this phase that is not yet satisfied.
8. Tests that are missing, skipped, or asserting nothing meaningful.
9. TRACEABILITY.md or PROGRESS.md entries marked complete that are not actually complete.

Output a findings table: Severity (Critical/High/Medium/Low), Finding, Evidence, Fix.
Then fix all Critical and High findings, re-run tests and Pint, and update PROGRESS.md.
```

---

## 4. Final owner handover

Paste this after Phase 8.

```
Prepare the build for owner review. Using the demo seeder on a fresh local database:
1. Walk through every §34 acceptance criterion and record pass/fail with evidence.
2. Produce docs/OWNER-GUIDE.md: a plain-language CMS guide for a non-technical owner, with no developer jargon. Cover editing the homepage, adding a project and case study, anonymising a client, replacing the CV, publishing/scheduling/previewing, booking setup, reading contact messages, and removing demo content.
3. List exactly what real content the owner must supply (PRD Appendix A), mapped to the admin screen where each item is entered.
4. Confirm `php artisan portfolio:purge-demo` works, and that the production build and caching commands succeed.
Do not mark §35 "approved by site owner" as done.
```