release

/release — Automated Release Workflow

Arguments: $ARGUMENTS

You are executing the release workflow for @code-insights/cli. Parse $ARGUMENTS to extract:

• type (required): patch, minor, or major
• description (optional): A one-liner for the release title

If type is missing or not one of patch/minor/major, ask the user to provide it.

---

Step 1: Pre-flight Checks

Run ALL of these checks. If any fail, STOP and tell the user what to fix.

# Must be on master
git branch --show-current  # Must output "master"

# Must have clean working tree
git status --porcelain     # Must be empty

# Pull latest
git pull origin master

Read the current version from cli/package.json (the "version" field).

Compute the new version:

• patch: increment the third number (3.6.1 → 3.6.2)
• minor: increment the second number, reset third to 0 (3.6.1 → 3.7.0)
• major: increment the first number, reset second and third to 0 (3.6.1 → 4.0.0)

Resume detection: Run npm view @code-insights/cli version to get the currently published version. If the version in package.json is ALREADY GREATER than the npm version, this is a resumed release — skip to Step 6.

---

Step 2: Analyze Changes

Find the last git tag and analyze what changed:

# Find latest tag
git describe --tags --abbrev=0

# Commits since last tag
git log $(git describe --tags --abbrev=0)..HEAD --oneline

# Full diff since last tag
git diff $(git describe --tags --abbrev=0)..HEAD --stat

Read the full diff and commit messages. Then:

1. Generate a CHANGELOG entry in the existing format (see cli/CHANGELOG.md for style). Group changes under ### Added, ### Changed, ### Fixed, ### Improved as appropriate. Match the existing tone — concise but descriptive, with bold lead-ins.

2. Generate a release title — a short phrase summarizing the release (e.g., "LLM-Powered Export Page", "PostHog custom domain"). Use the user's description if provided, otherwise derive from the changes.