From d4ff742e42832e889a4a3b10f6e8820f0a738010 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Wed, 6 May 2026 06:38:24 -0500 Subject: fix(commands): drop leftover name: frontmatter from converted commands The conversion commit ran sed -i to strip the name: line, but the staged version from git mv was captured before the sed ran. Result: the commit shipped the original frontmatter, and the sed cleanup was sitting in the working tree. This commit lands the cleanup that should have been in aa69245. --- .claude/commands/start-work.md | 1 - 1 file changed, 1 deletion(-) (limited to '.claude/commands/start-work.md') diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md index 311476d..d3d9349 100644 --- a/.claude/commands/start-work.md +++ b/.claude/commands/start-work.md @@ -1,5 +1,4 @@ --- -name: start-work description: Pick up a task (Linear ticket, GitHub issue, todo.org task, or a described scope) and take it through Claim, Justify, Approach, Implement, Verify, and Hand-off. Three user-approval gates separate the phases. The Justify gate covers benefits, costs, engineer/user impact, urgency, effort, alternatives, and a ticket-quality check. The Approach gate covers root cause, risk, refactor prerequisites, test strategy (unit, integration, e2e, pairwise, characterization), migration and backwards-compat, feature-flag question, commit decomposition, and branch name. Implementation uses TDD (red, green, edge cases, refactor audit of every touched file). The audit walks the whole of each touched file against a language-agnostic checklist; every finding is either fixed on this branch or filed as a ticket — nothing is silently dropped. A verify phase exercises the feature end-to-end in the local environment (Playwright against localhost for web projects, scripted manual test otherwise) before the final gate confirms readiness and hands off to the Review-and-Publish flow in commits.md. Use when starting work on a specific task where both "should we" and "how exactly" are worth deliberating. Do NOT use for open-ended bug investigation without a clear target (use debug first), for architectural paradigm exploration (use arch-design), for architectural decision recording (use arch-decide), when the task is trivial and obvious (just do it), or when requirements are still being shaped (use brainstorm). --- -- cgit v1.2.3