// Draft GitHub issues for opentelemetry.io following the real issue templates under `.github/ISSUE_TEMPLATE/`, the contributing guide, and the repo's live label taxonomy. Use when creating issue drafts from investigation findings or conversation context.
Update the drifted_from_default front matter field for localized content. Accepts an optional comma-separated locale list (e.g. pt,es,fr) to limit which locales are processed, and an optional --create-pr flag to open a PR automatically. Locales are discovered from the content directory structure.
Fetch, review, and attempt to fix non-2XX `static/refcache.json` URLs on the upstream `otelbot/refcache-refresh` PR. Use when that bot branch is red, refcache still lists 4XX/fragment errors after retries, or you want a guided pass over the refcache-refresh fix loop.
Review OpenTelemetry blog posts for front matter compliance, content conventions, GitHub link stability (`gh-url-hash`), spelling, and OTel terminology. Use when reviewing a PR or draft under `content/en/blog/`.
Review pull requests for opentelemetry.io: CI check semantics, CLA and approval-label workflow, refcache handling, locale rules, and content quality. Use when reviewing a PR or debugging a CI failure in open-telemetry/opentelemetry.io.
Skill for resolving static/refcache.json merge or rebase conflicts in the current branch or a specified PR.
| name | draft-issue |
| description | Draft GitHub issues for opentelemetry.io following the real issue templates under `.github/ISSUE_TEMPLATE/`, the contributing guide, and the repo's live label taxonomy. Use when creating issue drafts from investigation findings or conversation context. |
| argument-hint | <description of issue to draft> |
| allowed-tools | Read Grep Bash |
| effort | low |
Drafts ready-to-paste GitHub issues for open-telemetry/opentelemetry.io. The
templates under .github/ISSUE_TEMPLATE/ and the live label set are the sources
of truth ā when this skill drifts from them, trust the source.
$ARGUMENTS is empty, infer context from the conversation. If there is
insufficient context, ask the user what issue to draft.$ARGUMENTS string as the description. There are no
flags.The repo has five issue templates. Auto-detect type from context, or accept an explicit type from the user.
| Template file | Title prefix | Use for |
|---|---|---|
DOCS_UPDATE.yml | [Docs]: | Documentation errors, missing content, outdated info |
ISSUE_REPORT.yml | bug: | Site bugs, broken functionality, CI/workflow issues |
FEATURE_REQUEST.yml | feat: | New site features, tooling improvements |
BLOG_POST.yml | blog: | Blog post proposals (auto-applies blog label) |
PAGE_FEEDBACK.yml | page feedback: | Feedback from the "was this page helpful?" widget |
When drafting, read the chosen template under .github/ISSUE_TEMPLATE/ and
mirror its section labels verbatim so GitHub maps the body back to template form
fields. Required fields are marked in the template.
For writing or reviewing the post itself after a blog: proposal lands, see the
review-blog-post skill.
From content/en/docs/contributing/issues.md:
#1234 for the same repo, or the
full URL for cross-repo references.The repo's labels evolve; do not maintain a copy in this skill. Discover the live set with:
gh label list --repo open-telemetry/opentelemetry.io --limit 200
Path-based auto-labeling (e.g. blog, registry, i18n, lang:*, several
sig:*) is defined in .github/component-label-map.yml and applies on PRs
only. You can still suggest these on issues manually.
Governance for the triage:*, type:*, priority:*, and sig:* families
lives in content/en/docs/contributing/sig-practices.md. Skip type:discussion
ā its own label description says "Do not use, convert discussion issues into
real Discussions."
Produce a fenced block with title, suggested labels, and body. Labels are
comma-separated so they can be passed directly to
gh issue create --label "<comma,separated>".
**Title**: `bug: pr-approval-labels workflow adds ready-to-be-merged despite requested changes`
**Labels**: `CI/infra`, `Github actions`, `p2-medium`
---
### What happened?
The `pr-approval-labels` workflow currently adds the `ready-to-be-merged`
label when a PR receives an approving review, but it does not check whether
other reviewers have requested changes.
### What did you expect would happen?
The workflow should skip adding the `ready-to-be-merged` label if any
reviewer has a pending "changes requested" status on the PR.
### Name + path of the page
.github/workflows/pr-approval-labels.yml
### Additional context
Related to #1234.
.github/ISSUE_TEMPLATE/*.yml ā five real templates; mirror their section
labels verbatim.content/en/docs/contributing/issues.md ā user-facing guidance on filing
great issues.content/en/docs/contributing/sig-practices.md ā label and triage governance..github/component-label-map.yml ā path-based PR auto-labeling.gh label list --repo open-telemetry/opentelemetry.io --limit 200 ā live
label set.