Windsurf rules

1---
2name: commit-message
3model: haiku
4description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
5---
6 
7# Commit Message
8> **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
9 
10 
11## Modes
12 
13- Default: standard Conventional Commits message
14- --fix-type: Forces type=fix. Use when commit type is unambiguous.
15 
16## What "last chat" means
17 
18- **Primary source of truth:** `git status`, `git diff` (unstaged), and `git diff --cached` (staged). Run these in the repo root (or the paths the user changed).
19- **Context:** use the current conversation to summarize *intent* and to spot **breaking** API/behavior changes that diff alone may not show.
20- If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff <baseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.
21 
22## Quick workflow
23 
241. **Inventory** — List changed paths; group by feature vs chore vs docs vs test-only.
252. **Decide commit shape** — One atomic commit is ideal. If the diff mixes unrelated concerns, recommend **multiple commits** (each with its own type/scope) before suggesting one message.
263. **Classify for semantic release** — `fix` → patch, `feat` → minor, **breaking** → major.
274. **Write the message** — `type(optional-scope)!: description` (see [REFERENCE.md](REFERENCE.md#message-format)). Use `!` or a `BREAKING CHANGE:` footer when behavior contracts change.
285. **Note defensive-code categories touched** — from CONVENTIONS.md: Rate limit | Retry with backoff | Circuit breaker | Timeout | Graceful degradation
296. **Note fix-ratio contribution** — Each `fix:` commit counts toward `metrics.commit_ratio.fix` in `specs/state.yaml`. After `release-branch`, `session-state` recalculates the ratio automatically. A high fix rate (>30%) triggers a deploy + smoke-test suggestion.
307. **Deliver** — Output:
31   - Proposed **full commit message** (title + optional body + footers).
32   - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.
33   - Optional `git add …` and `git commit -m` instructions; do **not** run destructive git commands unless the user asked.
34 
35## Checklist before finalizing
36 
37- [ ] Type matches the **dominant** user-visible outcome (`feat` vs `fix` vs `perf`, etc.).
38- [ ] **Scope** is a short noun in parentheses if it helps (e.g. `fix(api): …`).
39- [ ] Breaking changes are explicit (`!` and/or `BREAKING CHANGE:` in the body/footer).
40- [ ] Description is imperative, lowercase start after the prefix, no trailing period in the title line.
41- [ ] **NO `Co-authored-by` or `Co-Authored-By` footers** — P1 rule (CONVENTIONS.md § Git Attribution). All commits must appear as if authored solely by the human user. The git hook and `land-branch.sh` both block these.
42 
43## When not to invent a bump
44 
45If the repo uses a custom `@semantic-release/commit-analyzer` preset, note that your bump is **heuristic** and they should match `.releaserc` / `release.config.*`. See [REFERENCE.md](REFERENCE.md#custom-repositories).
46 
47## Further reading
48 
49- [REFERENCE.md](REFERENCE.md) — Message shape, footers, release mapping, squashing notes.
50 
51 
52 
53## Handoff
54 
55Gate: READY -> next: release-branch
56Writes: state.yaml handoff.next_skill = release-branch
57 
58---
59 
60# Conventional Commits + semantic-style release (reference)
61 
62## Message format
63 
64From [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/#specification):
65 
66```text
67<type>[optional scope][optional !]: <description>
68 
69[optional body]
70 
71[optional footer(s)]
72```
73 
74- **Scope:** parenthesized noun, e.g. `feat(parser): …`.
75- **Breaking:** `!` before `:` (e.g. `feat(api)!: …`) and/or footer `BREAKING CHANGE: description` (token must be uppercase per spec for that footer name).
76- **Description:** short summary; body explains *why* or migration steps.
77 
78Common **types** (not exhaustive): `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` — as in [Angular / commitlint conventions](https://github.com/conventional-changelog/commitlint).
79 
80## Advanced Specification Patterns
81 
82### Reverts
83If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body, it should say: `This reverts commit <hash>.`.
84 
85```text
86revert: feat(api): add user endpoint
87 
88This reverts commit 676104e.
89```
90 
91### Breaking Changes
92A breaking change can be signaled by:
931.  A **`BREAKING CHANGE:`** footer (must be uppercase, at the start of the footer). This is the **most compatible** way to trigger a Major release in `semantic-release` (Angular preset).
942.  A **`!`** after the type/scope: `feat(api)!: change user response shape`.
95 
96**Pro-tip:** For maximum compatibility with all tooling (older and newer), use BOTH the `!` and the `BREAKING CHANGE:` footer.
97 
98### Footers (Tokens & Values)
99Footers follow the same `Token: value` pattern as Git Trailers. Common tokens:
100- `Refs: #123`
101- `See-also: docs/ADR-001.md`
102- `Signed-off-by: Name <email>`
103 
104**Multi-line footers:** If a footer value spans multiple lines, each subsequent line must be indented.
105 
106### Squashing & History
107When using `gh pr merge --squash`, the PR title is usually used as the commit subject. 
108- **PR Title:** MUST follow `<type>(<scope>): <description>`
109- **PR Body:** Content will be moved to the commit body.
110 
111## Release Type Mapping (Default Angular Preset)
112 
113This table reflects the **out-of-the-box** behavior of `semantic-release` using the `@semantic-release/commit-analyzer` default (Angular) rules.
114 
115| Commit pattern | Release | Notes |
116|----------------|---------|-------|
117| `fix:` | **Patch** | Bug fixes |
118| `feat:` | **Minor** | New features |
119| `perf:` | **Patch** | Performance improvements |
120| `any type` + `BREAKING CHANGE:` footer | **Major** | **Mandatory** for Major version bumps in default configs. |
121| `any type!:` (exclamation mark) | **Major** | Supported by modern CC parsers, but use footer for max safety. |
122| `docs:`, `chore:`, `test:`, `ci:`, `refactor:`, `style:` | **None** | Does not trigger a new release by default. |
123 
124> **Warning:** While `refactor:` and `style:` improve code, they do NOT trigger a release in the default Angular preset. Use `fix:` if a refactor also fixes a bug, or `feat:` if it adds new behavior.
125 
126## Custom Repositories
127 
128- Read `release.config.js`, `.releaserc`, or `package.json` → `release` / `semantic-release` config.
129- The **@semantic-release/commit-analyzer** preset may map types differently; prefer **their** rules when they conflict with this reference.
130 
131## Squash and PR titles
132 
133- If the team squashes on merge, the **PR title** often becomes the single squashed commit subject — it should still follow `type(scope): description` for tooling.
134- `revert:` type and `Refs:` footers are valid patterns; revert handling varies by [tooling](https://www.conventionalcommits.org/en/v1.0.0/#specification).
135 
136## Links
137 
138- [Conventional Commits — specification](https://www.conventionalcommits.org/en/v1.0.0/#specification)
139- [semantic-release — README (commit format & flow)](https://github.com/semantic-release/semantic-release#commit-message-format)
140- Automation and docs align with [semantic-release](https://github.com/semantic-release/semantic-release) upstream; a fork may be substituted without changing this guidance.
141