Engagement State Template
Engagement State Template
A template for tracking progress through a Plugin Audit & Cleanup engagement. Copy this into a new Google Doc at the start of every engagement and update after every work session.
This document is the single source of truth for engagement progress. At the start of every Claude session, paste the contents of this document into the chat so Claude has full context. The Claude assistant will produce update snippets at the end of each session to paste back in.
Template (copy from here)
# [CLIENT NAME] Plugin Audit & Cleanup — Engagement State
## Engagement details
- **Client:** [Name]
- **Host:** [WP Engine / Kinsta / Cloudways / other]
- **Engagement start date:** [YYYY-MM-DD]
- **Estimated hours (from quote):** [X–Y hours]
- **Hours used to date:** [running total]
- **Engagement contact:** The agency owner (all client comms go through the owner — never contact client directly)
## Site overview
- **Production URL:** [https://...]
- **Staging URL:** [https://...]
- **Theme / page builder:** [e.g., Divi 4.x, Elementor Pro, custom block theme]
- **WordPress version:** [from `wp core version`]
- **PHP version:** [from `wp eval 'echo PHP_VERSION;'`]
- **Multisite?** [yes/no]
- **Active plugin count at start:** [number]
- **Inactive plugin count at start:** [number]
## Known-good plugins (confirmed by client as in active use)
[Paste the list of plugins the client has confirmed they need. These do not get investigated for removal.]
1. [Plugin name] — [optional note on what it's used for]
2. ...
## Client-specific constraints
[Anything the owner has flagged from the engagement brief that affects how we work.]
- [e.g., "Site uses Divi, cannot migrate off"]
- [e.g., "Microsite pages /campaign-x/ and /landing-y/ must remain functional"]
- [e.g., "Gravity Forms integration with [CRM] is critical — do not touch"]
## Phase status
| Phase | Status | Notes |
|-------|--------|-------|
| 0 — Pre-flight | Not started / In progress / Done | |
| 1 — Production recon | | |
| 2 — Plugin investigation | | |
| 3 — Staging testing | | |
| 4 — Production execution | | |
| 5 — High-impact plugin resolution | | |
| 6 — Database cleanup | | |
| 7 — Wrap-up | | |
## Baseline metrics (captured during Phase 1)
- **Total active plugins:** [count]
- **Top autoloaded options by size:**
1. [option_name] — [size]
2. ...
- **Total autoload size (sum):** [MB]
- **Top database tables by size:**
1. [table_name] — [size, rows]
2. ...
- **Total database size:** [MB]
- **Cron event count:** [count]
- **Notable findings:** [e.g., "wp_options has 12MB of autoloaded data", "one plugin owns a 200MB tracking table with millions of rows", "wp_postmeta has 3.2M entries"]
## Plugin classification (built during Phase 2)
### Tier A — Safe to remove (no dependencies found)
| Plugin | Reason | Notes |
|--------|--------|-------|
| [plugin-name] | No theme refs, no shortcodes in content, no cron jobs | |
### Tier B — Likely safe, verify on staging
| Plugin | Reason | Notes |
|--------|--------|-------|
| [plugin-name] | Minor refs, looks vestigial | |
### Tier C — High-risk unknown, needs owner decision
| Plugin | Findings | Question for owner |
|--------|----------|-------------------|
| [plugin-name] | [what we found] | [specific question] |
### Tier D — Keep (confirmed dependencies)
| Plugin | Where it's used | Notes |
|--------|----------------|-------|
| [plugin-name] | [theme template / shortcode / widget / etc.] | |
## Staging testing log (Phase 3)
### Batch 1 — Tier A plugins
- **Deactivated:** [date, plugin list]
- **Tested:** [list of pages/flows tested]
- **Issues found:** [none / list]
- **Resolution:** [proceeded / reactivated X plugin / etc.]
### Batch 2 — Tier B plugins (group 1)
- ...
## Production execution log (Phase 4)
### Batch 1
- **Snapshot taken:** [date/time]
- **Deactivated:** [date/time, plugin list]
- **Observation window ends:** [date]
- **Spot check after deactivation:** [pass/fail, notes]
- **Issues observed during observation window:** [none / list]
- **Plugins deleted:** [date — only after observation window]
### Batch 2
- ...
## High-impact plugin resolution (Phase 5)
[One sub-section per high-impact plugin identified. Most engagements will have 0-2.]
### [Plugin name]
- **Why it's high-impact:** [database size, cron load, slow queries, etc.]
- **Table sizes / footprint at start:**
- [table_name]: [rows, size]
- [another_table]: [rows, size]
- **Investigation findings:**
- Theme references: [yes/no, locations]
- Shortcode usage in content: [yes/no, count]
- Widget usage: [yes/no]
- Custom integrations: [yes/no, details]
- **Conclusion:** [Not rendering — straight removal / Rendering — needs replacement decision]
- **Owner's decision:** [date, what was decided]
- **Resolution executed:** [date, what was done]
- **Footprint after:** [if applicable — table rows after, size reduction, etc.]
## Database cleanup (Phase 6)
- **Advanced Database Cleaner discovery run:** [date]
- **Orphan tables identified:** [count, list]
- **Orphan tables reviewed and removed:** [count]
- **Orphan options removed:** [count]
- **Orphan postmeta/usermeta removed:** [count]
- **Orphan cron events removed:** [count]
- **Autoload changes:** [count, notes]
- **Database size before:** [MB]
- **Database size after:** [MB]
## Open questions for owner
[Anything escalated and awaiting response.]
- [ ] [Question 1] — escalated [date]
- [ ] [Question 2] — escalated [date]
## Recommendations for follow-on work (gathered as we go)
[Things we noticed during the engagement that are outside scope but worth flagging for the owner's follow-on conversations with the client.]
- [e.g., "Divi performance settings not enabled — would benefit from a separate tuning engagement"]
- [e.g., "wp_options has high autoload from heavy plugin we kept — worth investigating optimization options"]
- [e.g., "Theme has uncached queries in single.php — performance refactor opportunity"]
## Session log
[Brief notes after each session: date, hours, what was done, key findings, next session goal.]
### Session [N] — [YYYY-MM-DD]
- **Hours:** [X]
- **Phase worked on:** [phase number]
- **What was done:** [summary]
- **Key findings:** [anything notable]
- **Next session goal:** [what comes next]
### Session [N-1] — [YYYY-MM-DD]
- ...
---
## Final summary (populated at end of engagement)
- **Plugins at start:** [count active]
- **Plugins at end:** [count active]
- **Plugins removed:** [count]
- **Database size before:** [MB]
- **Database size after:** [MB]
- **High-impact plugin outcomes:** [list each plugin handled in Phase 5 with before/after numbers — e.g., "Plugin X table: 5.4M rows → 0 rows" or "Plugin Y replaced with custom code, removed 200MB from DB"]
- **Total hours used:** [number]
- **Client summary document:** [link to client summary]
How to use this template
-
At engagement start: Create a new Google Doc in the client's folder titled
[Client Name] Plugin Audit & Cleanup — Engagement State. Copy the template above into it. Fill in the engagement details, site overview, known-good plugins, and client-specific constraints from the brief. -
At each Claude session start: Open the state doc, copy its current contents, paste into a new chat in the WordPress Plugin Audit & Cleanup Claude project. State which phase you're working on.
-
At each Claude session end: Claude will produce a markdown snippet summarizing what was done. Paste that into the relevant sections of the state doc.
-
Throughout: Keep the state doc current. It's what makes asynchronous work and AI assistance possible — without it, every session starts from zero.
-
At engagement end: Use the final state doc as the source for the Client Summary deliverable.