Sdlcreview

Submit for Review

Commit, push, and create a PR for code review.

In all bash steps below, substitute placeholder names (like BASE_BRANCH, CURRENT_BRANCH, etc.) with the actual values you stored earlier.

Workflow

1. Verify branch state on a feature branch with changes
2. Detect and remove dead code introduced by this branch
3. Commit and push all changes
4. Create PR with a comprehensive description

Step 1: Verify Branch State

Follow Branch Verification.

If CURRENT_BRANCH equals BASE_BRANCH, stop with error: "Cannot create PR from default branch".

Check if a PR already exists for this branch:

gh pr view --json number,state --jq '.number,.state'

If a PR already exists, report its number and state. If it is open, ask the user whether to update the existing PR (just push new commits) or proceed with a new one.

Check for uncommitted changes:

git status --porcelain

If output is empty, check for unpushed commits:

git log @{u}..HEAD

If both are empty, stop: "No changes to submit."

Step 2: Dead Code Detection

The goal is to catch orphaned code before it lands in the PR. This matters because deleted imports, renamed functions, and removed type references often leave behind unreferenced code that reviewers have to flag.

Get the full diff against the base branch so you can see what was added and removed:

git diff BASE_BRANCH...HEAD

Analyze what was removed or renamed. Specifically:

1. Identify deleted imports, function calls, class references, or type usages in the diff
2. For each deleted reference, search the codebase to see if anything still uses it
3. If a function, class, or type has zero remaining references (in both implementation and test files), remove it
4. If an import was the only consumer of an exported member, check whether that export is still used elsewhere

Safety guardrails:

• Only remove code with zero references across the entire codebase
• Preserve exported members that could be part of a public API
• When uncertain, leave the code and note it in the PR description
• Check test files too, as they are valid consumers

Report what was cleaned up (if anything) before proceeding.

Step 3: Commit and Push

Follow Commit and Push.

Step 4: Create PR

Get the commit log for the branch:

git log BASE_BRANCH..HEAD --pretty=format:"- %s%n%b"

Use the commits to write a clear PR title and body. The title should be concise (under 70 chars). The body should summarize what changed and why, plus a test plan.

Create the PR using a HEREDOC for the body to preserve formatting:

gh pr create --base BASE_BRANCH --title "PR title here" --body "$(cat <<'EOF'
## Summary
- bullet points summarizing the changes

## Test plan
- [ ] verification steps

EOF
)"

Output

Report success with the PR URL from the gh pr create output.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.