New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Project Health Check

by pnp in pnp/sharepoint-skills

Analyze SharePoint project content and project lists to produce a concise project health assessment covering schedule, risks, actions, decisions, and documentation.

MITAuto-check passedDocuments & Office

Install Project Health Check

skills CLI
$ npx skills add pnp/sharepoint-skills --skill project-health-check -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install pnp/sharepoint-skills project-health-check --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/pnp/sharepoint-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/Skills/project-health-check/project-health-check .claude/skills/project-health-check && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
project-health-check
GitHub stars
133
Token cost
~5.6k tokens
SKILL.md length
2,873 words
Files
1
Skills in repo
52
Repo updated
First seen
Licence
MIT

At a glance

Analyze SharePoint project content and project lists to produce a concise project health assessment covering schedule, risks, actions, decisions, and documentation.

  • Works in 5 steps: Project Health → Health Summary → Key Findings → …
  • The user asks for a project health check
  • SKILL.md covers Purpose, Before Starting, Preferred Sources and Output Structure, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Project Health Check is an agent skill from pnp/sharepoint-skills. Analyze SharePoint project content and project lists to produce a concise project health assessment covering schedule, risks, actions, decisions, and documentation. Use when the user asks for a project health check, project status assessment, RAG status, project review, or management health summary.

Its SKILL.md is about 5.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Documents & Office, covering Cloud office suites and Project management. It works with Microsoft SharePoint. The repository describes itself as: Skills for Copilot in SharePoint. The licence is MIT.

When your agent uses it

  • The user asks for a project health check
  • Project status assessment
  • Management health summary

Example prompts

  • “/project-health-check”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Project Health
  2. Health Summary
  3. Key Findings
  4. Management Attention
  5. Evidence and Coverage

What it can do on your machine

Read from SKILL.md and the folder at commit 69712d2. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are html).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Project Health Check loads about 5.6k tokens when it runs. Until then it costs about 80 tokens; SKILL.md has 2,873 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~80
When it runs · the whole SKILL.md, loaded when a task matches
~5.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from pnp/sharepoint-skills at commit 69712d2, republished under its MIT licence (© pnp). 2,873 words, ~5,577 tokens.

Download SKILL.mdSave it as .claude/skills/project-health-check/SKILL.md (or your agent's skills folder).
name
project-health-check
description
Analyze SharePoint project content and project lists to produce a concise project health assessment covering schedule, risks, actions, decisions, and documentation. Use when the user asks for a project health check, project status assessment, RAG status, project review, or management health summary.

Project Health Check

Purpose

Assess the current health of a project from the SharePoint content available to the user. Review project documents and, when available, structured SharePoint lists such as milestones, risks, actions, decisions, and deliverables.

The skill must produce an evidence-based health assessment. Never invent project facts, dates, owners, statuses, or missing documents.

Before Starting

  1. Determine the project scope from the user's selection, current SharePoint location, or prompt.
  2. Use the selected files and relevant project content available on the current SharePoint site.
  3. Prefer current, authoritative project artifacts over older drafts.
  4. If several project areas are present and the intended project is ambiguous, ask the user which project to assess.
  5. If a project reporting date is explicitly provided, use it. Otherwise use the current date.
  6. Do not require every source type below. Work with the information that is available and report coverage gaps.

Preferred Sources

Look for evidence in these source types when available:

  • Project charter, project brief, or initiation document
  • Current status report
  • Milestone or project plan
  • Risk register
  • Action / issue register
  • Decision register
  • Deliverables or document register
  • Meeting minutes and steering committee notes
  • Other project documents that contain dates, commitments, blockers, owners, or decisions

Structured lists should be treated as primary sources for the facts they own. For example, use a Risk Register for risk status when one is available rather than inferring all risks from narrative documents.

Output Structure

Produce the result in this order.

1. Project Health

State one overall status:

  • GREEN — project is broadly on track; no material issue needs management attention.
  • AMBER — one or more material concerns require attention, but recovery appears achievable.
  • RED — a critical condition threatens delivery or requires immediate management action.
  • UNKNOWN — available evidence is insufficient for a reliable health assessment.

Then give a one-sentence explanation.

2. Health Summary

Use exactly these five bullet lines. Do not use a Markdown table because citation markers inserted by the host can break table rendering.

  • Schedule & milestones — GREEN / AMBER / RED / UNKNOWN: evidence-based assessment
  • Risks & issues — GREEN / AMBER / RED / UNKNOWN: evidence-based assessment
  • Actions — GREEN / AMBER / RED / UNKNOWN: evidence-based assessment
  • Decisions & dependencies — GREEN / AMBER / RED / UNKNOWN: evidence-based assessment
  • Documentation & governance — GREEN / AMBER / RED / UNKNOWN: evidence-based assessment
3. Key Findings

Summarize the most important findings. Prefer 3–7 items and prioritize by business impact.

4. Management Attention

List only the items that need management action or awareness. For each item include:

  • What needs attention
  • Why it matters
  • Owner, if explicitly known
  • Due date, if explicitly known
  • Recommended next action
5. Evidence and Coverage

State:

  • Main sources used
  • Important project areas for which evidence should already exist at the current reporting point but no reliable evidence was found
  • Any assumptions or ambiguities that reduce confidence

Do not report a missing source type merely because it is common in project management. Do not call out a budget report, issue register, resource plan, or similar artifact unless the project says it is required/relevant or the user explicitly requested that dimension.

Give a confidence level: High, Medium, or Low.

Step 1: Establish Project Context

Identify, when available:

  • Project name
  • Project manager
  • Sponsor
  • Start date
  • Target completion date
  • Current reporting period
  • Main objectives and deliverables

Do not fail the health check if some of these values are missing. Record missing context as a governance or coverage observation only when it is material.

Step 2: Review Schedule and Milestones

Determine the status of significant milestones and delivery dates.

Classify Schedule & milestones as:

GREEN
  • No material milestone is overdue.
  • Near-term milestones appear achievable.
  • No credible evidence indicates schedule slippage.
AMBER

Use AMBER when one or more of these conditions is supported by evidence:

  • A significant milestone is overdue but recovery is plausible.
  • A milestone due soon is explicitly at risk.
  • A dependency may cause delay.
  • Current reporting states that schedule recovery or mitigation is required.
RED

Use RED when one or more of these conditions is supported by evidence:

  • A critical milestone has been missed with material delivery impact.
  • The target completion date is no longer credible.
  • A critical-path dependency is blocked with no viable mitigation.
  • The current status report explicitly identifies schedule as critical/off track.

If no meaningful schedule information exists, use UNKNOWN.

Schedule date wording

Distinguish date concepts precisely:

  • Overdue by N days = reporting/current date minus planned due date, only when the item is incomplete.
  • Forecast delay / forecast variance of N days = forecast completion date minus planned due date.
  • Never describe forecast variance as the number of days an item is currently overdue.
  • An item due on the reporting/current date is due today, not overdue.
  • A future date is not overdue.

Example: if a milestone was due 10 September, today is 15 September, and forecast completion is 22 September, say "5 days overdue and forecast to finish 12 days later than planned."

Step 3: Review Risks and Issues

Evaluate open risks and active issues. Consider severity, probability, impact, mitigation, ownership, and age where available.

Classify Risks & issues as:

GREEN
  • No open high/critical risk or major unresolved issue is identified.
  • Material risks have owners and credible mitigations.
AMBER
  • At least one high risk exists but has a plausible mitigation.
  • A material issue exists but recovery is in progress.
  • A significant risk lacks a complete owner, mitigation, or target date.
RED
  • A critical risk or issue threatens a key project objective.
  • A high-impact issue has no credible mitigation.
  • Multiple high risks combine to threaten delivery.
  • An issue has already invalidated a key project commitment.

If no reliable risk or issue evidence exists, use UNKNOWN.

Step 4: Review Actions

Evaluate open actions from registers, minutes, and status reports.

Classify Actions as:

GREEN
  • No material action is overdue.
  • Critical actions have owners and due dates.
AMBER
  • One or more important actions are overdue.
  • A material action is missing an owner or target date.
  • Several open actions show signs of execution delay.
RED
  • A critical overdue action blocks a milestone, decision, release, or mitigation.
  • Repeatedly overdue actions materially threaten project delivery.

If no reliable action evidence exists, use UNKNOWN.

Step 5: Review Decisions and Dependencies

Review unresolved decisions and important internal or external dependencies.

Classify Decisions & dependencies as:

GREEN
  • No material decision is overdue or blocking progress.
  • Critical dependencies appear controlled.
AMBER
  • A decision is overdue or approaching a date where delay will affect delivery.
  • A significant dependency is unresolved but has a manageable mitigation.
RED
  • An overdue decision or dependency is actively blocking a critical milestone.
  • A required decision can no longer be delayed without material impact.

If no reliable evidence exists, use UNKNOWN.

Step 6: Review Documentation and Governance

Evaluate whether key project artifacts are present, current, and internally consistent.

Only identify a document as missing when:

  1. A project document/register explicitly defines it as required, or
  2. The user supplied an expected-document checklist.

Do not assume that a generic project methodology automatically applies.

Classify Documentation & governance as:

GREEN
  • Required project artifacts found in the reviewed scope appear current enough for the reporting period.
  • No material contradiction between authoritative sources is detected.
AMBER
  • A required artifact is overdue and the expected evidence is not present.
  • A required artifact for a current or completed governance gate is missing, stale, materially incomplete, or contradictory.
  • A required future artifact is credibly at risk because prerequisite work, preparation, approval, ownership, or scheduling is missing or delayed.
  • Owners, review dates, or other key governance information needed for an upcoming gate are incomplete.
Treatment of future deliverables

Do not classify a future required deliverable as missing, deficient, or a coverage gap merely because its final evidence does not yet exist.

Evaluate future deliverables according to their delivery context:

  • Expected / not yet due: Informational only. Do not lower Documentation & governance solely because final evidence is not yet present.
  • Due soon and preparation is expected: Assess whether preparation, prerequisites, ownership, scheduling, or draft evidence indicates that delivery is on track.
  • At risk before due date: Use AMBER only when there is concrete evidence that the deliverable may not be ready for its required gate.
  • Past due: If required evidence is still absent, normally use AMBER; use RED only when the missing evidence materially blocks a critical gate or project objective.
  • Required for a current/completed gate: Missing required evidence is a governance deficiency even if another date field is ambiguous.

When a Deliverables Register identifies expected file/evidence, use it to determine what the project requires, but interpret Status, DueDate, Gate, prerequisite actions, and related project evidence together. A Not Started or In Progress status for a future deliverable is not automatically a problem.

Example: a Support Handover due one month from now should not be reported as missing simply because the final handover document does not yet exist. A Security Review due in two weeks may warrant AMBER if project evidence shows that its review date is still unconfirmed and the scheduling action is nearly due.

RED
  • Missing or unreliable governance evidence materially prevents control of the project.
  • Required approval or governance documentation is absent for a critical project stage.

If required documentation cannot be determined, use UNKNOWN rather than inventing requirements.

Step 7: Determine Overall Project Health

Use the following precedence:

  1. RED if any area is RED and the condition materially threatens a key project objective, target date, compliance obligation, or major deliverable.
  2. Otherwise AMBER if any area is AMBER.
  3. Otherwise GREEN if all assessed areas are GREEN.
  4. Use UNKNOWN if evidence is too incomplete to support GREEN, AMBER, or RED with confidence.

Do not mark the overall project RED solely because one area is UNKNOWN.

Step 8: Generate Recommendations

Generate focused recommendations that follow directly from the findings.

Recommendations must:

  • Be actionable.
  • Name the affected milestone, risk, action, decision, or document when known.
  • Reuse explicit owners and due dates when available.
  • Never create fictional owners or dates.
  • Prioritize recovery and decision-making over generic project-management advice.

Step 9: Generate Standalone HTML Report

After completing and validating the Project Health Check, generate a standalone HTML webpage containing the final management report.

This is a presentation step only. The HTML report must represent the already completed and validated assessment. Do not recalculate, reinterpret, or change the health status while creating the webpage.

Show full SKILL.md (1,187 more words)Show less
Output behavior

When the user asks to generate, create, save, export, or provide the Project Health Check as an HTML report:

  1. Generate a complete standalone HTML5 document, not an HTML fragment.
  2. Create/save the result as an .html file when the execution environment provides a file-creation capability.
  3. Use a meaningful filename. Prefer: Project-Health-Check-[Project-Name]-[YYYY-MM-DD].html
  4. Replace characters that are unsafe for filenames with hyphens.
  5. If file creation is not available, return the complete standalone HTML document so it can be saved as an .html file without modification.
  6. Do not claim that a file was created or stored unless the environment actually created it.
  7. Do not silently overwrite an existing report unless the user explicitly requested replacement and the environment supports it.
Standalone webpage requirements

The generated file must be directly openable in a modern browser and must contain:

  • <!DOCTYPE html>
  • <html lang="...">
  • <head>
  • <meta charset="utf-8">
  • <meta name="viewport" content="width=device-width, initial-scale=1">
  • A meaningful <title>
  • Embedded CSS inside a <style> element
  • <body> containing the complete report

Do not require:

  • external CSS files
  • JavaScript
  • external fonts
  • external images
  • CDN resources
  • network access

The webpage must remain readable when opened locally or directly from a supported document location.

Report structure

Use this logical structure:

  1. Report header

    • Project name
    • Report title: Project Health Check
    • Reporting date
    • Overall GREEN / AMBER / RED / UNKNOWN status
    • One-sentence executive assessment

  2. Health Summary

    • Schedule & milestones
    • Risks & issues
    • Actions
    • Decisions & dependencies
    • Documentation & governance

  3. Key Findings

  4. Management Attention For each material item include, when known:

    • Item
    • Owner
    • Due date
    • Why it matters
    • Recommended next action

  5. Evidence and Coverage

    • Main sources used
    • Material evidence gaps
    • Assumptions or ambiguities
    • Confidence level

  6. Report footer

    • Project name
    • Reporting date
    • Statement that the report was generated from the SharePoint project evidence available to the current user
Visual design

Create a professional management-report layout using embedded CSS.

  • Use a centered content container with a sensible maximum width.
  • Use clear typography, spacing, headings, cards, and tables.
  • Make the overall project health visually prominent.
  • Show each health dimension with both its textual status and a visual status indicator.
  • GREEN, AMBER, RED, and UNKNOWN may use distinct visual styling, but never rely on color alone.
  • Keep sufficient contrast and make the report readable when printed.
  • Use responsive CSS so the page remains usable on smaller screens.
  • Allow tables to scroll horizontally on narrow screens if necessary.
  • Add print CSS where useful so the report can be printed or converted to PDF cleanly.
  • Do not add decorative elements that distract from management information.
HTML safety and correctness
  1. HTML-encode project-derived text before placing it into HTML.
  2. Do not insert executable project content as HTML, CSS, or JavaScript.
  3. Do not generate JavaScript.
  4. Do not invent hyperlinks to SharePoint content.
  5. If reliable source URLs are available from the execution environment and links are included, use only those actual URLs.
  6. Preserve citations/source references when the host environment supports them, but do not invent citation identifiers.
  7. Ensure opening and closing HTML tags are valid and balanced.
  8. The resulting document must be usable without further editing.
HTML skeleton

Use the following structure as guidance. Adapt content to the actual assessment.

html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Project Health Check - [Project Name] - [Reporting Date]</title>
  <style>
    /* Self-contained report styles */
  </style>
</head>
<body>
  <main class="report">
    <header>
      <p class="eyebrow">Project Health Check</p>
      <h1>[Project Name]</h1>
      <p>Reporting date: [Reporting Date]</p>
      <section class="overall-health">
        <h2>Overall Health: [STATUS]</h2>
        <p>[Executive assessment]</p>
      </section>
    </header>

    <section>
      <h2>Health Summary</h2>
      <!-- Five health dimensions -->
    </section>

    <section>
      <h2>Key Findings</h2>
      <ul>
        <!-- Evidence-based findings -->
      </ul>
    </section>

    <section>
      <h2>Management Attention</h2>
      <!-- Actionable management items -->
    </section>

    <section>
      <h2>Evidence and Coverage</h2>
      <!-- Sources, gaps, assumptions and confidence -->
    </section>

    <footer>
      <!-- Project, reporting date and evidence statement -->
    </footer>
  </main>
</body>
</html>
Default versus HTML mode

For a normal request such as:

Run the Project Health Check for Project Aurora.

return the concise interactive Project Health Check defined earlier in this skill.

For a request such as:

Run the Project Health Check for Project Aurora and create the final HTML report.

perform the same assessment, validate it, and then create the standalone HTML webpage.

For a follow-up such as:

Create the HTML report from this assessment.

reuse the validated assessment from the current conversation when it is clearly available and still applicable. Do not unnecessarily recalculate the project health unless the user asks for a refreshed assessment.

Rules

  1. Evidence first. Every material finding must be traceable to available SharePoint content.
  2. No fabricated facts. Never invent project status, percentages, dates, owners, risks, decisions, or required documents.
  3. Current over old. Prefer the newest authoritative source when versions conflict, but mention important contradictions.
  4. Status is not sentiment. Do not classify a project as healthy because narrative language is optimistic when structured evidence shows overdue or blocked work.
  5. Do not silently change project content. This skill performs assessment and reporting unless the user explicitly requests an allowed update.
  6. Respect permissions. Use only content available to the current user.
  7. Be concise. Management output should normally fit on one screen before the Evidence and Coverage section.
  8. Dates matter. Compare due dates against the reporting/current date before labeling anything overdue.
  9. Separate risk from issue. A risk is a possible future event; an issue is a condition that has already occurred.
  10. Signal uncertainty. If evidence is incomplete or contradictory, reduce confidence and say why.

Example

User request:

Run the Project Health Check for Project Aurora.

Example abbreviated result:

Project Health: AMBER

Delivery remains achievable, but an overdue integration milestone, two overdue actions, and an unresolved architecture decision require attention.

  • Schedule & milestones — AMBER: Integration testing started later than planned; recovery is still described as achievable.
  • Risks & issues — AMBER: One high integration risk remains open with mitigation in progress.
  • Actions — AMBER: Two material actions are overdue.
  • Decisions & dependencies — AMBER: Architecture decision D-014 is overdue and affects the deployment approach.
  • Documentation & governance — AMBER: Required deliverables are tracked. The Security Review requires attention because its review date is not yet confirmed and the related scheduling action is due soon. Other future deliverables remain within their planned delivery windows and are not treated as missing.
Management Attention
  • ADR-014 — Hosting model: overdue decision; resolve before deployment planning can be finalized.
  • A-023 — Test environment: overdue; environment readiness is required for integration testing.
Evidence and Coverage

Primary evidence: latest status report, milestone plan, risk register, action register, decision register, and deliverables register. Confidence: High.

Validation Checklist

Before returning the assessment, verify:

  • The reporting/current date was used consistently for overdue checks.
  • Every RED or AMBER conclusion is supported by evidence.
  • No owner, date, percentage, or project fact was invented.
  • Missing documentation was identified only from an explicit requirement or checklist.
  • Contradictory sources were called out.
  • Management attention contains only material items.
  • The overall RAG status follows the precedence rules.
  • Current overdue days and forecast variance are not confused.
  • Items due today are not called overdue.
  • Every explicitly required deliverable was evaluated against its due date, gate, status, prerequisites, and current project phase.
  • Future required artifacts are not treated as deficiencies solely because final evidence does not yet exist.
  • A future deliverable is marked AMBER only when concrete evidence indicates preparation, scheduling, prerequisites, ownership, or delivery is at risk.
  • Unrequired source types are not reported as coverage gaps merely because they are common project artifacts.
  • Evidence coverage and confidence are stated.
  • If standalone HTML was requested, the HTML contains DOCTYPE, html, head, embedded CSS, and body.
  • The HTML report contains the same validated RAG assessment as the analysis.
  • Project-derived content is safely HTML-encoded.
  • The HTML has no external runtime dependencies and can be opened as a standalone webpage.
  • A created file is only claimed when file creation actually succeeded.

© pnp, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in Skills/project-health-check/project-health-check of pnp/sharepoint-skills.

Open the folder on GitHubat commit 69712d2

Compare with similar skills

Project Health Check next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Project Health Check compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Project Health Check this skillpnp/sharepoint-skills133—~5.6kAutomated safety check: PassMIT
Implementing Data Loss Prevention With Microsoft Purviewmukul975/Anthropic-Cybersecurity-Skills34k—~7.9kAutomated safety check: PassApache-2.0
Colleague DistillationZhixiangLuo/10xProductivity479—~2.1kAutomated safety check: NotesMIT
Msgraphcodemie-ai/codemie-code294—~4.1kAutomated safety check: PassApache-2.0
aai-cli Microsoft 365aai-labs/agent-barn109—~1.2kAutomated safety check: PassApache-2.0
Workiqmicrosoft/work-iq1k—~15kAutomated safety check: PassCustom licence

Similar skills

  • Implementing Data Loss Prevention With Microsoft Purview

    mukul975/Anthropic-Cybersecurity-Skills

    Implements DLP policies using Microsoft Purview PowerShell cmdlets and the Graph API to protect data across Exchange Online, SharePoint, OneDrive, Teams, endpoints, and Power BI, including…

    34k GitHub stars~7.9k tokensUpdated 1 mo ago
    Documents & OfficeAuto-check passed

  • Colleague Distillation

    ZhixiangLuo/10xProductivity

    Distill a colleague into a reusable AI skill (work + persona) using tool connections — Slack, Slack AI, Jira, GHE, Bitbucket, Confluence, SharePoint, Teams, Outlook, Notion, Linear, Google Docs, and…

    479 GitHub stars~2.1k tokensUpdated 3 mo ago
    Documents & OfficeAuto-check: notes

  • Msgraph

    codemie-ai/codemie-code

    Work with Microsoft 365 services via the Graph API — emails, calendar events, SharePoint sites (read and write), Teams chats and channel messages, OneDrive files, OneNote notebooks, Planner task…

    294 GitHub stars~4.1k tokensUpdated yesterday
    Documents & OfficeAuto-check passed

  • aai-cli Microsoft 365

    aai-labs/agent-barn

    Guides work with Outlook, OneDrive, SharePoint, Teams, Excel, To Do and Planner through aai-cli's Microsoft Graph commands, starting from which service owns the data.

    109 GitHub stars~1.2k tokensUpdated yesterday
    Documents & OfficeAuto-check passed

  • Workiq

    microsoft/work-iq

    Official

    WorkIQ tools for Microsoft 365 workplace data and actions. An agent skill from microsoft/work-iq.

    1k GitHub stars~15k tokensUpdated yesterday
    Documents & OfficeAuto-check passed

  • Workiq Preview

    microsoft/work-iq

    Official

    WorkIQ tools for Microsoft 365 workplace data and actions. An agent skill from microsoft/work-iq.

    1k GitHub stars~3.3k tokensUpdated yesterday
    Documents & OfficeAuto-check passed

More from pnp/sharepoint-skills

All 52 skills in this repo

  • Scorecard Matrix

    pnp/sharepoint-skills

    Generates a polished, self-contained HTML heatmap scorecard — a weighted comparison matrix where entities (rows) are scored across dimensions (columns), with computed totals, rank badges, and a…

    133 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed

  • Analyze Document Library

    pnp/sharepoint-skills

    Analyze the current SharePoint document library in read-only mode and produce a structured summary of files, folders, file types, recent activity, naming issues, and organization recommendations.

    133 GitHub stars~899 tokensUpdated yesterday
    Auto-check passed

  • Broken Link Auditor

    pnp/sharepoint-skills

    Audits SharePoint pages, news posts, and hyperlink fields for broken or risky links and saves a self-contained HTML link-health report to the site.

    133 GitHub stars~2.5k tokensUpdated yesterday
    Auto-check passed

  • Custom Image Tagger

    pnp/sharepoint-skills

    Analyze selected construction images, create missing object metadata columns, and write concise visual metadata back to SharePoint columns using explicit image-analysis, list-schema, list-update…

    133 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed

  • Dossier

    pnp/sharepoint-skills

    Renders a polished, self-contained HTML briefing from any data source — SharePoint lists, uploaded documents, or a verbal description.

    133 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed

  • Exec Report

    pnp/sharepoint-skills

    Generates a polished, self-contained HTML executive report or dashboard from any data source — SharePoint lists, CSV exports, or a user description.

    133 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Project Health Check

What does Project Health Check do?

Analyze SharePoint project content and project lists to produce a concise project health assessment covering schedule, risks, actions, decisions, and documentation. Project Health Check is an agent skill from pnp/sharepoint-skills. Analyze SharePoint project content and project lists to produce a concise project health assessment covering schedule, risks, actions, decisions, and documentation.

When should I use Project Health Check?

Project Health Check fits situations like: the user asks for a project health check; project status assessment; management health summary.

How do I install Project Health Check in Claude Code?

Run `npx skills add pnp/sharepoint-skills --skill project-health-check -a claude-code`. Or copy the skill folder (Skills/project-health-check/project-health-check in pnp/sharepoint-skills) into .claude/skills/project-health-check in your project. Claude Code loads it when a task matches its description.

How do I install Project Health Check in Codex?

Run `npx skills add pnp/sharepoint-skills --skill project-health-check -a codex`. Or copy the skill folder (Skills/project-health-check/project-health-check in pnp/sharepoint-skills) into .agents/skills/project-health-check in your project. Codex loads it when a task matches its description.

Can I use Project Health Check in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add pnp/sharepoint-skills --skill project-health-check -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/project-health-check, .gemini/skills/project-health-check, .github/skills/project-health-check and .opencode/skills/project-health-check in your project.

What does Project Health Check need to run?

SKILL.md names no scripts, command-line tools or credentials: Project Health Check is instructions for the agent only.

Does Project Health Check access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Project Health Check safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Project Health Check use?

Project Health Check is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Project Health Check use?

About 5.6k tokens (SKILL.md is roughly 22k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Project Health Check?

Skills that share tags, products or a category with Project Health Check: Implementing Data Loss Prevention With Microsoft Purview (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Colleague Distillation (ZhixiangLuo/10xProductivity, 479 stars), Msgraph (codemie-ai/codemie-code, 294 stars) and aai-cli Microsoft 365 (aai-labs/agent-barn, 109 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Project Health Check?

pnp (a GitHub organization) maintains it in pnp/sharepoint-skills, which has 133 GitHub stars. The repository holds 52 skills in this directory. The repository was last updated on October 9, 2026.

Source: pnp/sharepoint-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.