# Release Checker Agent

**Agent Name:** Release Checker Agent
**Role:** Release readiness verification auditor
**Frequency:** Every Thursday at 10:00 AM
**Output Channel:** #product-gang (Slack)
**Run Time:** ~12 minutes

---

## PURPOSE

Wednesday you ran your Release Readiness report. You got back a list of what's in progress, what's at risk, what's missing. Thursday morning, you need to verify: did the team actually fix those things? Or are we shipping with the same gaps?

The Release Checker Agent is your final gate. It runs 3 days before your target release date and does a verification pass on everything that was flagged as critical or high-risk. It checks that QA finished their tests, documentation is actually written, GTM materials are ready, and all required sign-offs are in place.

This agent is the difference between "we shipped something" and "we shipped something that customers understood, could use, and that we supported."

---

## DATA SOURCES

### 1. **QA Test Results** (TestRail, Jira, custom QA tool)
**Query:**
- For each feature scheduled to ship: test case status (passed / failed / not started)
- Test coverage (% of user paths tested)
- Critical tests: all passed? Any failed?
- Regression tests: all passed?
- Extract: Feature name, test status, blockers, last updated timestamp

**Extraction Rule:**
- Feature with test coverage < 80% = HIGH RISK
- Feature with failed critical tests = BLOCKER
- Feature with regression test failures = BLOCKER

### 2. **Documentation Status** (Notion, Google Docs, Help/Knowledge Base)
**Query:**
- For each shipping feature: is there a help article? Is it published?
- Release notes entry: exists and complete?
- API documentation: updated if applicable?
- Changelog entry: written?
- Sales enablement docs: written?
- Extract: Document name, status (draft / review / published), last modified, completeness %

**Extraction Rule:**
- Help article missing = HIGH
- Help article in draft status past deadline = HIGH
- Release notes entry missing = HIGH
- Release notes entry incomplete = HIGH

### 3. **GTM Materials Checklist** (Asana, Monday.com, shared spreadsheet)
**Query:**
- Sales deck: slide created, talking points written?
- Marketing email: drafted and reviewed?
- Customer communication: written and reviewed?
- Sales training: scheduled or completed?
- Support training: scheduled or completed?
- Extract: Item, owner, status, deadline, notes

**Extraction Rule:**
- Sales enablement not done 3 days before launch = HIGH
- Marketing communication not reviewed = HIGH
- Support training not done before launch = BLOCKER

### 4. **Sign-Off Tracking** (Email, Slack, Approval workflow)
**Query:**
- PM sign-off: required? Completed?
- QA sign-off: required? Completed?
- Engineering sign-off: required? Completed?
- Design sign-off (if applicable): required? Completed?
- Security review (if applicable): required? Completed?
- Compliance review (if applicable): required? Completed?
- Extract: Feature name, sign-off type, owner, status, date signed off, any conditions

**Extraction Rule:**
- Any required sign-off missing = BLOCKER
- Any sign-off with conditions not met = BLOCKER
- Any sign-off > 7 days old (may need re-verification) = MEDIUM RISK

### 5. **Feature Flag Configuration** (GitHub, feature management platform)
**Query:**
- For each shipping feature: is there a kill switch (feature flag)?
- Flag type: boolean, percentage rollout, or targeted?
- Flag status: correctly configured for launch?
- Rollout plan: 0% (dark launch) or immediate full rollout?
- Extract: Feature name, flag name, flag status, rollout plan

**Extraction Rule:**
- Feature shipping with no kill switch = HIGH
- Feature flag misconfigured = HIGH
- Rollout plan undefined = MEDIUM

---

## REPORT STRUCTURE

### 1. RELEASE HEADER & GO/NO-GO RECOMMENDATION

Top of report: Are we shipping or are we not?

**Format:**
```
**RELEASE: [Release Name]**
**Target Date:** [Date]
**Days Until Release:** [N]
**RECOMMENDATION: [GO / NO-GO / GO WITH CAUTION]**

[If NO-GO or CAUTION: Why, and what needs to be fixed]

Last verification: Wednesday [date]
This verification: Thursday [date]
Changes since Wednesday: [N blockers resolved, M new blockers, X items still at risk]
```

### 2. QA STATUS BY FEATURE

Feature-by-feature breakdown of test status.

**Format:**
```
| Feature | Test Coverage | Critical Tests | Regression Tests | Status | Blocker? |
|---|---|---|---|---|---|
| [Feature] | 95% | ✅ All passed | ✅ All passed | 🟢 Ready | No |
| [Feature] | 72% | ✅ All passed | ⚠️ 1 failing | 🟡 At Risk | No |
| [Feature] | 60% | ❌ 2 failed | 🟡 Blocked | 🔴 Blocked | YES |

Summary:
- Total features shipping: [N]
- QA cleared: [N] features (X%)
- At risk (coverage < 80%): [N] features
- Blocked (failed critical tests): [N] features
```

**Action Required:**
```
Features that need QA attention before Thursday EOD:
- [Feature]: [Issue]. QA owner: [Name]. Target: [resolve by EOD Thursday]
- [Feature]: [Issue]. QA owner: [Name]. Target: [resolve by EOD Thursday]
```

### 3. DOCUMENTATION COMPLETENESS

What's written, what's missing, what's incomplete.

**Format:**
```
**Help Articles**
| Feature | Help Article | Status | Last Updated | Owner | Publish Date |
|---|---|---|---|---|---|
| [Feature] | [Link] | 📋 Published | [Date] | [Name] | ✅ Live |
| [Feature] | [Link] | 📝 Draft | [Date] | [Name] | ⚠️ Not live |
| [Feature] |, | ❌ Missing |, | [Name] | 🔴 BLOCKER |

**Release Notes**
| Feature | Tier | Written | Complete | Published | Reviewed | Owner |
|---|---|---|---|---|---|---|
| [Feature] | 1 | ✅ | ✅ | ✅ | ✅ | [Name] |
| [Feature] | 2 | ✅ | ⚠️ Missing customer impact | ❌ | ⚠️ | [Name] |
| [Feature] | 3 | ⚠️ Draft | ⚠️ | ❌ | ❌ | [Name] |

**Changelog**
- Updated: [Date] | Item count: [N] | Status: ✅ Ready

Documentation Summary:
- Help articles written: [N] / [N] (X%)
- Release notes sections complete: [N] / [N] (X%)
- Missing or incomplete: [N] items (name them)
```

**Critical Gaps:**
```
🔴 BLOCKERS:
- [Feature]: No help article (3 days from launch)
- [Feature]: Release notes missing customer impact statement
```

### 4. GTM READINESS VERIFICATION

Sales, marketing, support, are they ready?

**Format:**
```
**Sales Enablement**
| Item | Owner | Status | Last Updated | Ready? |
|---|---|---|---|---|
| Sales deck created | [Name] | ✅ Done | [Date] | ✅ |
| Talking points written | [Name] | ✅ Done | [Date] | ✅ |
| Sales training scheduled | [Name] | ⚠️ In progress | [Date] | ❌ |
| Sales CRM updated | [Name] | ✅ Done | [Date] | ✅ |

**Marketing / Customer Communication**
| Item | Owner | Status | Last Updated | Ready? |
|---|---|---|---|---|
| Launch email drafted | [Name] | ✅ Done | [Date] | ✅ |
| Email reviewed/approved | [Name] | ⚠️ Pending | [Date] | ❌ |
| Launch blog post | [Name] | ✅ Done | [Date] | ✅ |
| Customer announcement | [Name] | ⚠️ Draft | [Date] | ❌ |

**Support Readiness**
| Item | Owner | Status | Last Updated | Ready? |
|---|---|---|---|---|
| Support team trained | [Name] | ✅ Done | [Date] | ✅ |
| Support documentation | [Name] | ✅ Done | [Date] | ✅ |
| FAQs written | [Name] | ⚠️ In progress | [Date] | ❌ |

GTM Summary:
- Sales ready: [Y/N] (X% complete)
- Marketing ready: [Y/N] (X% complete)
- Support ready: [Y/N] (X% complete)
```

**Gaps:**
```
🔴 CRITICAL GAPS:
- Sales training: Not scheduled. Sales team will ship unprepared.
- Customer communication: Draft not reviewed. Risk of miscommunication.

⚠️ AT RISK:
- Support FAQs: 80% complete. Should be done by Thursday EOD.
```

### 5. SIGN-OFF STATUS

Who approved this release? Who hasn't yet?

**Format:**
```
| Sign-Off Type | Owner | Status | Date | Conditions |
|---|---|---|---|---|
| PM Approval | [Name] | ✅ Signed off | [Date] | None |
| QA Approval | [Name] | ✅ Signed off | [Date] | None |
| Engineering Approval | [Name] | ⚠️ Pending | [Date] | [Condition: all critical tests pass] |
| Design Approval | [Name] | ✅ Signed off | [Date] | None |
| Security Review | [Name] | ⚠️ In progress | [Date] | [Will complete by Wed EOD] |

Sign-Off Summary:
- Required sign-offs: [N]
- Completed: [N] (X%)
- Pending: [N] (owners: [Names])
```

**Blockers:**
```
🔴 BLOCKING SIGN-OFFS:
- Engineering approval: Still pending (depends on all critical tests passing)
- Security review: In progress. Promised completion Wednesday EOD.
```

### 6. FEATURE FLAG STATUS

Are the kill switches configured?

**Format:**
```
| Feature | Flag Name | Type | Status | Rollout Plan | Verified? |
|---|---|---|---|---|---|
| [Feature] | `feature_x_flag` | Boolean | ✅ Created | Dark launch (0%) | ✅ |
| [Feature] | `feature_y_flag` | Percentage | ✅ Created | 100% rollout | ✅ |
| [Feature] | `feature_z_flag` | Targeted | ⚠️ Misconfigured | Should be 10% not 50% | ❌ |
| [Feature] |, |, | ❌ Missing |, | ❌ |

Feature Flag Summary:
- Features with kill switches: [N] / [N] (X%)
- Misconfigured: [N] (names: [Feature, Feature])
- Missing: [N] (names: [Feature, Feature])
```

**Critical Issues:**
```
🔴 BLOCKERS:
- [Feature]: No flag configured. Shipping without a kill switch.
- [Feature]: Flag set to 50% but rollout plan says dark launch (0%).
```

### 7. RELEASE BLOCKERS (CRITICAL)

Everything that would prevent you from shipping.

**Format:**
```
**BLOCKER 1: [QA Failure]**
- Feature: [Name]
- Issue: [Critical test failing]
- Impact: Feature is broken for [user segment]
- Owner: [Name]
- Action: Fix by [deadline]
- Severity: 🔴 BLOCKER

**BLOCKER 2: [Sign-Off Missing]**
- Required approval: [Engineering sign-off]
- Owner: [Name]
- Condition: [Must complete security review]
- Severity: 🔴 BLOCKER

**BLOCKER 3: [Documentation Missing]**
- Documentation: [Help article]
- Feature: [Name]
- Impact: Customers won't know how to use this
- Owner: [Name]
- Action: Publish by [deadline]
- Severity: 🔴 BLOCKER
```

**Bottom Line:**
```
Total blockers: [N]
If not resolved by Thursday EOD: [Release slips / Specific features descope]
```

### 8. GO/NO-GO DECISION FRAMEWORK

Final recommendation and reasoning.

**Format:**
```
**RECOMMENDATION: [GO / NO-GO / GO WITH CAUTION]**

**GO** (proceed as planned):
- All QA cleared
- All documentation published
- All sign-offs complete
- All feature flags configured
- GTM ready

**NO-GO** (delay release):
- [List blockers that make shipping impossible]
- Estimated fix time: [X hours / X days]
- Recommended new release date: [Date]

**GO WITH CAUTION** (proceed but with risk):
- [List items that are at risk but not blockers]
- Mitigation plan: [What will you do to manage risk?]
- Escalation plan: [If these blow up, what's the fallback?]
```

---

## HOW TO SET IT UP

### Step 1: Connect QA Tool
- Get API access to TestRail, Jira, or your QA tracking system
- Configure queries to pull: test case status, coverage %, passed/failed counts
- For each shipping feature, map to test cases that must pass

### Step 2: Connect Documentation Tools
- Get read access to Notion, Google Docs, or wherever you store documentation
- Set up queries for: help articles, release notes document, changelog
- Define "complete" for each doc type (e.g., release notes must have: description, customer impact, KB link)

### Step 3: Set Up GTM Checklist
- Create a shared Asana/Monday/Sheet that GTM owns
- Define: sales deck, talking points, marketing email, customer communication, support training, FAQs
- Agent will pull status from this checklist

### Step 4: Create Sign-Off Workflow
- Define who must sign off (PM, QA, Engineering, Design, Security, Compliance)
- Set up a simple approval document or email chain
- Agent will check: signature presence, date signed, any conditions noted

### Step 5: Connect Feature Flag Platform
- Get API access to your feature flag management tool (Statsig, LaunchDarkly, custom)
- Configure to pull: flag name, flag type, current status, rollout %

### Step 6: Define Release Schedule
- Set your standard release day (e.g., Monday 2pm)
- Calculate: Thursday 10am is 3 days before
- Configure agent to run Thursday AM every week

---

## SAMPLE PROMPT (Customizable)

```
You are a release operations specialist. Your job is to verify that a release is actually ready to ship.

DATA INPUTS:
- QA test results from [QA tool]
- Documentation status from [docs platform]
- GTM readiness checklist
- Sign-off tracking
- Feature flag status

INSTRUCTIONS:
1. For each feature scheduled to ship: verify QA has passed all critical tests (coverage > 80%)
2. For each feature: verify help article is published, release notes entry is complete, changelog is updated
3. Verify all GTM items are done: sales deck, talking points, marketing email, customer communication, support training
4. Verify all required sign-offs are complete: PM, QA, Engineering, Design, Security (if applicable)
5. Verify each feature has a configured kill switch (feature flag)
6. Identify all blockers: anything that would prevent shipping
7. Identify all at-risk items: things not done but might be OK if resolved by EOD Thursday
8. Give a clear GO / NO-GO / GO WITH CAUTION recommendation
9. If not GO: explain what needs to be fixed and by when

TONE: Action-oriented, clear priorities, no ambiguity.
OUTPUT: Markdown formatted for Slack. Start with GO/NO-GO recommendation at top.
```

---

## FREQUENCY & TIMING

- **Frequency:** Every Thursday
- **Time:** 10:00 AM
- **Runtime:** ~12 minutes
- **Timezone:** Your company's primary timezone
- **Note:** Assumes your release day is Monday. Adjust day/time if your release day is different.

---

## WHAT SUCCESS LOOKS LIKE

✓ No surprises on release day, you know exactly what's ready and what's not
✓ Blockers get fixed Thursday, not discovered Friday when it's too late
✓ QA is held accountable (they know you're verifying their tests)
✓ Documentation actually gets published (not forgotten in the chaos)
✓ GTM is ready (sales knows how to pitch, support knows how to help, customers are prepared)
✓ Kill switches work (if something breaks, you can roll it back in 5 minutes)
✓ Releases are boring (nothing surprising happens because you verified everything)