.comThis is falkster.com, the notebook. Falkster.AI is the company.Go to falkster.ai

Release Checker Agent

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 thi...

agent-release-checker.md14 KB2,353 words
Download

From this piece

The template

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)

More from the toolkit

All templates →