m365-tenant-automation

Stars3

Forks1

UpdatedJuly 23, 2026 at 22:15

M365 scripting: Entra ID, Exchange, SharePoint, Teams, Graph, licensing, inventory, or tenant config. Not for unrelated PowerShell.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

ilude

ilude/dotfiles

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	m365-tenant-automation
description	M365 scripting: Entra ID, Exchange, SharePoint, Teams, Graph, licensing, inventory, or tenant config. Not for unrelated PowerShell.

Microsoft 365 Tenant Automation

Boundary

Use m365-tenant-automation for cloud tenant state and service APIs. Use shell for generic PowerShell mechanics. Use private-store for sensitive exports, credentials, and tenant data custody.

Core Principles

Scripts must be convergent: repeated runs should move the tenant toward the declared target state without duplicate objects or unnecessary churn.
Treat live tenant inventory as the source of truth before mutation. Query current state and compare before creating, updating, or removing objects.
Keep tenant-specific environments separate: config, exports, credentials, app registrations, domains, and IDs must not bleed across tenants.
Prefer Graph, service modules, or supported CLI/API operations over UI-only runbooks. Verify API and CLI support before documenting a UI-only gap.

Practical Steps

Identify tenant, environment, cloud, module versions, scopes, and target workload.
Capture live inventory for affected objects and keep sensitive exports in private storage.
Diff desired state against live state and present intended mutations.
Use ShouldProcess/-WhatIf for administrative PowerShell mutations.
Apply least-privilege scopes and tenant-specific authentication.
Re-query live state after mutation and record object IDs or audit-relevant evidence.

Safety Checks

Do not reuse cached tokens, app IDs, or environment files across tenants without explicit confirmation.
Do not hardcode tenant IDs, secrets, domains, or certificate paths into reusable source.
Do not delete or disable users, groups, apps, connectors, or policies without explicit approval and rollback notes.
Store raw tenant exports under the private data workflow when they contain users, groups, domains, IDs, or configuration details.

Anti-patterns

Assuming declared config is accurate without live inventory.
Creating objects without stable lookup keys and idempotency checks.
Mixing prod, test, and client tenant variables in one environment file.
Treating portal screenshots as the source of truth when APIs can return authoritative state.

More from this repository

same repository

pi-extension

ilude/dotfiles

Pi extensions and tool policy: extensions/*.ts, hooks, registerTool, promptGuidelines, registerCommand, footer/status UI, tool_result, session hooks, or subprocesses. Not for slash-command placement; use pi-command.

2026-08-023

docs

ilude/dotfiles

README, CHANGELOG, docs/, RFCs, ADRs, guides, or Markdown structure. Not for prose cleanup or archival work.

2026-07-273

no-ai-slop

ilude/dotfiles

Prose cleanup for filler, hype, vague claims, repetition, detection tells, or uncited specifics. Not for Markdown architecture or archival work.

2026-07-273

planning

ilude/dotfiles

Requirements, user stories, acceptance/verification criteria, or testable outcomes. Not for PRD drafting (/prd) or Pi /goal prompts.

2026-07-273

prd

ilude/dotfiles

Use for /prd-it or to draft, refine, or review a Product Requirements Document. Not for acceptance criteria, planning, or Pi /goal prompts.

2026-07-273

pi-log-analytics

ilude/dotfiles

Pi session, trace, metrics, routing, workflow-friction, workflow-telemetry, usage, or local JSONL analysis with DuckDB. Use for aggregating or correlating Pi runtime logs. Not for adding telemetry, generic SQL/database design, or non-Pi logs.

2026-07-273

Microsoft 365 Tenant Automation

Boundary

Use m365-tenant-automation for cloud tenant state and service APIs. Use shell for generic PowerShell mechanics. Use private-store for sensitive exports, credentials, and tenant data custody.

Core Principles

Scripts must be convergent: repeated runs should move the tenant toward the declared target state without duplicate objects or unnecessary churn.

Treat live tenant inventory as the source of truth before mutation. Query current state and compare before creating, updating, or removing objects.

Keep tenant-specific environments separate: config, exports, credentials, app registrations, domains, and IDs must not bleed across tenants.

Prefer Graph, service modules, or supported CLI/API operations over UI-only runbooks. Verify API and CLI support before documenting a UI-only gap.

Practical Steps

Identify tenant, environment, cloud, module versions, scopes, and target workload.

Capture live inventory for affected objects and keep sensitive exports in private storage.

Diff desired state against live state and present intended mutations.

Use ShouldProcess/-WhatIf for administrative PowerShell mutations.

Apply least-privilege scopes and tenant-specific authentication.

Re-query live state after mutation and record object IDs or audit-relevant evidence.

Safety Checks

Do not reuse cached tokens, app IDs, or environment files across tenants without explicit confirmation.

Do not hardcode tenant IDs, secrets, domains, or certificate paths into reusable source.

Do not delete or disable users, groups, apps, connectors, or policies without explicit approval and rollback notes.

Store raw tenant exports under the private data workflow when they contain users, groups, domains, IDs, or configuration details.

Anti-patterns

Assuming declared config is accurate without live inventory.

Creating objects without stable lookup keys and idempotency checks.

Mixing prod, test, and client tenant variables in one environment file.

Treating portal screenshots as the source of truth when APIs can return authoritative state.