Improve api-proposal skill using skill-creator analysis#125494
Open
eiriktsarpalis wants to merge 1 commit intomainfrom
Open
Improve api-proposal skill using skill-creator analysis#125494eiriktsarpalis wants to merge 1 commit intomainfrom
eiriktsarpalis wants to merge 1 commit intomainfrom
Conversation
Apply improvements to the api-proposal skill informed by the Anthropic skill-creator skill's methodology for critiquing and optimizing skills. Changes: - Optimize description with trigger phrases (api-suggestion, api-needs-work) and a DO NOT USE FOR boundary to reduce false triggers against sibling skills - Remove generic slop warning (gh pr review --approve) that was not specific to this skill's purpose; reframe prototype-first warning with reasoning - Add Common Pitfalls section warning about LLM-specific failure modes: verbosity creep, invented scenarios, raw ref dumps, non-compilable examples - Restructure proposal template from 10 sections to 5, matching the format used in real api-approved issues (Background, API Proposal, API Usage, Alternative Designs, Risks); fold related issues and scope into Background, design decisions and open questions into Alternative Designs, prototype link into API Proposal section Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the .github/skills/api-proposal skill documentation to better match how api-suggestion/api-approved proposals are typically structured and reviewed in dotnet/runtime, emphasizing prototype-backed design and adding LLM-specific drafting guidance.
Changes:
- Expands the skill trigger description and clarifies intended/non-intended use cases.
- Adds a “Common Pitfalls” section focused on common LLM proposal failure modes.
- Restructures the proposal template sections to align more closely with the current API issue template (Background, API Proposal, Usage, Alternative Designs, Risks) and adds guidance for linking related issues and prototypes.
You can also share your feedback on Copilot code review. Take the survey.
| --- | ||
| name: api-proposal | ||
| description: Create prototype backed API proposals for dotnet/runtime. Use when asked to draft an API proposal or to refine a vague API idea into a complete proposal. | ||
| description: Create prototype-backed API proposals for dotnet/runtime. Use when asked to draft an API proposal, write an api-suggestion issue, refine a vague API idea into a complete proposal, or improve a proposal marked api-needs-work. Covers the full pipeline from research through prototyping, ref source generation, and publishing. DO NOT USE FOR bug fixes, code review, performance benchmarking, or internal API changes that don't affect public surface area. |
There was a problem hiding this comment.
The YAML front-matter description: is a single very long line, which is hard to read/review and tends to create noisy diffs on small edits. Consider switching to a folded block scalar (description: >) with wrapped lines (similar to other skills) so future edits remain maintainable.
Suggested change
| description: Create prototype-backed API proposals for dotnet/runtime. Use when asked to draft an API proposal, write an api-suggestion issue, refine a vague API idea into a complete proposal, or improve a proposal marked api-needs-work. Covers the full pipeline from research through prototyping, ref source generation, and publishing. DO NOT USE FOR bug fixes, code review, performance benchmarking, or internal API changes that don't affect public surface area. | |
| description: > | |
| Create prototype-backed API proposals for dotnet/runtime. Use when asked to | |
| draft an API proposal, write an api-suggestion issue, refine a vague API | |
| idea into a complete proposal, or improve a proposal marked api-needs-work. | |
| Covers the full pipeline from research through prototyping, ref source | |
| generation, and publishing. DO NOT USE FOR bug fixes, code review, | |
| performance benchmarking, or internal API changes that don't affect public | |
| surface area. |
| - **No extensive XML docs.** Comments only as brief clarifications for the review board. | ||
| - Naming must follow the [Framework Design Guidelines](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/framework-design-guidelines-digest.md). | ||
|
|
||
| Include the prototype link at the bottom of this section: "Prototype: `https://github.com/<owner>/<repo>/commit/<sha>`" |
There was a problem hiding this comment.
The prototype URL is shown as inline code (backticks), which prevents GitHub from auto-linking it. Prefer a plain URL or a normal Markdown link so reviewers can click through easily.
Suggested change
| Include the prototype link at the bottom of this section: "Prototype: `https://github.com/<owner>/<repo>/commit/<sha>`" | |
| Include the prototype link at the bottom of this section: "Prototype: https://github.com/<owner>/<repo>/commit/<sha>" |
| **10. Prototype** | ||
|
|
||
| Link to the prototype commit (e.g., `https://github.com/<owner>/<repo>/commit/<sha>`). | ||
| Write "No response" if there are genuinely no risks, matching the convention used in real `api-approved` issues. Do not inflate this section for straightforward additions. |
There was a problem hiding this comment.
This guidance conflicts with earlier instructions to "Skip inapplicable fields" and is also context-dependent: GitHub issue forms auto-fill optional fields with "No response", but gh issue create --body-file (used later in this doc) won’t. Suggest clarifying that authors should either omit the Risks section entirely in markdown proposals, or (when using the issue form) leave it empty and let GitHub generate "No response" automatically—rather than instructing to write it manually.
Suggested change
| Write "No response" if there are genuinely no risks, matching the convention used in real `api-approved` issues. Do not inflate this section for straightforward additions. | |
| If there are genuinely no risks: for markdown proposals (including those used with `gh issue create --body-file`), omit this section entirely; when using the GitHub issue form, leave the Risks field empty and let GitHub render "No response" automatically. Do not inflate this section for straightforward additions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Apply skill-creator methodology to improve the api-proposal skill: optimize description triggers, remove generic warnings, add LLM anti-patterns section, and restructure proposal template to match real api-approved issue format.