Skip to content

Commit fcec8bf

Browse files
emdnetoemdneto
committed
tune
Signed-off-by: Emídio Neto <9735060+emdneto@users.noreply.github.com>
1 parent 921e455 commit fcec8bf

1 file changed

Lines changed: 148 additions & 15 deletions

File tree

‎.github/skills/changelog/SKILL.md‎

Lines changed: 148 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,31 +1,164 @@
11
---
22
name: changelog
3-
description: A skill for generating changelog entries for OpenTelemetry Python Contrib packages.
3+
description: Add or update the missing CHANGELOG.md entry for the current OpenTelemetry Python Contrib pull request.
44
---
55

66
# OpenTelemetry Python Contrib — Changelog Skill
77

8-
This skill generates changelog entries for OpenTelemetry Python Contrib packages based on commit messages and pull request descriptions. It follows the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format and categorizes changes into sections: Added, Fixed or Breaking changes. Just Add/Update/Remove the entry from the ./CHANGELOG.md file at the root of the repository.
8+
Use this skill when a pull request in `open-telemetry/opentelemetry-python-contrib` is missing a changelog entry or the user asks to fix git conflicts with `./CHANGELOG.md`.
99

10-
# Important
10+
Your job is to **only edit the root `./CHANGELOG.md` file** and add or update the changelog entry for the current PR.
1111

12-
- Do not run any test or lint
13-
- Do not run any task other than just update the CHANGELOG.md file accordingly to the request
14-
- Do not search for failures in jobs
12+
## Primary goal
1513

16-
## Usage
14+
Given the current pull request diff, title, commit message, and/or PR description:
1715

18-
- You can also include multiple changes in a single entry
19-
- Each change should be listed on a new line with a leading dash
20-
- Include the PR number and link to the PR for reference
21-
- Fix any git conflicts in the changelog file if they arise during merges
16+
- determine whether the PR needs a changelog entry
17+
- determine the correct changelog section
18+
- add a concise entry in the correct format
19+
- avoid touching any file other than `./CHANGELOG.md`
2220

23-
A changelog entry format should look like this:
21+
## Scope rules
22+
23+
- Only modify `./CHANGELOG.md`
24+
- Do not edit any other file
25+
- Do not run tests
26+
- Do not run lint
27+
- Do not search CI jobs
28+
- Do not investigate unrelated failures
29+
- Do not make code changes
30+
- Do not reformat unrelated parts of the changelog
31+
- Do not reorder unrelated entries unless required to resolve a merge conflict
32+
33+
## What to inspect
34+
35+
Use the PR title, description, and code diff to infer:
36+
37+
- which package(s) changed
38+
- whether the change is user-visible
39+
- whether the change belongs in:
40+
- `### Added`
41+
- `### Fixed`
42+
- `### Breaking changes`
43+
44+
If the change is breaking and the repository uses a dedicated breaking-change section, place it there. Otherwise, place it in the most accurate normal section and clearly mention the breaking behavior in the text.
45+
46+
## When to add an entry
47+
48+
Add a changelog entry when the PR introduces a user-visible change, including:
49+
50+
- new instrumentation behavior
51+
- new package support
52+
- bug fixes
53+
- behavior changes
54+
- deprecations
55+
- removals
56+
- compatibility updates that matter to users
57+
- meaningful documentation-visible behavior changes
58+
59+
Do **not** add an entry for purely internal changes unless the repository convention clearly requires it, such as:
60+
61+
- refactors with no user-visible impact
62+
- test-only changes
63+
- CI-only changes
64+
- tooling-only changes
65+
- formatting-only changes
66+
67+
If uncertain, prefer adding an entry only when there is a clear user-facing impact.
68+
69+
## Placement rules
70+
71+
- Add the new entry under the appropriate section in the **current unreleased version** at the top of `CHANGELOG.md`
72+
- Do not create a new release section unless explicitly required
73+
- Do not place the entry under an older released version
74+
- Preserve existing formatting and spacing
75+
- Keep entries grouped with similar package changes when possible
76+
77+
## Entry style rules
78+
79+
- Each entry must start with `- `
80+
- Keep wording concise and user-facing
81+
- Mention the affected package name(s) when relevant, using backticks
82+
- Use present-tense or imperative changelog style consistently with the existing file
83+
- Do not include implementation details unless needed for clarity
84+
- One logical change per bullet
85+
- If a PR affects multiple user-visible packages in the same way, they may be grouped into one entry
86+
87+
## Required format
88+
89+
Format entries exactly like this:
90+
91+
- `- <entry text>`
92+
- ` ([#<PR_NUMBER>](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/<PR_NUMBER>))`
93+
94+
Example:
2495

25-
```
2696
- Add Python 3.14 support
27-
([#<PR_NUMBER>](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/<PR_NUMBER>))
28-
```
97+
([#1234](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/1234))
98+
99+
Package-specific example:
100+
101+
- `opentelemetry-instrumentation-requests`: Fix duplicate span creation on retried requests
102+
([#1234](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/1234))
103+
104+
## Update rules
105+
106+
If an entry for the current PR already exists:
107+
108+
- update it instead of adding a duplicate
109+
- improve clarity if the existing wording is inaccurate or incomplete
110+
- keep the PR link correct
111+
- do not duplicate the same PR number in multiple equivalent entries unless the PR truly needs multiple separate bullets
112+
113+
## Conflict resolution rules
114+
115+
If `CHANGELOG.md` has merge conflict markers:
116+
117+
- resolve conflicts only inside `CHANGELOG.md`
118+
- preserve all valid existing entries
119+
- keep the current PR entry exactly once
120+
- remove conflict markers
121+
- maintain correct section placement and formatting
122+
123+
## Output expectations
124+
125+
After editing:
126+
127+
- the only modified file should be `./CHANGELOG.md`
128+
- the changelog should remain valid markdown
129+
- the new or updated entry should match the repository’s existing style
130+
131+
## Decision heuristic
132+
133+
When generating the text:
134+
1. Identify the user-visible outcome
135+
2. Name the affected package if helpful
136+
3. Describe the change in one concise line
137+
4. Append the PR reference on the next line
138+
139+
Prefer this style:
140+
141+
- `package`: user-visible change
142+
143+
Avoid:
144+
- vague wording
145+
- internal implementation details
146+
- repeating the PR title verbatim if it is too technical or unclear
147+
148+
## Examples
149+
150+
### Added
151+
- `opentelemetry-instrumentation-botocore`: Add support for instrumenting `aiobotocore`
152+
([#4049](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/4049))
29153

154+
### Fixed
155+
- `opentelemetry-instrumentation-flask`: Fix exemplars generation for HTTP server duration metrics
156+
([#3912](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3912))
30157

158+
### Changed
159+
- `opentelemetry-instrumentation-logging`: Move the SDK `LoggingHandler` into the instrumentation package
160+
([#4210](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/4210))
31161

162+
### Removed
163+
- `opentelemetry-instrumentation-xyz`: Remove deprecated legacy hook support
164+
([#1234](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/1234))

0 commit comments

Comments
 (0)
⚡