Assess Release Readiness

Analyze a branch to determine if it's ready for release.

Analysis Tasks

1. •

   Review code changes: Check git diff main..HEAD for:

   • •Incomplete work (TODO, FIXME, XXX comments in new code)
   • •Security concerns (hardcoded secrets, credentials)
   • •Runtime errors or obvious bugs
2. •

   Check for blocking issues:

   • •Tests failing (if tests exist)
   • •Type errors (if type checking exists)
   • •Missing files referenced in code
3. •

   Identify actionable items (not theoretical concerns):

   • •Documentation that needs updating
   • •Version numbers to bump
   • •Files to stage/commit before release

What NOT to Flag

• •"Breaking changes" for command renames - users adapt
• •API changes in a plugin - plugins are configuration, not APIs
• •Internal refactoring - doesn't affect users
• •Theoretical upgrade concerns - users pull fresh versions

Output Format

Return JSON:

{
  "releasable": true,
  "verdict": "Ready for release",
  "concerns": [],
  "instructions": {
    "pre_release": [],
    "post_release": []
  }
}

Or if issues found:

{
  "releasable": false,
  "verdict": "Needs attention before release",
  "concerns": [
    "Found TODO comment in src/foo.ts",
    "Tests failing in commands/drive.md"
  ],
  "instructions": {
    "pre_release": ["Fix failing tests", "Remove TODO comments"],
    "post_release": []
  }
}

Guidelines

• •Focus on issues that actually block releases
• •Provide actionable instructions, not theoretical warnings
• •"Breaking change" is rarely a real concern for plugins
• •Empty concerns array is the happy path, not a failure
• •If it doesn't require action, don't flag it