--- description: Craft and run a cleepi-style git commit. Resolves domain (from cwd) and ticket-id (from cwd → branch → ask), assembles the message, strips any Co-authored-by, and runs git commit. argument-hint: " " --- The user wants to commit. Args: **$ARGUMENTS** ## Critical: required tool calls BEFORE any commit The whole point of `/commit` is to assemble `(): [ ]`. You cannot do that without knowing cwd, staged paths, and branch name. **Therefore, before running `git commit`, you MUST run these tool calls—in this order—so resolution has data:** 1. `bash: pwd` 2. `bash: git diff --cached --name-only` 3. `bash: git rev-parse --abbrev-ref HEAD` 4. `bash: git status --porcelain` If you skip any of these you will produce a bare `feat: message` commit, which is a **resolution failure**, not a valid output. A `git commit` call without a preceding resolution trace from these four tool calls is a bug. Load `/skill:git-commit` if you haven't — it has the full convention, type table, anti-patterns, and hard rules. ## Then: required output shape After the four tool calls, your reply MUST contain this block before the `git commit` call: ``` ## Resolution - type: (from args) - domain: (from cwd: ) - ticket-id: (from ) - message: - assembled: (): [ ] ``` No exceptions. No "auto-confirm" mode skips this. No "just commit" shortens it. The user cannot inspect resolution they cannot see; the Resolution block must always appear. A `: ` shape commit (no `()` clause) is a **resolution failure**. If you are about to produce one, STOP and walk resolution again. ## Resolve the parts ### 1. Type First word of `$ARGUMENTS` is the type. Validate against the Angular set (`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`, `build`, `ci`, `revert`). If the first token isn't a valid type, **stop** and ask the user which type to use, quoting the type table. ### 2. Domain Resolve from cwd: - If `cwd` is inside `packages//...`, domain = ``. - Otherwise, **ask** the user: *"Domain? (free-form area name — e.g. `meta`, `docs`, `ci`, `infra`, `release`)."* - If the user passed a `--domain=` style override anywhere in `$ARGUMENTS`, that wins. Don't use sub-areas of a package (`crew-agents`, `sdd-skill`). Use the package short name. ### 3. Ticket-id Resolve in this order (manual override always wins): a. **Explicit token in `$ARGUMENTS`** matching `[A-Z]+-[0-9]+` (excluding any token that's clearly part of the message). If found, use it. b. **Ticket-id pattern in any staged file path.** Run `git diff --cached --name-only` and grep the paths for `(?:^|/)()-[^/]+/` where ticket-pattern is `[A-Z]+-[0-9]+` or `DRAFT-[0-9]+`. Common matches: `docs/AC-NNN-slug/...`, `packages//docs/AC-NNN-slug/...`. If exactly one ticket-id matches across all staged paths, use it. If multiple, list them and ask. c. **Ticket-id pattern visible in the working tree near the change.** If (b) found nothing, check whether the parent repo has a single recently-modified `docs/-slug/` folder (`ls -t docs/ packages/*/docs/ 2>/dev/null | head`) that matches the type of change. Surface this as a *candidate*, not an auto-pick — ask the user to confirm. d. **Git branch name.** Run `git rev-parse --abbrev-ref HEAD`. Grep the result for `[A-Z]+-[0-9]+`. If matched, use the first match. e. **Ask the user**: *"Ticket-id? (e.g. `AC-123`, or empty to skip.)"* Include any candidates surfaced by (c) in the question. If they leave it empty: - For type `feat`/`fix`/`refactor`/`perf`: gently note that a ticket-id is highly recommended for these; ask once more if they want to provide one. If they still skip, proceed without. - For other types: proceed without. ### 4. Message Everything in `$ARGUMENTS` after the type token, minus any extracted ticket-id token. Trim. Apply message style from the skill: - Imperative, present tense (`add`, not `added`/`adds`). - Lowercase first letter (after ticket-id if present). - No trailing period. - Target 50–72 chars total assembled length; hard cap 100. If the message clearly violates these (past tense, capitalized first word, trailing period), rewrite to match. Tell the user in your reply that you normalised it. ## Check staging Run `git status --porcelain`. If there are unstaged changes: - Print the list of unstaged files. - Ask: *"Unstaged changes present. `[stage all / commit staged only / cancel]`?"* - On `stage all`: run `git add -A` then continue. - On `commit staged only`: continue with whatever is currently staged. - On `cancel`: stop. Don't commit. Never auto-`git add -A` without asking. ## Assemble ``` (): [ ] ``` Examples (target shape): ``` feat(crew): AC-201 add reviewer pre-step docs(crew): fix README install path chore(meta): bump prettier ``` ## Strip `Co-authored-by:` (hard rule) Before passing the message to `git commit`, scan it for any line matching `(?i)co-authored-by:`. **Remove the line and everything after it.** This rule overrides everything, including explicit user input that included such a line. Same for `Signed-off-by:`. If you removed anything, mention it in your reply: *"Stripped `Co-authored-by:` per the `git-commit` skill's hard rule."* ## Confirm + commit Show the user: - The final assembled message (one line). - The resolution trace in one compact line: *"resolved: domain=`X` (from cwd), ticket=`Y` (from )"*. This exists so the user can spot a wrong resolution before the commit lands. Don't skip this even when the user said "auto-confirm." - Brief summary of what's about to be committed: file count, a sample of paths from `git diff --cached --name-only`. Ask: *"Commit? `[y / N / edit]`"* - `y`: run `git commit -m ""`. Report the resulting commit hash and short summary. - `edit`: ask the user what to change; re-assemble; re-confirm. - `N` (default): stop. Don't commit. If the user pre-authorised auto-confirmation, treat that as standing consent for the *confirm step only* — still show the resolution trace so wrong resolutions are visible after the fact. ## Discipline check If at any point you almost wrote a multi-line commit, almost included `Co-authored-by:`, or almost used a type outside the Angular set, **stop and reload the skill**. These mistakes are the exact reason this prompt exists. Be concise throughout. No throat-clearing in your reply. The user wants the commit done, not a summary of what you did.