Technical documentation skill for Microsoft M&A tenant restructuring playbook. Use when creating or editing playbook documentation for mergers, acquisitions, divestitures, and related Microsoft 365/Azure tenant scenarios. Triggers on requests to start a new topic/doc/page, edit existing playbook content, or work with the playbook project structure.
Suggest topic name and filename, ask for confirmation or override
Propose placement in mkdocs.yml nav based on logical grouping, ask to confirm or override
Create the .md file with H1 title, add to mkdocs.yml
Ask for topic description
Conduct extensive research prioritizing Microsoft public documentation; evaluate any user-provided sources and considerations
Search /docs for related topics and incorporate context
Ask if user has additional information; review carefully, ask clarifying questions, conduct follow-up research; flag any contradictions with research findings
Ask clarifying questions iteratively until confident in understanding
Provide summary of understanding for user review
Edit Topic Workflow
When editing an existing topic:
Locate the .md file, ask user to confirm correct file
Read existing doc and any referenced playbook docs for context
Complete steps 6-10 from new topic workflow
Ask for confirmation before applying edits to file
Document Structure
Standard Playbook Topics
Hybrid documents combining conceptual and procedural content:
# Topic title
Brief summary of the topic (no "this document contains..." language)
## [Conceptual sections]
- Establish understanding
- Document key decisions
- Capture limitations and issues
## Implementation backlog
### [Backlog item name]
(format detailed below)
## Tests
### [Test Name]
(format detailed below)
## Sources
- [Title](URL) — Source, accessed YYYY-MM-DD
## Related topics
- [Topic Name](relative-path.md)
## Version history
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | YYYY-MM-DD | Owen Lundberg | Initial publication |
Include only: conceptual sections, Sources, Version history
Exclude: Implementation backlog, Tests, Related topics
Site-Level Pages
/docs/index.md and /docs/about.md:
User provides specific guidance on structure and content
Do not apply standard playbook sections
Style guidelines still apply
Drafting Workflow
Agree on table of contents for conceptual sections before drafting
Work section by section: draft, present for review, iterate, then proceed to next section (unless user says to write entire doc)
Before writing Implementation Backlog: present list of proposed backlog items with brief summaries for approval
Before writing Tests: present list of proposed tests with brief summaries for approval
Voice and Tone
Imperative mood: "Configure the policy..." not "You configure the policy..."
Active voice
Present tense for system behavior
Direct and concise, no filler phrases
No ambiguous language; state uncertainty clearly
Formatting
Headings
H1: Document title only (one per doc)
H2: Major sections
H3: Subsections
H4: Use sparingly
Headings in sentence case
Procedures
No sub-bullets (they don't render properly)
Use standard text for grouping steps
Placeholders in code: <PLACEHOLDER> format
Tables
Use when sensible for content, but sparingly (difficult to work with in markdown).
Images and Diagrams
User provides images and diagrams
Agree on placement in document
Never produce ASCII diagrams
Code Blocks
Use fenced code blocks with language identifiers:
# Example with placeholder
Connect-ExchangeOnline -UserPrincipalName admin@<TENANT_DOMAIN>
Callout Types
Type
Use Case
!!! warning
Actions that could cause problems if not followed correctly
!!! danger
Irreversible actions, data loss risks, security implications
!!! info
Supplementary context that aids understanding
!!! note
Important details that shouldn't be overlooked
!!! tip
Best practices, efficiency suggestions
!!! question
Uncertainty requiring verification before taking dependency
Backlog Item Format
Under "## Implementation Backlog", each item uses H3 heading with just the name:
### Configure Organization Relationship
**Objective:** What this accomplishes.
**Level of Effort:** Low | Medium | High | Very High
**Prerequisites:**
- Prerequisite one
- Prerequisite two
**Steps:**
1. First step.
2. Second step.
**Test:** Link to corresponding test in Tests section
**References:**
- [Most relevant doc](URL)
- [Supporting doc](URL)
Level of effort estimates:
Low — Less than 1 day
Medium — 1-2 days
High — 3-5 days
Very high — More than 5 days
Test Format
Under "## Tests", each test uses H3 heading with just the name:
### Verify Organization Relationship
**Objective:** What this test confirms.
**Prerequisites:**
- Prerequisite one
**Steps:**
1. First step.
2. Second step.
**Expected result:** What success looks like.
Version History
Auto-populate initial entry when creating new docs