Problem

The /ship skill (Step 4: Version bump) uses a line-count heuristic to auto-decide bump level:

• MICRO: <50 lines changed
• PATCH: 50+ lines changed (auto)
• MINOR: asks user — "major features or significant architectural changes"
• MAJOR: asks user — milestones/breaking changes

In practice, MINOR is never triggered because the heuristic only measures how much changed, not what kind of change it is. Every real session exceeds 50 lines, so PATCH is always auto-picked without prompting.

Real-world example

Over 23 sessions on a product app (keel), the version went from 0.1.0.0 to 0.1.23.0. During that time, the following shipped — all as PATCH bumps:

• Full health score engine (7 components, 112 tests)
• Reports/P&L screen (3 tabs, AI narrative)
• Score breakdown page
• Coaching signal detection layer (8 detectors)
• PDF statement import (Claude Vision)
• Accounts management page
• Budget builder

Every one of these warranted a MINOR bump. None was ever asked about.

Suggestion

Consider a smarter heuristic that triggers the MINOR ask, e.g.:

• Branch name starts with feat/ or contains a feature identifier
• New route/page files detected in the diff (e.g. app/*/page.tsx)
• New database tables or schema files added
• Diff exceeds a higher threshold (e.g. 500+ lines)
• New test files added (signals a meaningful new module)

Any of these would be a better signal than line count alone for "should we ask about MINOR?"

Context

• gstack v0.12.2.0
• Ship skill Step 4 (line ~1526 in SKILL.md)
• The 4-digit version format is fine — the issue is purely that the auto-decide logic never escalates to MINOR