docs(changesets): name client app developers in the skill's audience framing#178
Conversation
…framing The writing-changesets skill defines three audiences (End users, Client app developers, Operators), but the frontmatter `description` and the opening line described changesets as only "user-facing or operator-facing", dropping client app developers — the audience the rest of the skill treats as first-class. The omission matters most in the `description`, which is what the skill loader matches against to decide when to trigger. Both now name all three audiences, consistent with the audience list and the per-audience guidance below. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
Warning Review limit reached
More reviews will be available in 32 minutes and 57 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🚅 Deployed to the ePDS-pr-178 environment in ePDS
|
|
There was a problem hiding this comment.
Pull request overview
This PR updates the writing-changesets skill wording so its audience framing consistently includes client app developers alongside end users and operators.
Changes:
- Updates the skill frontmatter description to name all three changeset audiences.
- Updates the opening body sentence to match the same audience framing.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Coverage Report for CI Build 26641553777Coverage remained the same at 56.07%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Summary
The
writing-changesetsskill defines three audiences — End users, Client app developers, Operators — and uses all three consistently in the**Affects:**template, ordering rules, and examples. But two lead-in spots described changesets as only "user-facing or operator-facing", silently dropping client app developers:description(the text the skill loader matches against to decide when to trigger), andBoth now name all three audiences, matching the audience list and per-audience guidance below.
Why it matters
The
descriptionis the highest-stakes spot: it's what selects the skill. Omitting the API/integration audience risks the skill not firing for a change that's purely client-app-developer-facing (e.g. an OAuth flow / response-shape change with no operator or end-user impact).Notes
Two-line wording change, no behavioural content altered. Spotted while porting this skill to the certified-group-service repo, where the same inherited gap was fixed.
🤖 Generated with Claude Code