| name | feature-submission-reminder |
| description | Draft a dev-discuss.pytorch.org forum post that calls for feature submissions for an upcoming PyTorch release, in the style of "Reminder — Calls for Features & Upcoming Branch Cut". Use when the user asks for a release announcement, feature-submission reminder, call-for-features post, or dev-discuss post for a release. Produces a Markdown draft that merges the official key-dates timeline with the AI-identified feature list, and asks owning teams to file "Release highlight for Proposed Feature" issues. |
| disable-model-invocation | true |
Feature Submission Reminder Skill
Draft a dev-discuss.pytorch.org forum post in the
"Reminder — Calls for Features" style for an upcoming (or in-flight)
PyTorch release. The post combines:
- A call to feature owners to file release-highlight issues.
- The AI-identified feature list (via
release-blog-features skill
output, if available).
- The official release timeline (M1-M6) from the dev-discuss
key-dates post.
Reference exemplar:
https://dev-discuss.pytorch.org/t/reminder-calls-for-features-upcoming-branch-cut/3225
Usage
/feature-submission-reminder <version>
Defaults:
<version>: the upcoming release (e.g. 2.12). Required.
Optional inputs the user may provide:
- Key-dates URL — a link to the release's
pytorch-release-<v>-key-dates
post on dev-discuss. If omitted, ask the user for it before drafting.
- Feature list — either a path to a Markdown file, the raw list in
the conversation, or
auto to call the release-blog-features
skill against release/<prev> → release/<version>.
Workflow
Step 1 — Gather timeline
If the user provided a key-dates URL, fetch it with WebFetch and
extract the milestone rows verbatim — do not paraphrase dates.
The milestones typically follow this schema (from the 2.12 key-dates
post); confirm against the source before committing:
- M1 — Release announcement
- M2 — All PRs landed / Feature submission closed
- M3.1 — Release branch cut
- M4 — Release branch finalized, final RC, feature classifications
- M4.1 — Tutorial drafts submission deadline
- M5 — External-facing content finalized
- M6 — Release Day
Mark any milestone whose date is in the past as **Done** alongside
the date. Do not invent M3.2/M3.3 rows if they aren't in the source.
Step 2 — Gather feature list
Priority order:
- If the user supplied a feature list inline or at a file path, use
that directly.
- If there is a recent
<version>/blog-draft.md in this repo (from
release-blog-features), reuse its major features section.
- Otherwise, invoke the
release-blog-features skill against
release/<prev> → release/<version> and use its output.
Apply the "major features only" filter (≥4 PRs each) unless the user
asks for the long list.
Step 3 — Draft the post
Use announcement-template.md as the
starting point. Substitute:
{{VERSION}} — release version (e.g., 2.12){{FEATURES_MARKDOWN}} — the grouped feature list{{TIMELINE_TABLE}} — the M1-M6 table with dates from Step 1{{KEY_DATES_URL}} — link back to the source key-dates post
Always include:
- The AI-identified label on the feature section (e.g.,
"Features Identified by AI") and a note that the list is not
authoritative.
- A blockquoted ask: "If your team is responsible for one of the
features below, please submit a Release highlight for Proposed
Feature issue."
- An explicit call for missing features (especially in areas where
AI scans typically under-sample — MPS, Quantization, CPU/Arm).
Step 4 — Save and (optionally) publish
Save the draft to <version>/feature-submission-reminder.md in this
repo.
If the user asks for a Google Doc version, use the google-docs
skill:
gdocs create "PyTorch <version> Release — Call for Features" \
--from <version>/feature-submission-reminder.md
Do not post to dev-discuss directly — the release manager will
review the draft and post it.
Required elements
Every draft must contain:
- Title line in the format
Reminder — Calls for Features & Upcoming Branch Cut: PyTorch <version>.
- How to submit section listing the two canonical mechanisms
(new issue via template, or tag an existing RFC with
release-feature-request).
- Checklist of what to include in each feature submission:
availability in the release, API stability tag, tutorial links,
blog blurb, platform caveats.
- Feature list with clear "AI-identified, not authoritative"
framing.
- Timeline table with exact dates from the key-dates post.
- Closing sign-off:
Cheers, / Team PyTorch.
Things to avoid
- Don't invent milestones or dates. If the key-dates post doesn't
list M3.2/M3.3, don't add them. If a date is missing, mark it
TODO(release-manager).
- Don't claim authority. Every feature description should be
framed as an AI-generated starting point, not a team-confirmed
description.
- Don't include PR numbers in the feature list. The reminder post
is a call-to-action for teams, not a release-notes dump. Keep it
readable.
- Don't publish. This skill drafts posts; it never posts them.
