-
Notifications
You must be signed in to change notification settings - Fork 110
chore: improve Claude Code config and docs #2585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,63 +2,41 @@ | |
| description: Create a commit following InstUI conventions with HUSKY=0 | ||
| --- | ||
|
|
||
| Create a commit following the Instructure UI commit conventions: | ||
| Commit staged + relevant unstaged changes using Conventional Commits. | ||
|
|
||
| ## Format Requirements | ||
|
|
||
| Use Conventional Commits format: | ||
| ## Format | ||
|
|
||
| ``` | ||
| type(scope): subject | ||
|
|
||
| [optional body] | ||
| Document any breaking changes here with BREAKING CHANGE: prefix | ||
|
|
||
| [optional footer] | ||
| ``` | ||
|
|
||
| **Types**: feat, fix, docs, style, refactor, test, chore | ||
| type(scope): imperative subject | ||
|
|
||
| **Scope**: Full package name as-is (e.g., ui-button, ui-select). Use comma-separated for multiple packages, `many` for many packages, or omit for repo-wide changes. | ||
| <optional body> | ||
|
|
||
| **Subject**: Brief imperative description (e.g., "add loading state", not "adds" or "added") | ||
| BREAKING CHANGE: <only if applicable> | ||
|
|
||
| ## Breaking Changes | ||
|
|
||
| Mark breaking changes with an exclamation mark after scope and document in body: | ||
|
|
||
| ``` | ||
| feat(ui-select)!: remove deprecated onOpen prop | ||
| 🤖 Generated with [Claude Code](https://claude.com/claude-code) | ||
|
|
||
| BREAKING CHANGE: The onOpen prop has been removed. Use onShowOptions instead. | ||
| Co-Authored-By: Claude <noreply@anthropic.com> | ||
| ``` | ||
|
|
||
| Breaking changes include: | ||
|
|
||
| - Removing/renaming props or components | ||
| - Changing prop types or behavior | ||
| - Changing defaults that affect behavior | ||
| - Removing theme variables or exports | ||
|
|
||
| ## Commit Footer | ||
|
|
||
| Always include: | ||
| - **type**: one of `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`. `commitlint.config.js` extends [`@commitlint/config-conventional`](https://www.npmjs.com/package/@commitlint/config-conventional), which defines the allowed set — pick the type that genuinely matches the change (`feat`/`fix` only for actual features/bug fixes). | ||
| - **scope**: full package name (`ui-button`, `ui-select`). Comma-separate for a few, use `many` for several, omit for repo-wide. | ||
| - **subject**: imperative ("add loading state", not "added"). No trailing period. | ||
| - **Body lines: hard-wrap at 100 characters.** Commitlint (`body-max-line-length: 100`) runs in CI and will reject longer lines. The footer lines (Claude Code attribution, Co-Authored-By) are exempt. | ||
| - **Breaking changes**: add a `BREAKING CHANGE:` line in the body describing what breaks. See CLAUDE.md for what counts as breaking. | ||
|
|
||
| ``` | ||
| 🤖 Generated with [Claude Code](https://claude.com/claude-code) | ||
| ## Steps | ||
|
|
||
| Co-Authored-By: Claude <noreply@anthropic.com> | ||
| ``` | ||
| 1. `git status` + `git diff` (and `git diff --staged` if anything's staged). | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd add that it should not commit if its on the |
||
| 2. Stage the files that belong in this commit — be specific, don't `git add -A`. | ||
| 3. Commit with `HUSKY=0` to skip the interactive husky prompt: | ||
|
|
||
| ## Process | ||
| ```bash | ||
| HUSKY=0 git commit -m "$(cat <<'EOF' | ||
| <message> | ||
| EOF | ||
| )" | ||
| ``` | ||
|
|
||
| 1. Run `git status` and `git diff` to see changes | ||
| 2. Analyze the changes and draft appropriate commit message | ||
| 3. Add files to staging if needed: `git add <files>` | ||
| 4. Create commit with `HUSKY=0 git commit -m "$(cat <<'EOF' | ||
| [commit message here with proper footer] | ||
| EOF | ||
| )"` | ||
| 5. Run `git status` after to verify | ||
| 4. `git status` to confirm. | ||
|
|
||
| **Important**: Use HUSKY=0 prefix to skip interactive prompt since AI can't interact with it. | ||
| If the husky hook fails, fix the underlying issue and create a **new** commit — never `--amend` after a failed hook. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,55 +2,50 @@ | |
| description: Create a pull request following InstUI conventions | ||
| --- | ||
|
|
||
| Create a pull request following Instructure UI conventions: | ||
| Open a PR for the current branch. | ||
|
|
||
| ## PR Requirements | ||
| ## Steps | ||
|
|
||
| All PRs must include: | ||
| 1. `git status` — confirm branch + remote tracking. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would also add here, that it should abort if its on the master branch or its in a branch that has no commits. |
||
| 2. `git log master..HEAD` and `git diff master...HEAD` — review **all** commits in the branch, not just the latest. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why should the AI review commits when pushing? |
||
| 3. If not pushed: `git push -u origin <branch>`. | ||
| 4. Create the PR (see invocation below). | ||
| 5. Return the PR URL. | ||
|
|
||
| 1. **Summary**: Brief description of changes (1-3 bullet points) | ||
| 2. **Test Plan**: Clear steps for reviewers to test the changes | ||
| 3. **Jira Reference**: Include relevant Jira ticket number if applicable (e.g., `Fixes INST-1234`) | ||
| 4. **AI Disclosure**: Must clearly indicate this was created with AI assistance | ||
| If the branch name or any commit references a Jira ticket (e.g. `INSTUI-1234`), include it. If you can't find one, ask the user once before opening — don't invent one. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd also write that the JIRA ticket number should be included in the PR title, e.g. |
||
|
|
||
| ## Draft vs Ready | ||
| ## gh invocation | ||
|
|
||
| - Open as **draft** when work is in progress or not ready for review | ||
| - Mark as **ready for review** only when complete and all requirements met | ||
| Use `--body-file -` with a heredoc on stdin. This avoids shell-quoting issues and is the form supported by current `gh` versions. If unsure about flags, run `gh pr create --help` first — do **not** fall back to older forms like `gh pr create -t ... -b ...` with inline `-b`. | ||
|
|
||
| ## Process | ||
|
|
||
| 1. Run `git status` to check current branch and remote tracking | ||
| 2. Run `git log master..HEAD` to see all commits that will be in the PR | ||
| 3. Run `git diff master...HEAD` to see full diff from base branch | ||
| 4. Analyze changes across ALL commits (not just latest) | ||
| 5. Draft PR summary covering all changes | ||
| 6. **If Jira ticket number is unknown, ask the user for it before creating the PR** | ||
| 7. Push to remote if needed: `git push -u origin <branch>` | ||
| 8. Create PR with `gh pr create --title "title" --body "$(cat <<'EOF' | ||
| ```bash | ||
| gh pr create --title "<title>" --body-file - <<'EOF' | ||
| <body> | ||
| EOF | ||
| ``` | ||
|
|
||
| ## Summary | ||
| Open as draft (`--draft`) if the work is in progress. | ||
|
|
||
| - Bullet point 1 | ||
| - Bullet point 2 | ||
| ## Body format | ||
|
|
||
| ## Test Plan | ||
| Keep it **short**. No preamble, no restating the title, no "this PR does X" filler. | ||
|
|
||
| - [ ] Step 1 | ||
| - [ ] Step 2 | ||
| ``` | ||
| ## Summary | ||
| - <one line per logically distinct change; 1–4 bullets total> | ||
|
|
||
| ## Jira Reference | ||
| ## Test Plan | ||
| - <only manual / non-CI checks a reviewer should do> | ||
|
|
||
| Fixes INST-XXXX (or omit this section if not applicable) | ||
| Fixes INSTUI-XXXX | ||
|
|
||
| 🤖 Generated with [Claude Code](https://claude.com/claude-code) | ||
| EOF | ||
| )"` 9. Return the PR URL | ||
| ``` | ||
|
|
||
| **Important**: | ||
| Rules: | ||
|
|
||
| - Base branch is usually `master` (not main) | ||
| - Analyze ALL commits in the branch, not just the latest one | ||
| - Use markdown checklists for test plan | ||
| - Include AI attribution footer | ||
| - Always confirm Jira ticket number with user if not found in commits or branch name | ||
| - **Summary**: terse bullets. Each bullet is one change, not a paragraph. Skip context the diff already shows. | ||
| - **Test Plan**: only what CI **doesn't** cover — manual UI checks, RTL, a11y spot-checks, visual regression cases to look at, edge cases worth poking. Never include "tests pass", "lint passes", "types check", "build succeeds" — CI runs those. | ||
| - If there's genuinely nothing to manually verify (e.g. pure refactor with full test coverage), write `- No manual verification needed; covered by existing tests.` and move on. | ||
| - Omit the `Fixes` line entirely if no ticket applies. Don't write `Fixes INSTUI-XXXX (or omit if not applicable)`. | ||
| - Keep the Claude Code footer. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| { | ||
| "permissions": { | ||
| "allow": [ | ||
| "Bash(git status:*)", | ||
| "Bash(git diff:*)", | ||
| "Bash(git log:*)", | ||
| "Bash(git show:*)", | ||
| "Bash(git branch:*)", | ||
| "Bash(git blame:*)", | ||
| "Bash(git stash list:*)", | ||
| "Bash(pnpm run lint)", | ||
| "Bash(pnpm run lint:changes)", | ||
| "Bash(pnpm run lint:commits)", | ||
| "Bash(pnpm run ts:check)", | ||
| "Bash(pnpm run test:vitest)", | ||
| "Bash(pnpm run test:vitest *)", | ||
| "Bash(pnpm list:*)", | ||
| "Bash(pnpm why:*)", | ||
| "Bash(ls:*)", | ||
| "Bash(find:*)", | ||
| "Bash(grep:*)", | ||
| "Bash(rg:*)", | ||
| "Bash(tree:*)", | ||
| "Bash(wc:*)", | ||
| "Bash(pwd)", | ||
| "Bash(node --version)", | ||
| "Bash(pnpm --version)", | ||
| "Bash(gh pr view:*)", | ||
| "Bash(gh pr list:*)", | ||
| "Bash(gh pr diff:*)", | ||
| "Bash(gh pr checks:*)", | ||
| "Bash(gh issue view:*)", | ||
| "Bash(gh issue list:*)", | ||
| "Bash(gh api:*)", | ||
| "Bash(gh --help)", | ||
| "Bash(gh * --help)" | ||
| ] | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.