# office-docs-powershell: the source behind Microsoft's cmdlet reference > The office-docs-powershell repository holds the Markdown files that become the PowerShell reference for Office products on Microsoft Learn, and it is where a cmdlet article is written, reviewed and published. Its most important constraint is not editorial but structural, because the same files are converted into command line help through the platyPS schema. **MicrosoftDocs/office-docs-powershell** — PowerShell Reference for Office Products - Short URL: aka.ms/office-powershell - Repository: https://github.com/MicrosoftDocs/office-docs-powershell - Stars: 660 · Forks: 1,401 - Language: JavaScript - License: CC-BY-4.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoftdocs-office-docs-powershell ## A docs repository, not a module The repository description is plain about what it is: a PowerShell Reference for Office Products, with the short URL aka.ms/office-powershell. The primary language is listed as JavaScript, which reflects the tooling rather than the content, since what the repository holds is Markdown. The substance is a set of cmdlet reference articles for the Office product family, organised into directories that mirror the product areas, with exchange/, officewebapps/, teams/, skype/, whiteboard/, inkcanvas/, spmt/, ms-commerce/ and m365xtap/ alongside repo_docs/, images/, tools/, test/ and ThirdPartyNotices. The articles on learn.microsoft.com are formatted in Markdown, and the repository states that the documentation is published to Microsoft Learn and that contributors are listed on the repository's contributors graph. There is no build artefact to install and no runtime to depend on. The audience for a pull request here is a documentation contributor, not a consumer of a library. ## One article, two consumers: the page and Get-Help The most consequential sentence in the README is a tip block, and it explains the whole editing constraint. Cmdlet reference articles follow a strict schema with limited formatting options, because the articles are also converted and used for help at the command line, with the example given as Get-Help . That is why the schema is named: the platyPS schema, which is what the PowerShell documentation tooling consumes when it generates that help. The practical consequence for a contributor is that the freedom you have on a general documentation page is not available here. A heading hierarchy that reads well in a browser may break the conversion, and a construct the schema does not allow will not survive the trip. The README's instruction is to use existing content as a guide rather than to invent structure, and the schema documentation in the platyPS repository is the place to check whether a construct is allowed. It is a strange constraint to hit in a prose format, but it is the reason this repository is not just another set of Markdown files. ## Editing a single article from the browser The README documents a contribution path for people who make infrequent or small updates, and it is worth following because it needs no local tooling at all. You find the article on learn.microsoft.com, use the More actions menu above the title to select Edit, and GitHub opens the corresponding file in a line-numbered editor where you can make the change directly. The sequence in the README runs from signing in to GitHub.com, to finding the article, to opening it for editing. ```bash 1. Verify you're signed in to GitHub.com with your GitHub account. 2. On learn.microsoft.com, find the article you want to update. 3. Above the article title, select **⋮** **More actions \> ![Edit icon.](images/quick-update-icon-learn-edit.png) **Edit**. ``` The tip above that list says that to edit an article you need to get to it on the GitHub.com backend, and if you are already on the GitHub.com page of the article you are starting at a later step. The README also points out that your permissions in the repository determine what you see, and that people with the ability to approve their own pull requests get a similar experience with different button names, for example Commit changes instead of Propose changes, plus extra options for creating a branch and fewer confirmation pages. The practical advice it gives is blunt: select any green buttons presented to you until there are none more. ## The green button path from editor to live article The rest of the workflow is a fixed sequence of GitHub screens, and the README walks through all ten steps with a screenshot for each. After the edit, if a You need to fork this repository to propose changes page appears you fork the repository, and the article file opens in the line-numbered editor. There is a Preview option to see changes as you go and an Edit option to return to editing. When you are finished, the green Commit changes button opens the Propose changes dialog, where the commit message is required, with a default commit message that you can accept or replace, and an optional extended description where you can explain the change and mention a GitHub alias for someone to review and merge. After the pull request is created on the comparing changes page and titled on the open a pull request page, the README says there is nothing more for you to do. The article owner, identified in metadata, is notified, and eventually the owner or another party reviews, possibly edits, and approves the change. After the reviewer merges the pull request, the article is updated on learn.microsoft.com. The ms.date metadata field at the top of the README, 09/18/2025, is the kind of value the schema expects, and the file is a Markdown document with front matter rather than a plain file. ## Publishing goes through Microsoft Learn, not through GitHub Pages The repository carries the configuration that makes a merge reach the live site, and the file names describe the pipeline. There is an .openpublishing.publish.config.json for the publish settings, and a family of redirection files, .openpublishing.redirection.exchange.json, .openpublishing.redirection.officewebapps.json, .openpublishing.redirection.skype.json, .openpublishing.redirection.spmt.json, .openpublishing.redirection.teams.json and .openpublishing.redirection.whiteboard.json, which map old URLs to new ones so that a link that has moved does not break. The .gitattributes file is there for line ending handling, and SECURITY.md, ContentOwners.txt and cabgen-bootstrap.yml sit alongside it. The point is that the merge is not the publication. A merged pull request updates the article on learn.microsoft.com through this publishing configuration, which means the timing of a change going live is not entirely under the contributor's control, and a URL that moves is handled by a redirection file rather than by hand. ## Two licences, and the CLA you only sign once The legal section of the README separates two grants. Microsoft and any contributors grant you a licence to the Microsoft documentation and other content in the repository under the Creative Commons Attribution 4.0 International Public License, and a licence to any code in the repository under the MIT License, in the LICENSE and LICENSE-CODE files respectively. So the prose is CC-BY-4.0 and the code samples are MIT, which is the split you want in a repository where most of the bytes are prose and the code is illustrative. The README also notes that the licences do not grant rights to use any Microsoft names, logos or trademarks, and points at the general trademark guidelines, with privacy information linked separately. On the contribution side, the project welcomes contributions and most contributions require agreeing to a Contributor License Agreement that declares you have the right to grant the rights to use your contribution. A CLA bot then determines whether you need to provide a CLA and decorates the pull request, and the README stresses that you only need to do this once across all repositories using the Microsoft CLA. There is also an adopted Microsoft Open Source Code of Conduct with its own FAQ and a contact address for questions. ## Where this repository is the wrong place to work Two cases point elsewhere. The first is anyone who wants the PowerShell modules themselves. This repository is the documentation source, and the directory names map to product areas rather than to publishable packages, so a reader looking for a way to install a cmdlet will find nothing to install. The second is a team that needs to publish cmdlet help under its own name and on its own schedule. The route here runs through a pull request, a review by the article owner identified in metadata, and the Microsoft Learn publishing configuration, which is a deliberate governance model for a vendor's own reference documentation, not a general-purpose publishing system. A smaller constraint applies to the writing itself. Because the same article feeds Get-Help, contributors cannot use the full Markdown feature set even though the file format is Markdown, and the README points to the platyPS schema rather than to a general style guide. Contributors who want to write explanatory prose about PowerShell concepts rather than correct a cmdlet reference page will find the constraint working against them, and the repository's peer doc set is the place for that kind of article rather than this one. ## Conclusion office-docs-powershell fits a documentation contributor who wants to correct or extend the PowerShell reference for Office products, and who is willing to work inside the platyPS schema and the review queue. It does not fit a developer looking for a PowerShell module, because nothing here is installable, and it does not fit a team that wants to publish cmdlet help on its own schedule, since the publishing route runs through Microsoft Learn and a pull request review. Before you contribute, read the schema note rather than copying an existing page blindly, because the same article is both documentation and command line help, and check the CONTRIBUTING guide for the CLA step, which is a one-time requirement across the Microsoft documentation repositories. ## FAQ ### What is the office-docs-powershell repository? It is the MicrosoftDocs repository holding the PowerShell Reference for Office Products, with the short URL aka.ms/office-powershell. Its articles are formatted in Markdown, published to Microsoft Learn, and contributors are listed on the repository's contributors graph. The content is organised into product directories such as exchange/, officewebapps/, teams/, skype/ and whiteboard/. ### Why are cmdlet articles limited to a strict schema? Because the articles are also converted and used for help at the command line, with Get-Help given as the example, so the pages have to satisfy the platyPS schema. The README says to use existing content as a guide and links to the platyPS schema documentation for the details of what is allowed. ### How do I contribute a small fix without installing anything? Edit the file directly on GitHub.com. Find the article on learn.microsoft.com, use the More actions menu to select Edit, and the corresponding file opens in a line-numbered editor on GitHub. Fork the repository if you are asked to, commit the change, create the pull request, and the article owner reviews and merges it before the article is updated on learn.microsoft.com. ### What licence applies to the content and the code in this repository? Two. Microsoft and contributors grant the documentation and other content under the Creative Commons Attribution 4.0 International Public License, in the LICENSE file, and grant a licence to any code in the repository under the MIT License, in the LICENSE-CODE file. The licences do not grant rights to use Microsoft names, logos or trademarks. ### Do I have to sign a CLA to contribute? Most contributions require agreeing to a Contributor License Agreement declaring that you have the right to grant the rights to use your contribution. A CLA bot determines whether you need to provide one and decorates the pull request, and the README notes that you only need to do this step once across all the repositories using the Microsoft CLA. ## Sources - [Issues](https://github.com/MicrosoftDocs/office-docs-powershell/issues) - [License: CC-BY-4.0](https://github.com/MicrosoftDocs/office-docs-powershell/blob/main/LICENSE) - [MicrosoftDocs/office-docs-powershell on GitHub](https://github.com/MicrosoftDocs/office-docs-powershell) - [README](https://github.com/MicrosoftDocs/office-docs-powershell/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoftdocs-office-docs-powershell