MVP Activity Evidence
Use this to turn recent public technical work into source-backed Microsoft MVP activity entries. The workflow is evidence-first: collect signals, confirm dates and URLs in the source systems, then write concise activity records.
Inputs
Ask for or infer:
- Reporting window.
- Target activity format or destination, if any.
- Source roots: GitHub repos, blog repo/site, Vercel projects, session decks, newsletters, or community posts.
- Technology areas to classify against.
If the user names a source system, use that system directly when tools are available. Chronicle-style history is useful for discovery only; confirm important dates, URLs, traffic, and repository details in GitHub, Vercel, the blog repo, or the live site.
Workflow
Define the reporting window.
- Default to the period the user requested.
- If no period is supplied, use the last 30 days and say so.
Inventory candidate activities.
- GitHub: merged PRs, meaningful commits, releases, issues answered, docs added, samples shipped.
- Blog/site: posts published, updated, or materially improved.
- Vercel/analytics: traffic or usage signals that support reach, not vanity detail.
- Presentations/community: talks, demos, workshops, repo examples, downloadable artifacts.
Filter aggressively.
- Keep items with a public or auditable URL, a clear audience, and a Microsoft-relevant technology area.
- Merge small related commits into one activity.
- Skip private-only work unless the user explicitly wants an internal/private entry.
Confirm important facts at the source.
- Date published or merged.
- Canonical URL.
- Repository or site name.
- Measurable outcome, if available.
- Technology area.
Draft entries.
- Use concrete verbs: published, released, updated, answered, demonstrated, documented.
- Prefer one compact paragraph per entry.
- Include links and evidence notes separately if the target form has no URL field.
Reconcile duplicates.
- Combine blog + code + deployment work only when they describe one coherent public contribution.
- Keep separate entries when the audience or output is different.
Output
Return a compact table unless the user requests a specific import format:
| Date |
Activity |
Technology area |
Evidence |
Notes |
Then add:
Skipped: candidates rejected and why.Needs confirmation: entries blocked by missing source access or ambiguous dates.
Quality Bar
An entry is ready only when it has:
- A date or date range.
- A source URL or named auditable source.
- A specific contribution, not generic work history.
- A Microsoft ecosystem tie-in.
- A clear audience or impact signal.
Do not invent impact metrics. If analytics are unavailable, describe the output and audience, then mark reach as unconfirmed.
1---2name: mvp-activity-evidence3description: Build Microsoft MVP activity evidence from recent technical work. Use this skill when the user asks to update MVP activities, review GitHub/Vercel/blog impact for MVP submissions, turn recent posts or commits into MVP entries, or prepare contribution summaries for Microsoft MVP reporting.4---56# MVP Activity Evidence78Use this to turn recent public technical work into source-backed Microsoft MVP activity entries. The workflow is evidence-first: collect signals, confirm dates and URLs in the source systems, then write concise activity records.910## Inputs1112Ask for or infer:13- Reporting window.14- Target activity format or destination, if any.15- Source roots: GitHub repos, blog repo/site, Vercel projects, session decks, newsletters, or community posts.16- Technology areas to classify against.1718If the user names a source system, use that system directly when tools are available. Chronicle-style history is useful for discovery only; confirm important dates, URLs, traffic, and repository details in GitHub, Vercel, the blog repo, or the live site.1920## Workflow21221. Define the reporting window.23 - Default to the period the user requested.24 - If no period is supplied, use the last 30 days and say so.25262. Inventory candidate activities.27 - GitHub: merged PRs, meaningful commits, releases, issues answered, docs added, samples shipped.28 - Blog/site: posts published, updated, or materially improved.29 - Vercel/analytics: traffic or usage signals that support reach, not vanity detail.30 - Presentations/community: talks, demos, workshops, repo examples, downloadable artifacts.31323. Filter aggressively.33 - Keep items with a public or auditable URL, a clear audience, and a Microsoft-relevant technology area.34 - Merge small related commits into one activity.35 - Skip private-only work unless the user explicitly wants an internal/private entry.36374. Confirm important facts at the source.38 - Date published or merged.39 - Canonical URL.40 - Repository or site name.41 - Measurable outcome, if available.42 - Technology area.43445. Draft entries.45 - Use concrete verbs: published, released, updated, answered, demonstrated, documented.46 - Prefer one compact paragraph per entry.47 - Include links and evidence notes separately if the target form has no URL field.48496. Reconcile duplicates.50 - Combine blog + code + deployment work only when they describe one coherent public contribution.51 - Keep separate entries when the audience or output is different.5253## Output5455Return a compact table unless the user requests a specific import format:5657| Date | Activity | Technology area | Evidence | Notes |58| --- | --- | --- | --- | --- |5960Then add:61- `Skipped`: candidates rejected and why.62- `Needs confirmation`: entries blocked by missing source access or ambiguous dates.6364## Quality Bar6566An entry is ready only when it has:67- A date or date range.68- A source URL or named auditable source.69- A specific contribution, not generic work history.70- A Microsoft ecosystem tie-in.71- A clear audience or impact signal.7273Do not invent impact metrics. If analytics are unavailable, describe the output and audience, then mark reach as unconfirmed.
jorgeasaurus