Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 32 additions & 5 deletions .github/workflows/changeset.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,21 +61,48 @@ Your task is to:

1. **Analyze the Pull Request**: Review the pull request title and description above to understand what has been modified.

2. **Use the repository name as the package identifier** (gh-aw)
2. **Determine if a Changeset is Needed**:

**If the PR does NOT require a changeset** (see criteria below), call the `noop` tool with a reason message and **stop immediately**:

```javascript
noop({
message: "No changeset needed: <reason>"
})
```

**PRs that do NOT require a changeset**:
- Documentation-only changes (README, docs/, comments)
- Test-only changes (test files, fixtures)
- CI/CD configuration changes (.github/workflows/, .github/actions/)
- Development tooling changes (Makefile, scripts/, build configs)
- Changes to repository metadata (.gitignore, LICENSE, etc.)
- Internal refactoring with no user-facing impact

**PRs that DO require a changeset**:
- Bug fixes affecting users
- New features or capabilities
- Breaking changes in APIs or CLI
- Performance improvements
- Dependency updates that affect functionality

If a changeset is needed, proceed with the steps below.

Comment on lines +66 to +90
Copy link

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The instructions say to call noop(...) and "stop immediately" when skipping, but they don’t explicitly say not to append a "Changeset" section to the PR description in that path. To avoid accidental PR-body updates when no changeset was created, consider adding a sentence that the workflow must not call update_pull_request when exiting via noop.

Copilot uses AI. Check for mistakes.
3. **Use the repository name as the package identifier** (gh-aw)

3. **Determine the Change Type**:
4. **Determine the Change Type**:
- **major**: Major breaking changes (X.0.0) - Very unlikely, probably should be **minor**
- **minor**: Breaking changes in the CLI (0.X.0) - indicated by "BREAKING CHANGE" or major API changes
- **patch**: Bug fixes, docs, refactoring, internal changes, tooling, new shared workflows (0.0.X)

**Important**: Internal changes, tooling, and documentation are always "patch" level.
Comment on lines +93 to 98
Copy link

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The skip criteria in step 2 says documentation/test/tooling/internal refactors should not require a changeset, but step 4 still categorizes docs/refactoring/tooling as valid patch change types and states they're always patch level. This is contradictory and may lead the agent to both skip and/or generate a changeset for the same PR type. Consider updating step 4 to explicitly apply only "if a changeset is needed" and removing docs/refactoring/tooling from the patch examples (or adjusting the skip criteria accordingly).

Suggested change
4. **Determine the Change Type**:
- **major**: Major breaking changes (X.0.0) - Very unlikely, probably should be **minor**
- **minor**: Breaking changes in the CLI (0.X.0) - indicated by "BREAKING CHANGE" or major API changes
- **patch**: Bug fixes, docs, refactoring, internal changes, tooling, new shared workflows (0.0.X)
**Important**: Internal changes, tooling, and documentation are always "patch" level.
4. **Determine the Change Type (if a changeset is needed)**:
- **major**: Major breaking changes (X.0.0) - Very unlikely, probably should be **minor**
- **minor**: Breaking changes in the CLI (0.X.0) - indicated by "BREAKING CHANGE" or major API changes
- **patch**: Bug fixes, performance improvements, dependency updates that affect functionality, new shared workflows (0.0.X)
**Important**: When a changeset is required for internal-only, tooling, or documentation-related work (for example, when mixed with user-facing changes), it should always be recorded as "patch" level.

Copilot uses AI. Check for mistakes.

4. **Generate the Changeset File**:
5. **Generate the Changeset File**:
- Create the `.changeset/` directory if it doesn't exist: `mkdir -p .changeset`
- Use format from the changeset format reference above
- Filename: `<type>-<short-description>.md` (e.g., `patch-fix-bug.md`)

5. **Commit and Push Changes**:
6. **Commit and Push Changes**:
- Add and commit the changeset file using git commands:
```bash
git add .changeset/<filename> && git commit -m "Add changeset"
Expand All @@ -90,7 +117,7 @@ Your task is to:
- This tool call is REQUIRED for your changes to be pushed to the pull request
- **WARNING**: If you don't call this tool, your changeset file will NOT be pushed and the job will be skipped

6. **Append Changeset to PR Description**:
7. **Append Changeset to PR Description**:
- After pushing the changeset file, append a summary to the pull request description
- Use the `update_pull_request` tool:
```javascript
Expand Down
Loading