Create done.md
This commit is contained in:
Dominik Seemann
parent
d4f1a9aee0
commit
bb81a48727
|
|
@ -0,0 +1,173 @@
|
||||||
|
---
|
||||||
|
description: Finish a ticket — branch, commit, push, and open a PR closing the issue
|
||||||
|
argument-hint: [--draft] (optional — open the PR as a draft)
|
||||||
|
---
|
||||||
|
|
||||||
|
# /done — Ship the work
|
||||||
|
|
||||||
|
You are running the `/done` slash command. The user typed:
|
||||||
|
|
||||||
|
```
|
||||||
|
/done $ARGUMENTS
|
||||||
|
```
|
||||||
|
|
||||||
|
Goal: take the work that has just been completed for the active ticket and turn
|
||||||
|
it into a pull request — branch, commit, push, open PR, link the issue. This is
|
||||||
|
the final step of the ticket → plan → implement → ship workflow.
|
||||||
|
|
||||||
|
## Repository
|
||||||
|
|
||||||
|
Read the target repo from `.ticket/repo.md` (the `Repo (owner/name)` line). Set
|
||||||
|
`REPO` to that value (e.g. `salestech-group/MiroFish`) and use it explicitly in
|
||||||
|
every `gh` command via `--repo "$REPO"`.
|
||||||
|
|
||||||
|
## Step 0 — Determine the active ticket and spec
|
||||||
|
|
||||||
|
1. **Ticket.** List `.ticket/*.md` excluding `repo.md` and `.gitkeep`.
|
||||||
|
- Exactly one snapshot → use it.
|
||||||
|
- Multiple → pick the one with the newest `workingSince` in its frontmatter
|
||||||
|
(fall back to the file with the most recent mtime).
|
||||||
|
- Zero → ask the user for the issue number, or abort if no human is present.
|
||||||
|
|
||||||
|
Extract `<number>` and `<title>` from the frontmatter.
|
||||||
|
|
||||||
|
2. **Spec.** Look under `.kiro/specs/`. Pick the spec directory whose
|
||||||
|
`spec.json` references this ticket number, or — if none reference it
|
||||||
|
explicitly — the most recently modified spec. Note the directory as
|
||||||
|
`<spec-dir>` for the PR body.
|
||||||
|
|
||||||
|
## Step 1 — Sanity checks (abort early if any fail)
|
||||||
|
|
||||||
|
- `git status` is clean of unrelated noise. If there are changes outside
|
||||||
|
`.kiro/specs/<spec-dir>/` and the directories your implementation touched,
|
||||||
|
warn and ask before continuing.
|
||||||
|
- No `.env`, credentials, or files matching `.gitignore` patterns are staged.
|
||||||
|
- The current branch is **not** `main` or `dev`. If it is, you will create a
|
||||||
|
new branch in the next step.
|
||||||
|
- Working tree has at least one change to commit. If not, abort with a clear
|
||||||
|
message — there is nothing to ship.
|
||||||
|
|
||||||
|
## Step 2 — Determine commit type and branch name
|
||||||
|
|
||||||
|
1. **Type.** Inspect the diff and the ticket title to choose one of:
|
||||||
|
`feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `ci`, `perf`.
|
||||||
|
Default to `feat` for new functionality and `fix` for bug-fix tickets.
|
||||||
|
|
||||||
|
2. **Scope.** Optional. Use a short kebab-case area name if one is obvious from
|
||||||
|
the changed paths (e.g. `auth`, `graph`, `simulation`). Omit the parens
|
||||||
|
entirely if no clear scope.
|
||||||
|
|
||||||
|
3. **Branch name.** Format:
|
||||||
|
|
||||||
|
```
|
||||||
|
<type>/<issue-number>-<short-kebab-summary>
|
||||||
|
```
|
||||||
|
|
||||||
|
Example: `feat/142-add-two-factor-auth`. Keep the summary ≤ 50 chars.
|
||||||
|
|
||||||
|
4. **Branch handling.**
|
||||||
|
- If the current branch already matches `<type>/<issue-number>-*`, reuse it.
|
||||||
|
- Otherwise create and switch:
|
||||||
|
`git checkout -b "$BRANCH"`.
|
||||||
|
- Never reset, force-checkout, or delete an existing branch.
|
||||||
|
|
||||||
|
## Step 3 — Stage and commit
|
||||||
|
|
||||||
|
1. **Stage explicitly.** Add only the files this work intentionally changed
|
||||||
|
plus the spec directory. Do NOT use `git add -A` or `git add .`. Examples:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git add backend/app/services/foo.py
|
||||||
|
git add frontend/src/components/Bar.vue
|
||||||
|
git add .kiro/specs/<spec-dir>/
|
||||||
|
```
|
||||||
|
|
||||||
|
`.ticket/<n>.md` is gitignored — do not stage it.
|
||||||
|
|
||||||
|
2. **Commit message.** Conventional Commits, per
|
||||||
|
`.claude/rules/commits.md`:
|
||||||
|
|
||||||
|
```
|
||||||
|
<type>(<scope>): <imperative summary, lowercase, ≤72 chars, no period>
|
||||||
|
|
||||||
|
<body — what changed and WHY, not how>
|
||||||
|
|
||||||
|
Closes #<issue-number>
|
||||||
|
```
|
||||||
|
|
||||||
|
**Hard rules:**
|
||||||
|
- Lowercase summary. No trailing period. Imperative mood ("add", not
|
||||||
|
"added"/"adds").
|
||||||
|
- **No `Co-Authored-By:` trailer.** The project rule explicitly forbids AI
|
||||||
|
watermarks.
|
||||||
|
- **No `--no-verify`**, `--no-gpg-sign`, or other hook bypasses. If a
|
||||||
|
pre-commit hook fails, fix the underlying issue and create a new commit
|
||||||
|
(do not amend).
|
||||||
|
- Always pass the message via a HEREDOC for clean formatting:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git commit -m "$(cat <<'EOF'
|
||||||
|
<type>(<scope>): <summary>
|
||||||
|
|
||||||
|
<body>
|
||||||
|
|
||||||
|
Closes #<issue-number>
|
||||||
|
EOF
|
||||||
|
)"
|
||||||
|
```
|
||||||
|
|
||||||
|
3. If the work spans multiple unrelated concerns, split into multiple commits
|
||||||
|
on the same branch — one per concern — rather than mixing them.
|
||||||
|
|
||||||
|
## Step 4 — Push
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git push -u origin "$BRANCH"
|
||||||
|
```
|
||||||
|
|
||||||
|
If the push is rejected (remote has commits the local branch doesn't), stop
|
||||||
|
and surface the error. Do **not** force-push.
|
||||||
|
|
||||||
|
## Step 5 — Open the pull request
|
||||||
|
|
||||||
|
```bash
|
||||||
|
gh pr create --repo "$REPO" \
|
||||||
|
--base main --head "$BRANCH" \
|
||||||
|
--title "<same as the commit summary>" \
|
||||||
|
--body "$(cat <<'EOF'
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
- <1-3 bullets describing what changed and why>
|
||||||
|
|
||||||
|
## Spec
|
||||||
|
|
||||||
|
See `.kiro/specs/<spec-dir>/` for requirements, design, and tasks.
|
||||||
|
|
||||||
|
## Test plan
|
||||||
|
|
||||||
|
- [ ] <what to verify locally>
|
||||||
|
- [ ] <edge case to check>
|
||||||
|
|
||||||
|
Closes #<issue-number>
|
||||||
|
EOF
|
||||||
|
)"
|
||||||
|
```
|
||||||
|
|
||||||
|
If `$ARGUMENTS` contains `--draft`, append `--draft` to the `gh pr create`
|
||||||
|
invocation. Use draft mode whenever the implementation is incomplete or
|
||||||
|
`/kiro:validate-impl` flagged outstanding issues that were not resolved.
|
||||||
|
|
||||||
|
## Step 6 — Confirm
|
||||||
|
|
||||||
|
Print one line: the PR URL. Nothing else.
|
||||||
|
|
||||||
|
## Constraints
|
||||||
|
|
||||||
|
- Never push to `main` or `dev` directly.
|
||||||
|
- Never force-push (`--force` / `--force-with-lease`).
|
||||||
|
- Never bypass hooks or signing.
|
||||||
|
- Never stage `.env` files, credentials, or secrets.
|
||||||
|
- Never add `Co-Authored-By:` trailers.
|
||||||
|
- Use `gh` exclusively for GitHub interactions.
|
||||||
|
- Be quiet on success (one-line PR URL). Be loud on failure (state what
|
||||||
|
failed and the next action).
|
||||||
Loading…
Reference in New Issue