[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699MPHZ6P4KBHG5SNH3Y6VQ":3,"skill-same:01M699MPHZ6P4KBHG5SNH3Y6VQ":90},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M699MPHZ6P4KBHG5SNH3Y6VQ","create-mission-spec",null,"Turn a mission or lab idea into a fully researched GitHub issue spec on microsoft\u002Fagent-academy, then post it with the GitHub CLI. Use this skill whenever the user wants to propose new Agent Academy content before writing it — course missions (Recruit, Operative, Commander), standalone Special Ops, or Cowork Collective missions. Trigger whenever the user says \"write a spec for a mission\", \"create an issue for a new lab\", \"I want to propose a Special Ops\", \"file a mission proposal\", \"spec out a lab\", \"open an issue for a new module\", or hands over Microsoft Learn URLs and asks to turn them into an Agent Academy lab. This skill handles: mining source documentation, interviewing for scope, repo reconnaissance and duplicate detection across both docs and existing issues, frontmatter and tag validation, writing-style conformance, drafting the issue body, title conventions, milestone and assignee metadata, and posting plus verifying the issue via `gh`.","microsoft\u002Fagent-academy","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699MCPQNKZBY9K0MDHG9XC8",3717,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcreate-mission-spec\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,31,32,33,34,9],"spec","create mission spec","writing","cli","docs","github","2026-11-10 10:12:30",false,"---\nname: create-mission-spec\ndescription: >\n  Turn a mission or lab idea into a fully researched GitHub issue spec on microsoft\u002Fagent-academy,\n  then post it with the GitHub CLI. Use this skill whenever the user wants to propose new Agent\n  Academy content before writing it — course missions (Recruit, Operative, Commander), standalone\n  Special Ops, or Cowork Collective missions. Trigger whenever the user says \"write a spec for a\n  mission\", \"create an issue for a new lab\", \"I want to propose a Special Ops\", \"file a mission\n  proposal\", \"spec out a lab\", \"open an issue for a new module\", or hands over Microsoft Learn\n  URLs and asks to turn them into an Agent Academy lab. This skill handles: mining source\n  documentation, interviewing for scope, repo reconnaissance and duplicate detection across both\n  docs and existing issues, frontmatter and tag validation, writing-style conformance, drafting\n  the issue body, title conventions, milestone and assignee metadata, and posting plus verifying\n  the issue via `gh`.\nargument-hint: Optionally provide the topic and any source documentation URLs for the mission.\n---\n\n# Create Mission Spec\n\nThis skill produces a **specification issue** — not mission content. The output is a GitHub issue\non `microsoft\u002Fagent-academy` that another contributor (or a later run of\n`agent-academy-mission-builder`) can implement from without further research.\n\nThe difference matters. A spec issue answers _what should be built and why_. The mission builder\nanswers _how it reads_. Never write the mission markdown in this skill.\n\n## ? Prerequisites\n\n1. Run `gh --version` to confirm the GitHub CLI is installed. If missing, install it\n   (`brew install gh` on macOS).\n1. Run `gh auth status` to confirm authentication. If not authenticated, run `gh auth login` and\n   guide the user through the flow.\n\nDo not proceed until both checks pass.\n\n## Mission types\n\nFour tracks exist, and each has its own folder, contributing guide, and style section. Identify\nthe track before anything else, because it determines the frontmatter contract.\n\n| Track             | Folder                         | Contributing guide                  |\n| ----------------- | ------------------------------ | ----------------------------------- |\n| Recruit           | `docs\u002Frecruit\u002FNN-slug\u002F`        | `CONTRIBUTING-COURSES.md`           |\n| Operative         | `docs\u002Foperative\u002FNN-slug\u002F`      | `CONTRIBUTING-COURSES.md`           |\n| Commander         | `docs\u002Fcommander\u002FNN-slug\u002F`      | `CONTRIBUTING-COURSES.md`           |\n| Special Ops       | `docs\u002Fspecial-ops\u002Fslug\u002F`       | `CONTRIBUTING-SPECIAL-OPS.md`       |\n| Cowork Collective | `docs\u002Fcowork-collective\u002Fslug\u002F` | `CONTRIBUTING-COWORK-COLLECTIVE.md` |\n\n`CONTRIBUTING-GENERAL.md` covers markdown linting and spell checking for every track.\n\n## Phase 1: Mine the source documentation\n\nDo this **first**, before the interview. You cannot offer the user good scoped options until you\nknow what the product actually does, and an interview built on guesses wastes a round trip.\n\nIf the user supplied URLs, fetch **all of them in parallel**. Extract and keep:\n\n- Exact tool, API, or feature names and their required vs. optional parameters\n- Endpoint URLs and placeholder segments (e.g. `{environmentId}`)\n- Licensing, role, and version prerequisites\n- Governance, admin, and observability surfaces\n- Anything gated behind admin rights, preview, or regional availability\n\nThese become the spec's **Prerequisites**, **Lab outline**, and **Risks** sections. A spec that\nparaphrases the docs is useless; a spec that names the exact tools and endpoints saves the\nimplementer an hour.\n\nIf the user supplied no URLs, ask for them before going further. Never write a spec from memory\nabout a product surface that changes as fast as these do.\n\n## Phase 2: Gather intel\n\nFirst, list the available milestones so you can offer real options rather than asking a second\ntime later:\n\n```bash\nGH_PAGER=cat gh api repos\u002Fmicrosoft\u002Fagent-academy\u002Fmilestones \\\n  --jq '.[] | \"\\(.title)  due=\\(.due_on)\"'\n```\n\nThen ask everything in **one batch** using the ask-questions tool. Never interrogate one question\nat a time. Offer concrete options with a recommended default so the user can answer by picking,\nand derive those options from what you found in Phase 1.\n\nAlways ask:\n\n1. **Mission status** — is this a new mission or an update to an existing mission? For an update,\n   ask which mission is changing and treat its current content as the implementation baseline.\n1. **Mission type** — Special Ops, Cowork Collective, or a course mission (Recruit \u002F Operative \u002F\n   Commander)?\n1. **Scenario** — what will the learner actually build? Offer 3-4 scoped options drawn from the\n   documentation rather than asking an open question.\n1. **Surface** — which product or client does the mission drive? (Copilot Studio, VS Code, both.)\n1. **Difficulty and time** — offer 2-3 sensible pairings, e.g. \"Difficulty 3, ~45 min\".\n1. **Badge codename** (Special Ops only) — offer 3-4 punchy options.\n1. **Milestone** — which fiscal quarter does this target? Offer the open milestones you just\n   listed, with the nearest one recommended. This is the due date.\n1. **Deliverable** — draft the body in chat, post the issue directly, or save to a file?\n\nIf the user already stated something in their prompt (for example \"avoid the connectors one, start\nwith Graph APIs\"), do not ask about it again. Treat it as a hard scope boundary and reflect it in\nthe **Out of scope** section.\n\n## Phase 3: Repo reconnaissance\n\nRun these in parallel:\n\n1. **Duplicate check in the docs** — `grep_search` the repo for the feature name. Distinguish a\n   real duplicate (an existing mission on the topic) from a passing mention in another mission.\n   Report either way in the issue, and link passing mentions as cross-link targets.\n1. **Duplicate check in the issues** — someone may have already filed this spec. Run\n   `GH_PAGER=cat gh issue list --repo microsoft\u002Fagent-academy --state all --search \"\u003Ckeyword>\"`.\n   Grepping the docs alone misses proposals that have not been implemented yet.\n1. **Read the contributing guide for the track** — see the Mission types table above. Each guide\n   defines a different frontmatter contract; Special Ops omits `prev`, `next`, and `codename`,\n   which course missions require.\n1. **Validate slugs** — read `docs\u002F.vitepress\u002Fdata\u002Ftags.json`, `products.json`, and\n   `industries.json`. Every `tags`, `products`, and `industries` value in the proposed frontmatter\n   must already exist in those files. If one does not, either pick an existing slug or add an\n   explicit acceptance-criteria item to create it.\n1. **Find the closest existing mission** — use it as the structural reference and name it in the\n   issue so the implementer has a template to copy.\n1. **Read `WRITING_STYLE.md`** — specifically the section matching the mission type. Course\n   missions, Special Ops, and Cowork Collective have different required sections and intros. The\n   spec must reflect the right one; proposing a `codename` for a Special Ops mission or omitting\n   the `⚙️ Prerequisites` section is a spec bug, not an authoring bug.\n\nFor a new mission, if either duplicate check finds a genuine match, **stop and tell the user**\nbefore drafting. Offer to pivot the angle, extend the existing mission, or proceed anyway. Do not\nsilently file a second spec for work that already exists. For an updated mission, confirm that the\nnamed mission exists, inspect its current content, and use related open issues to identify overlap\nrather than treating the mission itself as a duplicate.\n\n## Phase 4: Title convention\n\nFormats:\n\n- New mission: `[New Mission] \u003CSection>: \u003CAction verb> \u003Cwhat they build>`\n- Updated mission: `[Updated Mission] \u003CSection>: \u003CAction verb> \u003Cwhat changes>`\n\nExamples:\n\n- `[New Mission] Special Ops: Build your own MCP server with the MCP Management Server`\n- `[New Mission] Operative Mission 12: Ground an agent in SharePoint knowledge`\n- `[New Mission] Cowork Collective: Turn a badge-scan export into an emailed report`\n- `[Updated Mission] Special Ops: Refresh the Copilot Studio MCP lab`\n\nRules:\n\n- Use `[New Mission]` or `[Updated Mission]` according to the mission status selected in Phase 2.\n  Never use `[New Lab]`; missions are the unit of content in this repo across every track.\n- Keep the whole title **under 80 characters**. GitHub truncates issue titles around 70 in list\n  views.\n- One bracketed prefix only. Do not nest a pipe inside the brackets — `[New Mission | Special Ops]`\n  reads like a UI breadcrumb and costs characters without adding information.\n- New course missions are sequential, so include the proposed number (`Operative Mission 12`).\n  Confirm the next free number from the track's `index.md` before claiming it. Updated course\n  missions retain their existing number. Special Ops and Cowork Collective are standalone and\n  take no number.\n- Avoid repeating a product acronym. \"Microsoft MCP Management Server\" says MCP twice; \"MCP\n  Management Server\" is enough because the body spells it out.\n- Prefer \"Build your own\" over \"Build a custom\" — shorter and states the value.\n- Mirror the final title as the body's H1 so the issue reads consistently.\n\n## Phase 5: Draft the issue body\n\nWrite the body to a temp file **outside the workspace** (`\u002Ftmp\u002F`), never into the repo. Use this\nstructure:\n\n```markdown\n# \u003Ctitle>\n\n## Summary\n\nWhat the mission teaches, and the specific curriculum gap it closes. Name the existing missions\nthat cover adjacent ground so the gap is provable, not asserted. State the scope boundary here.\n\n## Proposed mission\n\nA table: Section, Folder, Title, Operation codename, Badge, Difficulty, Time.\n\n### Proposed frontmatter\n\nA fenced yaml block matching the contributing guide exactly for that mission type.\nFollow it with a line confirming whether the tag\u002Fproduct\u002Findustry slugs already exist.\n\n## Scenario\n\nA fictional company, an industry, and a concrete problem. Include the analogy the mission\nshould use in its concept brief.\n\n## Mission objectives\n\nBulleted, one concrete capability each, phrased as what the learner will do.\n\n## Prerequisites (to state in the mission)\n\nLicenses, roles, tool versions, tenant availability, and links. Bold any hard blocker.\n\n## Proposed lab outline\n\nA Recon section explaining the concept, then numbered labs. For each lab, one bold heading and\ntwo or three sentences naming the exact tools, parameters, and UI paths involved. End with a\ncleanup lab where the mission creates real resources.\n\n## Acceptance criteria\n\nA checkbox list covering: files created, assets and screenshots, required components\n(`\u003Cmission-meta \u002F>`, `\u003Canalytics-tag \u002F>`), badge claim section, cross-links, conformance to\n`WRITING_STYLE.md`, and every validation command from the contributing guide.\n\n## Out of scope\n\nEverything deliberately deferred, each on its own line. Name the follow-up mission where one\nis implied.\n\n## Risks\n\nAccess barriers, admin gates, and availability gaps that could block learners mid-lab.\n\n## References\n\nEvery source URL used, with descriptive link text.\n```\n\nOnly include a `preview` field or preview framing if the user confirms the mission should be\nflagged as preview. Do not add it on the assumption that a preview product implies a preview\nmission — those are separate decisions.\n\n## Phase 6: Writing-style check\n\nBefore posting, read `WRITING_STYLE.md` and run the draft against it. Two things get checked.\n\n### The spec's own prose\n\nThe issue is repo content and should read like it. Verify:\n\n- Active voice, present tense, learner addressed as \"you\" in any objective or prerequisite text\n- Sentences of 15-25 words; long paragraphs broken up\n- **Select**, never \"click\". **Field**, never \"textbox\". This is an accessibility requirement,\n  not a preference — learners may use keyboard, touch, or a screen reader\n- Action verbs opening every step-like line: Select, Enter, Navigate, Configure, Choose, Upload\n- Exact UI text in bold; values to type in code format\n- Objectives phrased as skills gained, not tasks performed, with parallel structure\n- Mission-themed but professional tone; no marketing adjectives\n\n### The style constraints the spec must pass on\n\nThe implementer should not have to rediscover these. State the ones that apply in the lab outline\nor acceptance criteria:\n\n| Mission type      | Style requirements the spec must name                                                                                                                                    |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Course            | Codename as `OPERATION NAME`, time-estimate blockquote, Mission Brief of 150-250 words, 3-5 objectives, theory before every lab, Mission Complete with next-mission link |\n| Special Ops       | No codename, agent-themed hook, dedicated `⚙️ Prerequisites` section, all concepts explained in-mission, badge claim section at `width=\"200\"`                            |\n| Cowork Collective | `? The Problem` then `? The Scenario`, `? What You'll Produce` checklist, full copy-pasteable prompts in fenced blocks, approval-flow steps documented                |\n\nAlso carry forward the screenshot rules when the mission needs images: light theme, no browser\nframe, no cursor, Microsoft red `#e91c1c` highlight boxes at 4px, cropped to the relevant region.\n\nFix anything the check surfaces before posting. Do not post and then clean up.\n\n## Phase 7: Post the issue\n\nUnless the user has already asked you to post, show the draft and get confirmation first. Filing\nan issue on a public Microsoft repo notifies watchers and cannot be undone quietly.\n\n### Gather the metadata\n\nA spec issue needs four things set: title, label, **milestone**, and **assignee**. The milestone\ncarries the due date — GitHub issues have no native due-date field, so the repo tracks delivery\nthrough fiscal-quarter milestones.\n\n- **Label** — `feature-request` is the correct label for new content proposals. There is no\n  `special-ops` or `new-mission` label. Confirm with\n  `GH_PAGER=cat gh label list --repo microsoft\u002Fagent-academy --limit 50`.\n- **Milestone** — use the quarter the user picked in Phase 2. Milestones are named by fiscal\n  quarter, for example `FY27Q1` and `FY27Q2`. Do not ask again here.\n- **Assignee** — default to the requesting user. Confirm the GitHub login with\n  `GH_PAGER=cat gh api user --jq .login`.\n\n### Create it\n\n```bash\ngh issue create --repo microsoft\u002Fagent-academy \\\n  --title \"\u003Ctitle>\" \\\n  --label feature-request \\\n  --milestone \"FY27Q1\" \\\n  --assignee \"\u003Clogin>\" \\\n  --body-file \u002Ftmp\u002F\u003Cname>.md\n```\n\nTo set a milestone or assignee on an issue that already exists, use `gh issue edit \u003Cn> --milestone`\nand `gh issue edit \u003Cn> --add-assignee`.\n\n## Phase 8: Verify and clean up\n\n1. Read the issue back:\n\n   ```bash\n   GH_PAGER=cat gh issue view \u003Cnumber> --repo microsoft\u002Fagent-academy \\\n     --json title,labels,milestone,assignees,url\n   ```\n\n   Do not request `projectCards` — Projects (classic) is deprecated and the field errors the whole\n   query out.\n\n1. Confirm all four are set: title, label, milestone, assignee. A spec with no milestone has no due\n   date and drops off the plan.\n1. Confirm the body's H1 matches the title exactly. These drift easily and nothing else catches it.\n1. Delete the temp file.\n1. Report the issue URL to the user.\n\n## ? Rules\n\n- Always prefix `gh` commands with `GH_PAGER=cat`. Without it, `gh` opens an alternate screen\n  buffer and the tool returns no output.\n- Always pass the body via `--body-file`. Inline `--body` mangles long markdown and breaks on\n  backticks and newlines.\n- Always write temp files to `\u002Ftmp\u002F`, never into the repo, and always delete them afterward.\n- Never create mission markdown files in `docs\u002F` from this skill. The output is an issue only.\n- Never invent tag, product, or industry slugs. Read the JSON data files and use what exists.\n- Never state a duplicate check result you did not actually run, and always check both the docs and\n  the existing issues.\n- Always confirm with the user before posting, unless they already asked you to post.\n- Never post a spec issue without a milestone. The milestone is the due date, and an unmilestoned\n  spec is invisible to planning.\n- Never request `projectCards` in a `gh issue view --json` query. Projects (classic) is deprecated\n  and the field fails the entire request.\n- Always run the Phase 6 writing-style check before posting. `WRITING_STYLE.md` is the source of\n  truth, and its per-mission-type sections differ — read the one that applies.\n- Never write \"click\" or \"textbox\" anywhere in the spec. Use \"select\" and \"field\".\n- When editing an existing spec issue's title, update the body's H1 in the same pass so the two\n  never drift.\n- To edit a posted body: fetch it with `gh issue view \u003Cn> --json body -q .body > \u002Ftmp\u002Fb.md`, edit\n  the file, then `gh issue edit \u003Cn> --body-file \u002Ftmp\u002Fb.md`.\n","# Create Mission Spec\n\nThis skill produces a **specification issue** — not mission content. The output is a GitHub issue\non `microsoft\u002Fagent-academy` that another contributor (or a later run of\n`agent-academy-mission-builder`) can implement from without further research.\n\nThe difference matters. A spec issue answers _what should be built and why_. The mission builder\nanswers _how it reads_. Never write the mission markdown in this skill.\n\n## ? Prerequisites\n\n1. Run `gh --version` to confirm the GitHub CLI is installed. If missing, install it\n   (`brew install gh` on macOS).\n1. Run `gh auth status` to confirm authentication. If not authenticated, run `gh auth login` and\n   guide the user through the flow.\n\nDo not proceed until both checks pass.\n\n## Mission types\n\nFour tracks exist, and each has its own folder, contributing guide, and style section. Identify\nthe track before anything else, because it determines the frontmatter contract.\n\n| Track             | Folder                         | Contributing guide                  |\n| ----------------- | ------------------------------ | ----------------------------------- |\n| Recruit           | `docs\u002Frecruit\u002FNN-slug\u002F`        | `CONTRIBUTING-COURSES.md`           |\n| Operative         | `docs\u002Foperative\u002FNN-slug\u002F`      | `CONTRIBUTING-COURSES.md`           |\n| Commander         | `docs\u002Fcommander\u002FNN-slug\u002F`      | `CONTRIBUTING-COURSES.md`           |\n| Special Ops       | `docs\u002Fspecial-ops\u002Fslug\u002F`       | `CONTRIBUTING-SPECIAL-OPS.md`       |\n| Cowork Collective | `docs\u002Fcowork-collective\u002Fslug\u002F` | `CONTRIBUTING-COWORK-COLLECTIVE.md` |\n\n`CONTRIBUTING-GENERAL.md` covers markdown linting and spell checking for every track.\n\n## Phase 1: Mine the source documentation\n\nDo this **first**, before the interview. You cannot offer the user good scoped options until you\nknow what the product actually does, and an interview built on guesses wastes a round trip.\n\nIf the user supplied URLs, fetch **all of them in parallel**. Extract and keep:\n\n- Exact tool, API, or feature names and their required vs. optional parameters\n- Endpoint URLs and placeholder segments (e.g. `{environmentId}`)\n- Licensing, role, and version prerequisites\n- Governance, admin, and observability surfaces\n- Anything gated behind admin rights, preview, or regional availability\n\nThese become the spec's **Prerequisites**, **Lab outline**, and **Risks** sections. A spec that\nparaphrases the docs is useless; a spec that names the exact tools and endpoints saves the\nimplementer an hour.\n\nIf the user supplied no URLs, ask for them before going further. Never write a spec from memory\nabout a product surface that changes as fast as these do.\n\n## Phase 2: Gather intel\n\nFirst, list the available milestones so you can offer real options rather than asking a second\ntime later:\n\n```bash\nGH_PAGER=cat gh api repos\u002Fmicrosoft\u002Fagent-academy\u002Fmilestones \\\n  --jq '.[] | \"\\(.title)  due=\\(.due_on)\"'\n```\n\nThen ask everything in **one batch** using the ask-questions tool. Never interrogate one question\nat a time. Offer concrete options with a recommended default so the user can answer by picking,\nand derive those options from what you found in Phase 1.\n\nAlways ask:\n\n1. **Mission status** — is this a new mission or an update to an existing mission? For an update,\n   ask which mission is changing and treat its current content as the implementation baseline.\n1. **Mission type** — Special Ops, Cowork Collective, or a course mission (Recruit \u002F Operative \u002F\n   Commander)?\n1. **Scenario** — what will the learner actually build? Offer 3-4 scoped options drawn from the\n   documentation rather than asking an open question.\n1. **Surface** — which product or client does the mission drive? (Copilot Studio, VS Code, both.)\n1. **Difficulty and time** — offer 2-3 sensible pairings, e.g. \"Difficulty 3, ~45 min\".\n1. **Badge codename** (Special Ops only) — offer 3-4 punchy options.\n1. **Milestone** — which fiscal quarter does this target? Offer the open milestones you just\n   listed, with the nearest one recommended. This is the due date.\n1. **Deliverable** — draft the body in chat, post the issue directly, or save to a file?\n\nIf the user already stated something in their prompt (for example \"avoid the connectors one, start\nwith Graph APIs\"), do not ask about it again. Treat it as a hard scope boundary and reflect it in\nthe **Out of scope** section.\n\n## Phase 3: Repo reconnaissance\n\nRun these in parallel:\n\n1. **Duplicate check in the docs** — `grep_search` the repo for the feature name. Distinguish a\n   real duplicate (an existing mission on the topic) from a passing mention in another mission.\n   Report either way in the issue, and link passing mentions as cross-link targets.\n1. **Duplicate check in the issues** — someone may have already filed this spec. Run\n   `GH_PAGER=cat gh issue list --repo microsoft\u002Fagent-academy --state all --search \"\u003Ckeyword>\"`.\n   Grepping the docs alone misses proposals that have not been implemented yet.\n1. **Read the contributing guide for the track** — see the Mission types table above. Each guide\n   defines a different frontmatter contract; Special Ops omits `prev`, `next`, and `codename`,\n   which course missions require.\n1. **Validate slugs** — read `docs\u002F.vitepress\u002Fdata\u002Ftags.json`, `products.json`, and\n   `industries.json`. Every `tags`, `products`, and `industries` value in the proposed frontmatter\n   must already exist in those files. If one does not, either pick an existing slug or add an\n   explicit acceptance-criteria item to create it.\n1. **Find the closest existing mission** — use it as the structural reference and name it in the\n   issue so the implementer has a template to copy.\n1. **Read `WRITING_STYLE.md`** — specifically the section matching the mission type. Course\n   missions, Special Ops, and Cowork Collective have different required sections and intros. The\n   spec must reflect the right one; proposing a `codename` for a Special Ops mission or omitting\n   the `⚙️ Prerequisites` section is a spec bug, not an authoring bug.\n\nFor a new mission, if either duplicate check finds a genuine match, **stop and tell the user**\nbefore drafting. Offer to pivot the angle, extend the existing mission, or proceed anyway. Do not\nsilently file a second spec for work that already exists. For an updated mission, confirm that the\nnamed mission exists, inspect its current content, and use related open issues to identify overlap\nrather than treating the mission itself as a duplicate.\n\n## Phase 4: Title convention\n\nFormats:\n\n- New mission: `[New Mission] \u003CSection>: \u003CAction verb> \u003Cwhat they build>`\n- Updated mission: `[Updated Mission] \u003CSection>: \u003CAction verb> \u003Cwhat changes>`\n\nExamples:\n\n- `[New Mission] Special Ops: Build your own MCP server with the MCP Management Server`\n- `[New Mission] Operative Mission 12: Ground an agent in SharePoint knowledge`\n- `[New Mission] Cowork Collective: Turn a badge-scan export into an emailed report`\n- `[Updated Mission] Special Ops: Refresh the Copilot Studio MCP lab`\n\nRules:\n\n- Use `[New Mission]` or `[Updated Mission]` according to the mission status selected in Phase 2.\n  Never use `[New Lab]`; missions are the unit of content in this repo across every track.\n- Keep the whole title **under 80 characters**. GitHub truncates issue titles around 70 in list\n  views.\n- One bracketed prefix only. Do not nest a pipe inside the brackets — `[New Mission | Special Ops]`\n  reads like a UI breadcrumb and costs characters without adding information.\n- New course missions are sequential, so include the proposed number (`Operative Mission 12`).\n  Confirm the next free number from the track's `index.md` before claiming it. Updated course\n  missions retain their existing number. Special Ops and Cowork Collective are standalone and\n  take no number.\n- Avoid repeating a product acronym. \"Microsoft MCP Management Server\" says MCP twice; \"MCP\n  Management Server\" is enough because the body spells it out.\n- Prefer \"Build your own\" over \"Build a custom\" — shorter and states the value.\n- Mirror the final title as the body's H1 so the issue reads consistently.\n\n## Phase 5: Draft the issue body\n\nWrite the body to a temp file **outside the workspace** (`\u002Ftmp\u002F`), never into the repo. Use this\nstructure:\n\n```markdown\n# \u003Ctitle>\n\n## Summary\n\nWhat the mission teaches, and the specific curriculum gap it closes. Name the existing missions\nthat cover adjacent ground so the gap is provable, not asserted. State the scope boundary here.\n\n## Proposed mission\n\nA table: Section, Folder, Title, Operation codename, Badge, Difficulty, Time.\n\n### Proposed frontmatter\n\nA fenced yaml block matching the contributing guide exactly for that mission type.\nFollow it with a line confirming whether the tag\u002Fproduct\u002Findustry slugs already exist.\n\n## Scenario\n\nA fictional company, an industry, and a concrete problem. Include the analogy the mission\nshould use in its concept brief.\n\n## Mission objectives\n\nBulleted, one concrete capability each, phrased as what the learner will do.\n\n## Prerequisites (to state in the mission)\n\nLicenses, roles, tool versions, tenant availability, and links. Bold any hard blocker.\n\n## Proposed lab outline\n\nA Recon section explaining the concept, then numbered labs. For each lab, one bold heading and\ntwo or three sentences naming the exact tools, parameters, and UI paths involved. End with a\ncleanup lab where the mission creates real resources.\n\n## Acceptance criteria\n\nA checkbox list covering: files created, assets and screenshots, required components\n(`\u003Cmission-meta \u002F>`, `\u003Canalytics-tag \u002F>`), badge claim section, cross-links, conformance to\n`WRITING_STYLE.md`, and every validation command from the contributing guide.\n\n## Out of scope\n\nEverything deliberately deferred, each on its own line. Name the follow-up mission where one\nis implied.\n\n## Risks\n\nAccess barriers, admin gates, and availability gaps that could block learners mid-lab.\n\n## References\n\nEvery source URL used, with descriptive link text.\n```\n\nOnly include a `preview` field or preview framing if the user confirms the mission should be\nflagged as preview. Do not add it on the assumption that a preview product implies a preview\nmission — those are separate decisions.\n\n## Phase 6: Writing-style check\n\nBefore posting, read `WRITING_STYLE.md` and run the draft against it. Two things get checked.\n\n### The spec's own prose\n\nThe issue is repo content and should read like it. Verify:\n\n- Active voice, present tense, learner addressed as \"you\" in any objective or prerequisite text\n- Sentences of 15-25 words; long paragraphs broken up\n- **Select**, never \"click\". **Field**, never \"textbox\". This is an accessibility requirement,\n  not a preference — learners may use keyboard, touch, or a screen reader\n- Action verbs opening every step-like line: Select, Enter, Navigate, Configure, Choose, Upload\n- Exact UI text in bold; values to type in code format\n- Objectives phrased as skills gained, not tasks performed, with parallel structure\n- Mission-themed but professional tone; no marketing adjectives\n\n### The style constraints the spec must pass on\n\nThe implementer should not have to rediscover these. State the ones that apply in the lab outline\nor acceptance criteria:\n\n| Mission type      | Style requirements the spec must name                                                                                                                                    |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Course            | Codename as `OPERATION NAME`, time-estimate blockquote, Mission Brief of 150-250 words, 3-5 objectives, theory before every lab, Mission Complete with next-mission link |\n| Special Ops       | No codename, agent-themed hook, dedicated `⚙️ Prerequisites` section, all concepts explained in-mission, badge claim section at `width=\"200\"`                            |\n| Cowork Collective | `? The Problem` then `? The Scenario`, `? What You'll Produce` checklist, full copy-pasteable prompts in fenced blocks, approval-flow steps documented                |\n\nAlso carry forward the screenshot rules when the mission needs images: light theme, no browser\nframe, no cursor, Microsoft red `#e91c1c` highlight boxes at 4px, cropped to the relevant region.\n\nFix anything the check surfaces before posting. Do not post and then clean up.\n\n## Phase 7: Post the issue\n\nUnless the user has already asked you to post, show the draft and get confirmation first. Filing\nan issue on a public Microsoft repo notifies watchers and cannot be undone quietly.\n\n### Gather the metadata\n\nA spec issue needs four things set: title, label, **milestone**, and **assignee**. The milestone\ncarries the due date — GitHub issues have no native due-date field, so the repo tracks delivery\nthrough fiscal-quarter milestones.\n\n- **Label** — `feature-request` is the correct label for new content proposals. There is no\n  `special-ops` or `new-mission` label. Confirm with\n  `GH_PAGER=cat gh label list --repo microsoft\u002Fagent-academy --limit 50`.\n- **Milestone** — use the quarter the user picked in Phase 2. Milestones are named by fiscal\n  quarter, for example `FY27Q1` and `FY27Q2`. Do not ask again here.\n- **Assignee** — default to the requesting user. Confirm the GitHub login with\n  `GH_PAGER=cat gh api user --jq .login`.\n\n### Create it\n\n```bash\ngh issue create --repo microsoft\u002Fagent-academy \\\n  --title \"\u003Ctitle>\" \\\n  --label feature-request \\\n  --milestone \"FY27Q1\" \\\n  --assignee \"\u003Clogin>\" \\\n  --body-file \u002Ftmp\u002F\u003Cname>.md\n```\n\nTo set a milestone or assignee on an issue that already exists, use `gh issue edit \u003Cn> --milestone`\nand `gh issue edit \u003Cn> --add-assignee`.\n\n## Phase 8: Verify and clean up\n\n1. Read the issue back:\n\n   ```bash\n   GH_PAGER=cat gh issue view \u003Cnumber> --repo microsoft\u002Fagent-academy \\\n     --json title,labels,milestone,assignees,url\n   ```\n\n   Do not request `projectCards` — Projects (classic) is deprecated and the field errors the whole\n   query out.\n\n1. Confirm all four are set: title, label, milestone, assignee. A spec with no milestone has no due\n   date and drops off the plan.\n1. Confirm the body's H1 matches the title exactly. These drift easily and nothing else catches it.\n1. Delete the temp file.\n1. Report the issue URL to the user.\n\n## ? Rules\n\n- Always prefix `gh` commands with `GH_PAGER=cat`. Without it, `gh` opens an alternate screen\n  buffer and the tool returns no output.\n- Always pass the body via `--body-file`. Inline `--body` mangles long markdown and breaks on\n  backticks and newlines.\n- Always write temp files to `\u002Ftmp\u002F`, never into the repo, and always delete them afterward.\n- Never create mission markdown files in `docs\u002F` from this skill. The output is an issue only.\n- Never invent tag, product, or industry slugs. Read the JSON data files and use what exists.\n- Never state a duplicate check result you did not actually run, and always check both the docs and\n  the existing issues.\n- Always confirm with the user before posting, unless they already asked you to post.\n- Never post a spec issue without a milestone. The milestone is the due date, and an unmilestoned\n  spec is invisible to planning.\n- Never request `projectCards` in a `gh issue view --json` query. Projects (classic) is deprecated\n  and the field fails the entire request.\n- Always run the Phase 6 writing-style check before posting. `WRITING_STYLE.md` is the source of\n  truth, and its per-mission-type sections differ — read the one that applies.\n- Never write \"click\" or \"textbox\" anywhere in the spec. Use \"select\" and \"field\".\n- When editing an existing spec issue's title, update the body's H1 in the same pass so the two\n  never drift.\n- To edit a posted body: fetch it with `gh issue view \u003Cn> --json body -q .body > \u002Ftmp\u002Fb.md`, edit\n  the file, then `gh issue edit \u003Cn> --body-file \u002Ftmp\u002Fb.md`.\n",{"name":5,"description":40,"argument-hint":41},"Turn a mission or lab idea into a fully researched GitHub issue spec on microsoft\u002Fagent-academy, then post it with the GitHub CLI. Use this skill whenever the user wants to propose new Agent Academy content before writing it — course missions (Recruit, Operative, Commander), standalone Special Ops, or Cowork Collective missions. Trigger whenever the user says \"write a spec for a mission\", \"create an issue for a new lab\", \"I want to propose a Special Ops\", \"file a mission proposal\", \"spec out a lab\", \"open an issue for a new module\", or hands over Microsoft Learn URLs and asks to turn them into an Agent Academy lab. This skill handles: mining source documentation, interviewing for scope, repo reconnaissance and duplicate detection across both docs and existing issues, frontmatter and tag validation, writing-style conformance, drafting the issue body, title conventions, milestone and assignee metadata, and posting plus verifying the issue via `gh`.\n","Optionally provide the topic and any source documentation URLs for the mission.","main","989277d271bbc8776ba09173471689ea151c193d",".github\u002Fskills\u002Fcreate-mission-spec",218,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy","https:\u002F\u002Faka.ms\u002Fagent-academy","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 23:08:32",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add microsoft\u002Fagent-academy --skill create-mission-spec",{"tool":58,"command":59},"bunx","bunx skills add microsoft\u002Fagent-academy --skill create-mission-spec",{"tool":61,"command":62},"pnpm","pnpm dlx skills add microsoft\u002Fagent-academy --skill create-mission-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcreate-mission-spec\u002FSKILL.md",true,[66,72,76,80,86],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Ftemplate-api-docs.md","ASSET","资产文件",5648,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fadhd-friendly-documentation\u002Fassets\u002Ftemplate-api-docs.md",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"assets\u002Ftemplate-quick-start.md",2600,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fadhd-friendly-documentation\u002Fassets\u002Ftemplate-quick-start.md",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"assets\u002Ftemplate-tutorial.md",4768,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fadhd-friendly-documentation\u002Fassets\u002Ftemplate-tutorial.md",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fadhd-patterns.md","REFERENCE","参考文档",7397,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fadhd-friendly-documentation\u002Freferences\u002Fadhd-patterns.md",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fchecklist.md",4134,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fdot_claude\u002Fskills\u002Fadhd-friendly-documentation\u002Freferences\u002Fchecklist.md",[91,106,114,122,129,136],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":103,"publishedAt":35},"01M699N3CMNAZY11BM55YDB2VY","outlook-pre-onboarding-checklist-meeting","Create a 1-hour Outlook follow-up meeting for pre-onboarding after a successful Docusign workflow trigger, using the employee name and agreement effective date from workflow context.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002Fdocs\u002Fspecial-ops\u002Fdocusign-mcp\u002Fassets\u002Fsample-skill\u002FSKILL.md",[97,100],{"categoryNo":98,"categoryName":99,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000034","行政与办公人员",{"categoryNo":101,"categoryName":102,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源",[104,105],"outlook pre onboarding checklist meeting","workflow",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":35},"01M699N27KQF7X22QHFTYBCGH2","device-guidance-v1-0-4","Helps employees identify available device options based on their needs, using the `Get Employee Assets` tool.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002Fdocs\u002Frecruit-nextgen\u002F07-automate-with-workflows\u002Fassets\u002Fdevice-guidance-v1-0-4\u002FSKILL.md",[],[113],"device guidance v1 0 4",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":35},"01M699N109HNVTY7D4TARZ6WCT","troubleshooting-procedure","Call this when a user states an IT issue and requests troubleshooting help. It provides step-by-step procedure for diagnosing and resolving IT issues, including escalation with a ticket summary.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002Fdocs\u002Frecruit-nextgen\u002F06-add-skills\u002Fassets\u002Fit-troubleshooting-procedure\u002FSKILL.md",[],[121],"troubleshooting procedure",{"skillNo":123,"name":124,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":35},"01M699MZTEGG5Z9HJEPPWR8MX0","device-guidance-v1-0-3","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002Fdocs\u002Frecruit-nextgen\u002F06-add-skills\u002Fassets\u002Fdevice-guidance-v1-0-3\u002FSKILL.md",[],[128],"device guidance v1 0 3",{"skillNo":130,"name":131,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":35},"01M699MY3MXWR14ZKG8J2S2W81","device-guidance-v1-0-2","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002Fdocs\u002Frecruit-nextgen\u002F06-add-skills\u002Fassets\u002Fdevice-guidance-v1-0-2\u002FSKILL.md",[],[135],"device guidance v1 0 2",{"skillNo":137,"name":138,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":35},"01M699MWSGDSNKX7F5A9E9TC4K","device-guidance-v1-0-1","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-academy\u002Fblob\u002Fmain\u002Fdocs\u002Frecruit-nextgen\u002F06-add-skills\u002Fassets\u002Fdevice-guidance-v1-0-1\u002FSKILL.md",[],[142],"device guidance v1 0 1"]