[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69A1Q2QXB2TJHYCVXCSD8YY":3,"skill-same:01M69A1Q2QXB2TJHYCVXCSD8YY":59},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M69A1Q2QXB2TJHYCVXCSD8YY","mcscatblog-review-post",null,"End-to-end review, fix, publish, and verify a blog post PR from another author","microsoft\u002Fmcscatblog","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69A1FRTZD8E1M88JHDP3WSF",21,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmcscatblog-review-post\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30],"mcscatblog review post","review","2026-11-10 10:12:30",false,"---\nname: mcscatblog-review-post\ndescription: End-to-end review, fix, publish, and verify a blog post PR from another author\n---\n\n# Review and Publish a Blog Post PR\n\nYou are reviewing and publishing a blog post PR for the Microsoft Copilot Studio CAT team blog.\n\nThe argument is either a PR number, a branch name, or an author's GitHub username. If not provided, ask.\n\n## Backlog Source of Truth\n\nUse only the SharePoint **CAPE Patterns & Practices Backlog** list for editorial tracking:\n\nhttps:\u002F\u002Fmicrosoft.sharepoint.com\u002Fteams\u002FCAPECopilotAgentsPlatformEcosystem-PatternsandPractices\u002FLists\u002FCAPE%20Patterns%20%20Practices%20Backlog\u002FAllItems.aspx\n\nDo not search or update the former Microsoft Loop backlog, including as a fallback. The Blog Editorial Hub managed app uses this same SharePoint list; it is not a separate backlog.\n\n- Resolve the existing item by its `GitHubPullRequest` URL first, then by title and author if it is not linked yet. Titles can differ between the list and the post. If no item matches, or several match, ask the user rather than creating a duplicate or guessing.\n- Read the list's column definitions and current item before writing. Relevant internal field names are `Title`, `Status`, and `GitHubPullRequest` (a hyperlink with `Url` and `Description`). The destination field is `Goes_x0020_to`; blog items use `The Custom Engine Blog`.\n- Link the original article PR in `GitHubPullRequest` and use `PR submitted` while it awaits publication. Preserve that original link for an already-published article; do not replace it with a date-only or maintenance PR.\n- If using Microsoft Graph, resolve the site and list IDs from the URL. Read `\u002Fsites\u002F{site-id}\u002Flists\u002F{list-id}\u002Fitems` with selected fields and follow pagination. Title filtering can fail on this list because `Title` is not indexed; in that case, inspect paginated results rather than switching to Loop.\n- With WorkIQ, update the supported list-item path `\u002Fsites\u002F{site-id}\u002Flists\u002F{list-id}\u002Fitems\u002F{item-id}` with a `fields` object. For example, a status-only update is `{\"@odata.type\":\"#microsoft.graph.listItem\",\"fields\":{\"@odata.type\":\"#microsoft.graph.fieldValueSet\",\"Status\":\"Published\"}}`. The `\u002Ffields` PATCH path may not be exposed by that tool. Use the latest ETag with `If-Match` when supported; reread and reconcile a conflict rather than overwriting it.\n- Read the item back after updating. If SharePoint access or a write fails, report the tracking step as blocked; do not claim it succeeded or substitute Loop.\n\n## Step 1: Pull the PR Branch\n\n1. Find the PR using `gh pr list` (filter by author if a username was given)\n2. Check out the PR branch: `gh pr checkout \u003Cnumber>`\n3. Identify the new or modified post file in `_posts\u002F`\n4. Resolve its SharePoint backlog item using the rules above and confirm the original article PR is linked.\n\n## Step 2: Start Local Dev Server\n\n1. Run `.\u002Ftools\u002Frun.sh` in the background\n2. Wait for the server to be ready at `http:\u002F\u002F127.0.0.1:4000\u002Fmcscatblog\u002F`\n3. Open the post in the browser so the user can see it\n\n## Step 3: Review the Post\n\nRead the review instructions at `.github\u002Finstructions\u002Fposts.instructions.md`. Review the post against priorities 1-5 defined there.\n\n### Read as a Reader First\n\nBefore checking anything technical, read the post top to bottom as a reader would. Ask yourself:\n- Do I understand the problem being solved by the end of the intro?\n- At any point, did I feel lost, bored, or overwhelmed?\n- Could I follow the instructions and get a working result?\n- Were there sections I wanted to skip?\n\n### Narrative and Structure (highest impact)\n\n- Does the intro state the problem clearly before showing the solution?\n- Progressive disclosure: does the post build from basic to advanced, or dump everything at once?\n- Does every section earn its place? Flag tangential sections for removal.\n- No redundant content (same concept in two tables, glossary restating callouts, etc.)\n- Flag posts over 5,000 words or posts that try to cover too many things shallowly.\n\n### Technical Accuracy\n\n- Flag authoritative-sounding claims that aren't linked to documentation.\n- Verify technical claims if possible (e.g., if the post says \"the API returns fragments,\" test it).\n- All code examples should be complete and working.\n- YAML\u002FJSON blocks over 20 lines should be in collapsible `\u003Cdetails>` sections (use `\u003Cpre>\u003Ccode>` inside, not markdown fences).\n- Links to MS docs for every product feature or configuration step.\n- 2-3 internal links using `post_url` to related blog posts.\n\n### Front Matter and Images\n\n- Filename date matches front matter date\n- Required: title, date, categories (lowercase, max 2), tags (lowercase, 5-8), description, author (matches `_data\u002Fauthors.yml`), image with alt text\n- All referenced images exist in `assets\u002Fposts\u002F` and have alt text + italic caption\n- Screenshots appear after their explanation, not before\n- Tall\u002Fnarrow images (height > 2x width) need resizing to ~300px width\n- No manual \"Further Reading\" section (Chirpy auto-generates from tags)\n- Callouts use Chirpy prompt boxes, not emoji\n- Tags maximize Chirpy \"Further Reading\" overlap with existing posts\n\n### Naming and Terminology (canonical)\n\nCopilot Studio is **one product**. It offers three *harnesses* (build experiences), not three separate products. Flag any framing that treats a harness as its own product. Prose should lead with \"Copilot Studio\" and introduce a harness name only when precision requires it.\n\nFlag and correct non-canonical harness names to these canonical ones:\n\n| Canonical harness | What it is | Reject these terms |\n| --- | --- | --- |\n| **Copilot Chat harness** | Customize Microsoft 365 Copilot with your organization's knowledge. | \"Chat agent\", \"DA\", \"classic\u002Fold Copilot Studio\" |\n| **Standard harness** | Rule-based conversational agents with predefined topics and flows. | \"Basic orchestration\", \"Advanced\", \"Samba\", \"classic\u002Fold Copilot Studio\" |\n| **Microsoft Copilot harness** | Optimize your business processes with an agentic build experience. | \"GitHub Copilot harness\", \"GHCP harness\", \"New Copilot Studio\", \"Dracarys\" |\n\nAdditional checks:\n\n- Harnesses are build choices, not separate products.\n- Use the term \"harness\" consistently; avoid alternates such as \"orchestrator\".\n- Avoid scale labels such as Basic, Advanced, Premium, or Ultimate; they don't scale as new harnesses are added.\n- Context note (keep any cost\u002Flicensing phrasing factual and brief): as of 8\u002F3, Copilot Studio supports building agents with a new Microsoft Copilot harness (GA); agents built with it are billed on a usage basis and are not eligible for inclusion in Microsoft 365 Copilot licensing.\n\n**Front-matter `agent_edition` taxonomy** (established by PR #352, \"Retire classic\u002Fmodern edition naming\"). This field drives the under-title pill rendered in `_layouts\u002Fpost.html` and validated by `_plugins\u002Fvalidate-agent-edition.rb`. Canonical values and what they render:\n\n- `standard` → \"Standard harness\" pill\n- `github-copilot` → \"Microsoft Copilot harness\" pill\n- `both` → \"Both harnesses\" pill\n\nDeprecated aliases `classic` → `standard` and `modern` → `github-copilot` are still accepted but should be migrated. Review check: every post sets a valid `agent_edition`, and posts using `classic`\u002F`modern` should be updated to the canonical value.\n\nThe front-matter value remains `github-copilot`; use Microsoft Copilot harness in prose and display labels.\n\n### Output the Review\n\n- List the **top 5-7 issues** ranked by impact.\n- For each: quote the text, explain the problem, suggest a fix.\n- Do NOT score 14 categories or provide percentage scores.\n- State: **ready to publish**, **needs minor fixes**, or **needs structural revision**.\n\n## Step 4: Apply Fixes\n\nAfter presenting the review, ask the user which fixes to apply. Common fixes include:\n\n- Restructuring sections for progressive disclosure\n- Adding MS docs links and internal post links\n- Cutting tangential sections\n- Making YAML blocks collapsible\n- Grammar, spelling, terminology corrections\n- Correcting Copilot Studio product\u002Fharness terminology to canonical names (see Naming and Terminology)\n- Front matter corrections (dates, tags, categories)\n- Image resizing (use Python PIL)\n- Replacing emoji callouts with Chirpy prompt boxes\n\nApply only the fixes the user approves.\n\n## Step 5: Commit, Push, and Comment\n\n1. For a newly published article, set the front-matter date to the publication date and rename `_posts\u002FYYYY-MM-DD-\u003Cslug>.md` to match. Keep the slug and public URL unchanged, and update any `post_url` references to the old filename. Do not bump publication dates for routine maintenance of an already-published article unless requested.\n2. Verify the updated post renders, then commit all changes with a descriptive message listing what was fixed.\n3. Push to the PR branch.\n4. Add a PR comment summarizing all changes made, organized by category, so the original author can see what was changed and why.\n\n## Step 6: Merge\n\n1. Confirm a new article's filename and front-matter date still match the publication date. If publication was delayed, repeat the date update, verification, commit, and push before final checks.\n2. Confirm any linked sample PRs have merged so the article's sample links resolve.\n3. Merge only when the user has authorized publication and required reviews and checks pass. Never bypass repository protections.\n4. Merge the PR with `gh pr merge --squash --delete-branch`.\n5. Wait ~90 seconds, then find the `Build and Deploy` run for the merge commit with `gh run list --limit 3` and wait for it to succeed.\n6. If the build fails, investigate immediately. Leave the backlog item at `PR submitted` until production is verified.\n\n## Step 7: Verify Production\n\n1. Fetch the production page using WebFetch at `https:\u002F\u002Fmicrosoft.github.io\u002Fmcscatblog\u002Fposts\u002F\u003Cslug>\u002F`\n2. Confirm the page loads with correct title, author, date, images, and code blocks. For a newly published article, also verify its placement and date in the homepage's Latest section or `\u002Flatest\u002F`; a working direct URL alone does not confirm that readers can find it.\n3. Update the matched SharePoint item's `Status` to `Published`, preserving its original article PR link and all unrelated fields.\n4. Read the item back to verify `Status: Published` and the correct `GitHubPullRequest` URL.\n5. Report the live URL and whether the SharePoint update succeeded. Publication and backlog tracking are separate outcomes; report either failure explicitly.\n","# Review and Publish a Blog Post PR\n\nYou are reviewing and publishing a blog post PR for the Microsoft Copilot Studio CAT team blog.\n\nThe argument is either a PR number, a branch name, or an author's GitHub username. If not provided, ask.\n\n## Backlog Source of Truth\n\nUse only the SharePoint **CAPE Patterns & Practices Backlog** list for editorial tracking:\n\nhttps:\u002F\u002Fmicrosoft.sharepoint.com\u002Fteams\u002FCAPECopilotAgentsPlatformEcosystem-PatternsandPractices\u002FLists\u002FCAPE%20Patterns%20%20Practices%20Backlog\u002FAllItems.aspx\n\nDo not search or update the former Microsoft Loop backlog, including as a fallback. The Blog Editorial Hub managed app uses this same SharePoint list; it is not a separate backlog.\n\n- Resolve the existing item by its `GitHubPullRequest` URL first, then by title and author if it is not linked yet. Titles can differ between the list and the post. If no item matches, or several match, ask the user rather than creating a duplicate or guessing.\n- Read the list's column definitions and current item before writing. Relevant internal field names are `Title`, `Status`, and `GitHubPullRequest` (a hyperlink with `Url` and `Description`). The destination field is `Goes_x0020_to`; blog items use `The Custom Engine Blog`.\n- Link the original article PR in `GitHubPullRequest` and use `PR submitted` while it awaits publication. Preserve that original link for an already-published article; do not replace it with a date-only or maintenance PR.\n- If using Microsoft Graph, resolve the site and list IDs from the URL. Read `\u002Fsites\u002F{site-id}\u002Flists\u002F{list-id}\u002Fitems` with selected fields and follow pagination. Title filtering can fail on this list because `Title` is not indexed; in that case, inspect paginated results rather than switching to Loop.\n- With WorkIQ, update the supported list-item path `\u002Fsites\u002F{site-id}\u002Flists\u002F{list-id}\u002Fitems\u002F{item-id}` with a `fields` object. For example, a status-only update is `{\"@odata.type\":\"#microsoft.graph.listItem\",\"fields\":{\"@odata.type\":\"#microsoft.graph.fieldValueSet\",\"Status\":\"Published\"}}`. The `\u002Ffields` PATCH path may not be exposed by that tool. Use the latest ETag with `If-Match` when supported; reread and reconcile a conflict rather than overwriting it.\n- Read the item back after updating. If SharePoint access or a write fails, report the tracking step as blocked; do not claim it succeeded or substitute Loop.\n\n## Step 1: Pull the PR Branch\n\n1. Find the PR using `gh pr list` (filter by author if a username was given)\n2. Check out the PR branch: `gh pr checkout \u003Cnumber>`\n3. Identify the new or modified post file in `_posts\u002F`\n4. Resolve its SharePoint backlog item using the rules above and confirm the original article PR is linked.\n\n## Step 2: Start Local Dev Server\n\n1. Run `.\u002Ftools\u002Frun.sh` in the background\n2. Wait for the server to be ready at `http:\u002F\u002F127.0.0.1:4000\u002Fmcscatblog\u002F`\n3. Open the post in the browser so the user can see it\n\n## Step 3: Review the Post\n\nRead the review instructions at `.github\u002Finstructions\u002Fposts.instructions.md`. Review the post against priorities 1-5 defined there.\n\n### Read as a Reader First\n\nBefore checking anything technical, read the post top to bottom as a reader would. Ask yourself:\n- Do I understand the problem being solved by the end of the intro?\n- At any point, did I feel lost, bored, or overwhelmed?\n- Could I follow the instructions and get a working result?\n- Were there sections I wanted to skip?\n\n### Narrative and Structure (highest impact)\n\n- Does the intro state the problem clearly before showing the solution?\n- Progressive disclosure: does the post build from basic to advanced, or dump everything at once?\n- Does every section earn its place? Flag tangential sections for removal.\n- No redundant content (same concept in two tables, glossary restating callouts, etc.)\n- Flag posts over 5,000 words or posts that try to cover too many things shallowly.\n\n### Technical Accuracy\n\n- Flag authoritative-sounding claims that aren't linked to documentation.\n- Verify technical claims if possible (e.g., if the post says \"the API returns fragments,\" test it).\n- All code examples should be complete and working.\n- YAML\u002FJSON blocks over 20 lines should be in collapsible `\u003Cdetails>` sections (use `\u003Cpre>\u003Ccode>` inside, not markdown fences).\n- Links to MS docs for every product feature or configuration step.\n- 2-3 internal links using `post_url` to related blog posts.\n\n### Front Matter and Images\n\n- Filename date matches front matter date\n- Required: title, date, categories (lowercase, max 2), tags (lowercase, 5-8), description, author (matches `_data\u002Fauthors.yml`), image with alt text\n- All referenced images exist in `assets\u002Fposts\u002F` and have alt text + italic caption\n- Screenshots appear after their explanation, not before\n- Tall\u002Fnarrow images (height > 2x width) need resizing to ~300px width\n- No manual \"Further Reading\" section (Chirpy auto-generates from tags)\n- Callouts use Chirpy prompt boxes, not emoji\n- Tags maximize Chirpy \"Further Reading\" overlap with existing posts\n\n### Naming and Terminology (canonical)\n\nCopilot Studio is **one product**. It offers three *harnesses* (build experiences), not three separate products. Flag any framing that treats a harness as its own product. Prose should lead with \"Copilot Studio\" and introduce a harness name only when precision requires it.\n\nFlag and correct non-canonical harness names to these canonical ones:\n\n| Canonical harness | What it is | Reject these terms |\n| --- | --- | --- |\n| **Copilot Chat harness** | Customize Microsoft 365 Copilot with your organization's knowledge. | \"Chat agent\", \"DA\", \"classic\u002Fold Copilot Studio\" |\n| **Standard harness** | Rule-based conversational agents with predefined topics and flows. | \"Basic orchestration\", \"Advanced\", \"Samba\", \"classic\u002Fold Copilot Studio\" |\n| **Microsoft Copilot harness** | Optimize your business processes with an agentic build experience. | \"GitHub Copilot harness\", \"GHCP harness\", \"New Copilot Studio\", \"Dracarys\" |\n\nAdditional checks:\n\n- Harnesses are build choices, not separate products.\n- Use the term \"harness\" consistently; avoid alternates such as \"orchestrator\".\n- Avoid scale labels such as Basic, Advanced, Premium, or Ultimate; they don't scale as new harnesses are added.\n- Context note (keep any cost\u002Flicensing phrasing factual and brief): as of 8\u002F3, Copilot Studio supports building agents with a new Microsoft Copilot harness (GA); agents built with it are billed on a usage basis and are not eligible for inclusion in Microsoft 365 Copilot licensing.\n\n**Front-matter `agent_edition` taxonomy** (established by PR #352, \"Retire classic\u002Fmodern edition naming\"). This field drives the under-title pill rendered in `_layouts\u002Fpost.html` and validated by `_plugins\u002Fvalidate-agent-edition.rb`. Canonical values and what they render:\n\n- `standard` → \"Standard harness\" pill\n- `github-copilot` → \"Microsoft Copilot harness\" pill\n- `both` → \"Both harnesses\" pill\n\nDeprecated aliases `classic` → `standard` and `modern` → `github-copilot` are still accepted but should be migrated. Review check: every post sets a valid `agent_edition`, and posts using `classic`\u002F`modern` should be updated to the canonical value.\n\nThe front-matter value remains `github-copilot`; use Microsoft Copilot harness in prose and display labels.\n\n### Output the Review\n\n- List the **top 5-7 issues** ranked by impact.\n- For each: quote the text, explain the problem, suggest a fix.\n- Do NOT score 14 categories or provide percentage scores.\n- State: **ready to publish**, **needs minor fixes**, or **needs structural revision**.\n\n## Step 4: Apply Fixes\n\nAfter presenting the review, ask the user which fixes to apply. Common fixes include:\n\n- Restructuring sections for progressive disclosure\n- Adding MS docs links and internal post links\n- Cutting tangential sections\n- Making YAML blocks collapsible\n- Grammar, spelling, terminology corrections\n- Correcting Copilot Studio product\u002Fharness terminology to canonical names (see Naming and Terminology)\n- Front matter corrections (dates, tags, categories)\n- Image resizing (use Python PIL)\n- Replacing emoji callouts with Chirpy prompt boxes\n\nApply only the fixes the user approves.\n\n## Step 5: Commit, Push, and Comment\n\n1. For a newly published article, set the front-matter date to the publication date and rename `_posts\u002FYYYY-MM-DD-\u003Cslug>.md` to match. Keep the slug and public URL unchanged, and update any `post_url` references to the old filename. Do not bump publication dates for routine maintenance of an already-published article unless requested.\n2. Verify the updated post renders, then commit all changes with a descriptive message listing what was fixed.\n3. Push to the PR branch.\n4. Add a PR comment summarizing all changes made, organized by category, so the original author can see what was changed and why.\n\n## Step 6: Merge\n\n1. Confirm a new article's filename and front-matter date still match the publication date. If publication was delayed, repeat the date update, verification, commit, and push before final checks.\n2. Confirm any linked sample PRs have merged so the article's sample links resolve.\n3. Merge only when the user has authorized publication and required reviews and checks pass. Never bypass repository protections.\n4. Merge the PR with `gh pr merge --squash --delete-branch`.\n5. Wait ~90 seconds, then find the `Build and Deploy` run for the merge commit with `gh run list --limit 3` and wait for it to succeed.\n6. If the build fails, investigate immediately. Leave the backlog item at `PR submitted` until production is verified.\n\n## Step 7: Verify Production\n\n1. Fetch the production page using WebFetch at `https:\u002F\u002Fmicrosoft.github.io\u002Fmcscatblog\u002Fposts\u002F\u003Cslug>\u002F`\n2. Confirm the page loads with correct title, author, date, images, and code blocks. For a newly published article, also verify its placement and date in the homepage's Latest section or `\u002Flatest\u002F`; a working direct URL alone does not confirm that readers can find it.\n3. Update the matched SharePoint item's `Status` to `Published`, preserving its original article PR link and all unrelated fields.\n4. Read the item back to verify `Status: Published` and the correct `GitHubPullRequest` URL.\n5. Report the live URL and whether the SharePoint update succeeded. Publication and backlog tracking are separate outcomes; report either failure explicitly.\n",{"name":5,"description":7},"main","f40634049c93a11102af70b2250b70caaeb2780c",".claude\u002Fskills\u002Fmcscatblog-review-post",20,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 01:35:05",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add microsoft\u002Fmcscatblog --skill mcscatblog-review-post",{"tool":51,"command":52},"bunx","bunx skills add microsoft\u002Fmcscatblog --skill mcscatblog-review-post",{"tool":54,"command":55},"pnpm","pnpm dlx skills add microsoft\u002Fmcscatblog --skill mcscatblog-review-post","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmcscatblog-review-post\u002FSKILL.md",true,[],[60,69,83,93],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":31},"01M69A1RQD23FV3GW55ZQ7T9HE","mcscatblog-submit-pr","Commit current changes and create a pull request for review","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmcscatblog-submit-pr\u002FSKILL.md",[],[67,68,30],"mcscatblog submit pr","commit",{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":31},"01M69A1NCSJD9WWQ1YK1FH922J","mcscatblog-react-widget","Build and embed a React widget into a Jekyll blog post as a self-contained HTML file","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmcscatblog-react-widget\u002FSKILL.md",[75,78,79],{"categoryNo":76,"categoryName":77,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[81,82],"mcscatblog react widget","react",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":91,"publishedAt":31},"01M69A1KHT5NJCPQZ0JBRXZRT0","mcscatblog-new-post","Create a new blog post with branch, front matter, and asset folder","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmcscatblog-new-post\u002FSKILL.md",[89,90],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[92],"mcscatblog new post",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":102,"publishedAt":31},"01M69A1J5V1NMYT8A8HEG9PA35","mcscatblog-local-server","Start the local Jekyll dev server and open a post in the browser","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmcscatblog\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmcscatblog-local-server\u002FSKILL.md",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[103],"mcscatblog local server"]