policy-check

$npx mdskill add microsoft/FluidFramework/policy-check

Run `pnpm policy-check --path <relative-path>` from the repo root to check a specific package. Do NOT `cd` into the package directory.

SKILL.md

.github/skills/policy-checkView on GitHub ↗
---
name: policy-check
description: This skill should be used when the user asks to "run policy check", "check policy", "policy-check", or needs to validate package compliance. Provides guidance on running policy checks for specific packages or the entire repository.
---

Run `pnpm policy-check --path <relative-path>` from the repo root to check a specific package. Do NOT `cd` into the package directory.

Even when changes are applied to a single package, repository-wide checks (`pnpm policy-check` without `--path`) are still appropriate since changes in one package can cause policy failures in others.

More from microsoft/FluidFramework

SkillDescription
api-changesUse when customer-facing API changes were made — i.e., API report .md files differ from main. Guides through release tag assignment, API Council review requirements, breaking change classification, deprecation process, and changeset guidance. Triggered automatically by ci-readiness-check when api-report diffs are detected.
brainstormingIMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
building-ui-uxUse when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
ci-readiness-checkUse when the user explicitly asks for a CI check or to push their branch — e.g. "ci readiness", "check ci", "pre-push check", "ready for CI", "ci check", "ready to push", "push my changes", "push the branch", "let's push". Catches common CI failures before pushing — formatting, stale API reports, missing changesets, policy violations.
creating-debug-tests-and-iteratingUse this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.
creating-skillsUse when you need to create a new custom skill for a profile - guides through gathering requirements, creating directory structure, writing SKILL.md, and optionally adding bundled scripts
ff-oce-dashboardGenerate the OCE shift status dashboard. Triggers on: 'generate shift dashboard', 'show dashboard', 'shift status', 'status dashboard', 'what's going on', or any request for a NON-SPECIFIC overview of current OCE status (incidents, pipelines, errors).
ff-oce-kustoUse this skill for any Kusto query or telemetry investigation specifically related to Fluid Framework or its partners. Triggers include: writing or running a Kusto query against the Office Fluid database, investigating Fluid Framework telemetry or error rates, querying Office_Fluid_FluidRuntime_* tables, looking up a Fluid session by Session_Id or docId, investigating a Fluid-related error in Loop or Whiteboard telemetry, monitoring an FF bump or partner ring deployment, checking Fluid render reliability or Scriptor errors, or when the user mentions Fluid-specific tables (Office_Fluid_FluidRuntime_*, OwhLoads, HostTracker, Scriptor) or Fluid-specific error types (dataCorruptionError, dataProcessingError, DeltaConnectionFailureToConnect, ICE, ACE). Do NOT trigger for general Kusto questions that are not related to Fluid Framework.
finishing-a-development-branchUse this when you have completed some feature implementation and have written passing tests, and you are ready to create a PR.
fluid-prUse when creating a pull request in the Fluid Framework repo. Composes a PR title and body following Fluid Framework conventions, proposes them to the user, then pushes the branch and creates the PR on GitHub. Triggers on "create a PR", "make a PR", "open a PR", "submit a PR", or "push and create a PR".