shift: Skill for Claude Code

/issue — How Shift issues are written

An issue records an unmet product or engineering outcome. It explains the problem and the truth that must become observable without prescribing an unnecessary implementation.

Search before creation

Always search open and recently closed issues before creating one. Use several concise searches based on the user-visible behavior, domain terms, and likely title wording.

• Reuse a matching open issue rather than creating a duplicate.
• Reference a related issue when the scope overlaps but is not identical.
• Inspect a matching closed issue before deciding whether the new report is a recurrence, a regression, or distinct work.
• Never reopen or modify a closed issue without explicit user approval.

If an existing issue is adequate, return or update that issue instead of creating another.

Title

Use a concise outcome-oriented title that stands alone in issue lists. The title should:

• describe the missing or incorrect behavior;
• use direct, specific wording;
• stay at or below 72 characters when practical;
• omit trailing punctuation, emoji, agent labels, and implementation trivia.

Issues do not require a Conventional Commit prefix. Use fix:, feat:, or another type only when it is already part of an established issue series.

Body

Use the smallest body that makes the work testable:

## Problem

What is missing, broken, unsafe, or difficult, and why it matters.

## Expected outcome

What should be observably true when the issue is complete.

## Acceptance criteria

- [ ] concrete, verifiable result
- [ ] important safety or compatibility boundary

Add reproduction steps, evidence, constraints, or out-of-scope notes only when they materially clarify the issue. Do not copy an implementation plan into the issue unless the implementation boundary itself is a requirement.

Acceptance criteria must describe behavior or durable repository outcomes. Do not use vague criteria such as “works correctly,” “tests pass,” or “code is clean.”