diff --git a/.github/skills/app-service-community-standup-blog/SKILL.md b/.github/skills/app-service-community-standup-blog/SKILL.md new file mode 100644 index 0000000000..9fa39fad08 --- /dev/null +++ b/.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`. diff --git a/.github/skills/app-service-community-standup-blog/references/article-contract.md b/.github/skills/app-service-community-standup-blog/references/article-contract.md new file mode 100644 index 0000000000..9a03006943 --- /dev/null +++ b/.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-.md +``` + +Default `YYYY-MM-DD` to the current date unless the user specifies a publication date. + +Start with: + +```yaml +--- +title: "" +author_name: "" +tags: + - + - + - +--- +``` + +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 ](https://img.youtube.com/vi//maxresdefault.jpg)](https://www.youtube.com/watch?v=) + +[Watch on YouTube](https://www.youtube.com/watch?v=) +``` + +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-.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. diff --git a/.github/skills/app-service-community-standup-blog/references/recording-research.md b/.github/skills/app-service-community-standup-blog/references/recording-research.md new file mode 100644 index 0000000000..8f20529e11 --- /dev/null +++ b/.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= +https://img.youtube.com/vi//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?