Add App Service Community Standup blog skill

.github/skills/app-service-community-standup-blog/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: app-service-community-standup-blog
+description: Generate and stage an Azure App Service Team Blog recap from a YouTube Community Standup recording. Use when given an Azure App Service standup YouTube URL and asked to research the session, verify announcements and demos, draft a recap, or prepare a review-ready post.
+---
+
+# App Service Community Standup Blog
+
+Turn an Azure App Service Community Standup YouTube recording into a factual, customer-focused recap for the App Service Team Blog. Extract the actual session content, verify product claims against first-party public sources, follow the repository's recap pattern, and stage the post for review.
+
+Read these references before starting:
+
+- [Recording research](references/recording-research.md)
+- [Article contract](references/article-contract.md)
+
+## Required input and defaults
+
+- Require one YouTube video URL.
+- Use the current date for the post filename unless the user specifies a publication date.
+- Derive the article title from the video's official title, removing redundant channel or series wording only when needed for readability.
+- Derive `author_name` from the presenters featured in the recording or video description. Preserve the names and ordering used by the official source.
+- Work only in the current App Service Blog repository.
+- Preserve unrelated staged and unstaged changes.
+
+## Non-negotiable publication rules
+
+1. **Base the recap on the recording.**
+   - Do not infer the session from the video title alone.
+   - Use captions or a transcript to identify the agenda, demonstrations, limitations, measurements, and closing guidance.
+   - If captions are unavailable, create a local transcript from the public recording when the required local tools are available.
+   - If the recording cannot be transcribed or inspected, stop and report the evidence gap instead of fabricating a recap.
+
+2. **Verify product claims independently.**
+   - Treat the recording as the authority for what the presenters said and demonstrated.
+   - Treat current first-party documentation and announcement posts as the authority for availability, preview or GA status, supported operating systems, regions, SKUs, commands, properties, and limitations.
+   - Narrow or qualify claims when the recording and current documentation differ.
+   - Use “at the time of the recording” for roadmap or rollout statements that are no longer current.
+
+3. **Keep the article App Service-focused.**
+   - Include only App Service announcements, demos, and closely related tooling mentioned in the session.
+   - Do not turn brief references to unrelated Azure services into standalone sections.
+   - Explain integrations such as Azure SQL, Key Vault, Azure Bastion, Azure Monitor, or GitHub Copilot only as they support the App Service story.
+
+4. **Use first-party links.**
+   - Prefer Microsoft Learn, the Apps on Azure Blog, the App Service Team Blog, official Microsoft GitHub repositories, and the recording itself.
+   - Do not use private planning links, internal documents, or unofficial summaries in the public post.
+   - Verify every resource URL before staging.
+
+5. **Separate shipped behavior from future work.**
+   - State preview status and material scope explicitly.
+   - Describe future portal, CLI, operating-system, region, or GA plans as planned, not available.
+   - Do not publish dates or roadmap commitments unless a public source states them.
+
+6. **Use canonical terminology.**
+   - Always write `SCM (Kudu)` in prose.
+   - Preserve literal command names, headers, API properties, and quoted output exactly.
+
+## Workflow
+
+1. Inspect the current repository conventions and at least one recent session recap.
+2. Extract the YouTube video ID, title, channel, description, thumbnail, publication metadata, duration, and named presenters.
+3. Obtain captions or create a local transcript. Store temporary media, transcripts, screenshots, and models in the session artifacts directory, never in the repository.
+4. Build a compact private evidence ledger of the session's topics, demonstrations, measurements, and caveats.
+5. Find first-party public sources for every material announcement and verify its current status.
+6. Select the customer-relevant narrative. Prefer two or three major outcomes over a chronological transcript.
+7. Draft the post using the article contract.
+8. Open the repository Markdown for review when an editor surface is available.
+9. Re-read the file from disk after review because user edits may have changed it.
+10. Validate the front matter, links, Markdown, claims, and Git diff.
+11. Stage only the generated post. Do not commit, push, create a pull request, or request reviewers unless explicitly asked.
+12. Delete temporary downloaded media and transcription artifacts after the post is validated.
+
+## Research stopping rule
+
+Stop researching when all of these are true:
+
+- The recording's major segments and demonstrations are represented in the evidence ledger.
+- Every published product claim has a first-party public source.
+- Preview, GA, operating-system, region, SKU, and rollout boundaries are recorded.
+- Demonstration-specific commands, headers, properties, and measurements are verified from the recording or public documentation.
+- Every resource link has been checked.
+- The recap can explain the session's customer value without reproducing the transcript.
+
+## Expected handoff
+
+Provide:
+
+1. The staged post path.
+2. A short list of the included standup topics.
+3. Material preview, rollout, or evidence caveats.
+4. Suggested reviewers based on the presenters or feature owners, without requesting review unless the user asks.
+
+Keep transcripts, screenshots, evidence notes, and research artifacts out of `_posts`.

.github/skills/app-service-community-standup-blog/references/article-contract.md

@@ -0,0 +1,121 @@
+# Article contract
+
+## Filename and front matter
+
+Use:
+
+```text
+_posts/YYYY-MM-DD-<concise-session-slug>.md
+```
+
+Default `YYYY-MM-DD` to the current date unless the user specifies a publication date.
+
+Start with:
+
+```yaml
+---
+title: "<Official or lightly edited session title>"
+author_name: "<Presenter names>"
+tags:
+  - <topic-one>
+  - <topic-two>
+  - <topic-three>
+---
+```
+
+Follow these rules:
+
+- Do not repeat the title as an H1 in the body.
+- Use no more than three tags, matching `CONTRIBUTING.md`.
+- Add `toc` fields only when the post's length and repository precedent justify them.
+
+## Opening
+
+Write one short paragraph that connects the session's major topics into a customer outcome. Link the first mention of the standup title to the YouTube recording.
+
+Follow with a short `The session covered:` list containing the two or three primary topics. Do not list every aside or announcement.
+
+## Watch section
+
+Place the watch section immediately after the opening overview and before the detailed recap:
+
+```markdown
+## Watch the Session
+
+[![Watch <SESSION_TITLE>](https://img.youtube.com/vi/<VIDEO_ID>/maxresdefault.jpg)](https://www.youtube.com/watch?v=<VIDEO_ID>)
+
+[Watch on YouTube](https://www.youtube.com/watch?v=<VIDEO_ID>)
+```
+
+Use the official video title in the image alt text.
+
+## Body
+
+- Organize H2 sections by customer outcome, not presenter or timestamp.
+- Use benefit-first, sentence-style headings.
+- Explain the problem, capability, demonstration, and material limitations.
+- Keep the recap concise; omit introductions, banter, and repeated explanations.
+- Use bullets for capability lists and numbered steps only for an actual sequence.
+- Use short code examples only when the recording demonstrates an actionable command, request header, or configuration.
+- Verify exact syntax from the recording or public documentation.
+- Distinguish a demo-specific measurement from broad product testing.
+- State preview, GA, operating-system, region, SKU, plan, and rollout boundaries.
+- Use `SCM (Kudu)` in prose.
+- Do not add a closing `## Summary`.
+
+An optional synthesis section can connect the topics into a practical path, as long as it adds insight rather than repeating the introduction.
+
+## Time-sensitive wording
+
+Use current public documentation for present-tense availability.
+
+When reporting something shown as upcoming in the recording:
+
+- Say “the team previewed” or “at the time of the recording.”
+- Use “planned” for unshipped work.
+- Do not preserve a promised date that has passed unless it remains relevant historical context.
+- Remove roadmap material that cannot be verified publicly.
+
+## Resources
+
+End with:
+
+```markdown
+## Resources
+```
+
+Include a compact list of first-party links:
+
+1. Announcement posts for the main topics.
+2. Microsoft Learn documentation.
+3. Official repositories or samples demonstrated.
+4. Closely related App Service Team Blog posts.
+
+Do not duplicate the YouTube link unless it materially helps readers.
+
+## Review and staging
+
+Before staging:
+
+1. Re-read the file from disk after editor or canvas review.
+2. Confirm the filename uses the intended publication date.
+3. Confirm the title and YouTube URL match the input video.
+4. Confirm the watch section appears directly after the opening overview.
+5. Confirm `author_name` matches the presenters.
+6. Confirm there are no more than three tags.
+7. Confirm every current-state claim has first-party evidence.
+8. Confirm preview, GA, operating-system, region, SKU, and rollout boundaries are explicit.
+9. Confirm commands, headers, properties, numbers, and measurements are exact.
+10. Confirm no transcript fragments, internal notes, or private links appear in the post.
+11. Check every resource URL.
+12. Run `git diff --check`.
+13. Run the repository's existing Jekyll validation only when its dependencies are already available. Do not install Ruby dependencies from an unapproved source.
+
+Stage only the generated post:
+
+```text
+git add -- _posts/YYYY-MM-DD-<concise-session-slug>.md
+git diff --cached --check
+```
+
+Do not overwrite or unstage unrelated user changes. Do not commit, push, create a pull request, or request reviewers unless requested.

.github/skills/app-service-community-standup-blog/references/recording-research.md

@@ -0,0 +1,126 @@
+# Recording research
+
+Use the YouTube URL as the research boundary. The goal is to understand what happened in the session, not to produce a generic article about the title's keywords.
+
+## 1. Inspect repository conventions
+
+Before researching the recording:
+
+1. Read `CONTRIBUTING.md`.
+2. Read the newest relevant Community Standup or recorded-session recap under `_posts`.
+3. Note the front matter, voice, section ordering, watch-card placement, resource style, and maximum tag count.
+4. If the user identifies an example PR, inspect its changed post from local Git history or the merged file on the default branch.
+
+Do not overwrite unrelated work. Use the existing post only as a structural model, not as reusable factual content.
+
+## 2. Resolve video metadata
+
+From the URL, record:
+
+| Field | Purpose |
+|---|---|
+| Video ID | Thumbnail and canonical watch links |
+| Official title | Article title and opening link |
+| Channel | Source attribution |
+| Description | Agenda, presenters, and official framing |
+| Publication metadata | Context only; the post date defaults to the requested publication date |
+| Duration | Transcript completeness |
+| Presenters | `author_name` and reviewer suggestions |
+
+Prefer YouTube oEmbed or player metadata over search-result snippets.
+
+Use the canonical links:
+
+```text
+https://www.youtube.com/watch?v=<VIDEO_ID>
+https://img.youtube.com/vi/<VIDEO_ID>/maxresdefault.jpg
+```
+
+## 3. Obtain the session content
+
+Use this order:
+
+1. Public caption track from YouTube player metadata.
+2. YouTube transcript endpoint when a caption track exists.
+3. Existing local transcription tools against the public audio.
+
+If local transcription is required:
+
+- Keep audio, transcript, screenshots, virtual environments, and model data under the session artifacts directory.
+- Prefer already installed tools such as `yt-dlp`, `ffmpeg`, and a local speech-to-text runtime.
+- If a dependency is missing, use only the package manager's configured corporate-approved source. Do not access a public package registry directly.
+- Do not commit generated media or transcripts.
+- Remove temporary artifacts after validation.
+
+The transcript must cover the full substantive session. Ignore pre-show silence, countdowns, and closing music.
+
+## 4. Build the private evidence ledger
+
+Capture the session in a compact table:
+
+| Time | Topic | Presenter | What was shown or claimed | Verification source | Status or caveat | Include |
+|---|---|---|---|---|---|---|
+
+Record:
+
+- The opening agenda.
+- Major announcements.
+- Customer problem and value proposition.
+- Demonstrated application, command, configuration, or workflow.
+- Exact measurements or comparisons.
+- Preview, GA, operating-system, region, SKU, or plan boundaries.
+- Security and persistence guidance.
+- Future work or rollout statements.
+- Resource links displayed or mentioned.
+
+Transcription errors are common in product names, commands, acronyms, and numbers. Verify those details from on-screen frames or public documentation before using them.
+
+## 5. Verify announcements
+
+For each material topic, search first-party sources in this order:
+
+1. Microsoft Learn documentation.
+2. Apps on Azure Blog announcement.
+3. App Service Team Blog post.
+4. Official Microsoft or Azure GitHub repository.
+5. Official CLI, SDK, REST, ARM, or Bicep reference.
+
+Verify:
+
+- Feature status: preview or GA.
+- Supported platforms and operating systems.
+- Regions and pricing tiers.
+- Required headers, commands, properties, and API versions.
+- Authentication and network behavior.
+- Persistence or restart behavior.
+- Whether a portal or CLI experience is available now or only planned.
+
+When the recording is older than the publication date, use current public documentation for current-state claims. Preserve the recording's historical context with phrases such as “During the session” or “At the time of the recording.”
+
+## 6. Use demonstrations carefully
+
+Demonstrations make the recap concrete, but do not overstate them:
+
+- Identify the starting constraint.
+- Describe the relevant App Service capability.
+- State the observed outcome.
+- Make clear whether the result was a general product guarantee or one demo's measurement.
+- Add “results vary” when the presenters or source material qualify a measurement.
+
+For exact terminal syntax or HTTP headers, inspect the relevant video frame if the transcript omits punctuation.
+
+## 7. Select the narrative
+
+Do not summarize every minute. Group the session into two or three customer outcomes, for example:
+
+- Move constrained Windows applications to managed PaaS.
+- Make existing content easier for agents to consume.
+- Improve operations with a new CLI capability.
+
+The article should answer:
+
+1. What customer problem does this solve?
+2. What did the team demonstrate?
+3. What can readers use now?
+4. What important limitations apply?
+5. Where can readers learn more?