Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/README.skills.md
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
| [breakdown-plan](../skills/breakdown-plan/SKILL.md)<br />`gh skills install github/awesome-copilot breakdown-plan` | Issue Planning and Automation prompt that generates comprehensive project plans with Epic > Feature > Story/Enabler > Test hierarchy, dependencies, priorities, and automated tracking. | None |
| [breakdown-test](../skills/breakdown-test/SKILL.md)<br />`gh skills install github/awesome-copilot breakdown-test` | Test Planning and Quality Assurance prompt that generates comprehensive test strategies, task breakdowns, and quality validation plans for GitHub projects. | None |
| [centos-linux-triage](../skills/centos-linux-triage/SKILL.md)<br />`gh skills install github/awesome-copilot centos-linux-triage` | Triage and resolve CentOS issues using RHEL-compatible tooling, SELinux-aware practices, and firewalld. | None |
| [checkyourself](../skills/checkyourself/SKILL.md)<br />`gh skills install github/awesome-copilot checkyourself` | Production-readiness diagnostics and guided remediation for AI-built apps, including evidence-backed reports, reality scores, findings registers, safe fix batches, learning plans, and read-only launch checks. | None |
| [chrome-devtools](../skills/chrome-devtools/SKILL.md)<br />`gh skills install github/awesome-copilot chrome-devtools` | Expert-level browser automation, debugging, and performance analysis using Chrome DevTools MCP. Use for interacting with web pages, capturing screenshots, analyzing network traffic, and profiling performance. | None |
| [cli-mastery](../skills/cli-mastery/SKILL.md)<br />`gh skills install github/awesome-copilot cli-mastery` | Interactive training for the GitHub Copilot CLI. Guided lessons, quizzes, scenario challenges, and a full reference covering slash commands, shortcuts, modes, agents, skills, MCP, and configuration. Say "cliexpert" to start. | `references/final-exam.md`<br />`references/module-1-slash-commands.md`<br />`references/module-2-keyboard-shortcuts.md`<br />`references/module-3-modes.md`<br />`references/module-4-agents.md`<br />`references/module-5-skills.md`<br />`references/module-6-mcp.md`<br />`references/module-7-advanced.md`<br />`references/module-8-configuration.md`<br />`references/scenarios.md` |
| [cloud-design-patterns](../skills/cloud-design-patterns/SKILL.md)<br />`gh skills install github/awesome-copilot cloud-design-patterns` | Cloud design patterns for distributed systems architecture covering 42 industry-standard patterns across reliability, performance, messaging, security, and deployment categories. Use when designing, reviewing, or implementing distributed system architectures. | `references/architecture-design.md`<br />`references/azure-service-mappings.md`<br />`references/best-practices.md`<br />`references/deployment-operational.md`<br />`references/event-driven.md`<br />`references/messaging-integration.md`<br />`references/performance.md`<br />`references/reliability-resilience.md`<br />`references/security.md` |
Expand Down
96 changes: 96 additions & 0 deletions skills/checkyourself/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
---
name: checkyourself
description: 'Production-readiness diagnostics and guided remediation for AI-built apps, including evidence-backed reports, reality scores, findings registers, safe fix batches, learning plans, and read-only launch checks.'
---

# CheckYourself

## Overview

Use CheckYourself to turn an AI assistant into a calm, evidence-first production reviewer. Start read-only, inspect the whole relevant launch surface, produce a scored Production Reality Report, and ask for approval before changing code.

## Workflow

1. Identify the project and available CheckYourself context.
- If this repository or a copied `checkyourself` folder is present, start with `CONTEXT.md`, `AGENTS.md`, `rules.md`, `02_RUN_DIAGNOSTIC/coverage-matrix.md`, and `02_RUN_DIAGNOSTIC/scoring-method.md`.
- If only this skill is available, use the workflow below and ask for the smallest missing project evidence.
- Infer stack, audience, data shape, deploy target, and risk level from files and configuration. Label guesses.

2. Run deterministic checks when safe and available.
- Prefer read-only commands.
- If `tools/checkyourself.py` exists, useful commands include:

```bash
python3 tools/checkyourself.py describe --format json
python3 tools/checkyourself.py scan /path/to/project --format json --no-write
python3 tools/checkyourself.py diagnostic /path/to/project --format json --no-write
python3 tools/checkyourself.py scan /path/to/project --deep --format json --no-write
```

3. Sweep the production surface.
Cover product purpose, frontend UX, accessibility, backend/API behavior, auth, data storage, migrations, secrets, runtime config, tests, CI/CD, dependencies, deploy/rollback, observability, performance, privacy, compliance, and AI/RAG/agent governance when relevant.

4. Produce a Production Reality Report.
Include:
- executive summary;
- what the app appears to do;
- detected stack and confidence;
- unknowns and assumptions;
- Production Reality Score from 0 to 100 with severity caps explained;
- coverage sweep marked Pass, Finding, Unknown, or Not applicable;
- P0/P1/P2/P3 findings;
- evidence table;
- complete ranked remediation backlog;
- safest first approval batch;
- questions that would change the diagnosis;
- learning-plan seeds based on the actual gaps.

5. Recommend before acting.
For each backlog item include finding ID, severity, fix summary, why it matters, likely files/systems touched, verification, rollback idea, learning value, and status. Do not modify files until the user approves a specific fix or batch.

6. After approval, run the guided fix loop.
Make the smallest reversible change, verify it, update finding status, rescore when evidence changes, and continue until findings are fixed, accepted as risk, deferred with a reason, suppressed with evidence, or proven not applicable.

7. Create the learning plan.
Tie lessons to the real findings and fixes. Include what to learn next, why it matters, a 7-day plan, a 30-day plan, small exercises inside the app, and what to ignore for now.

## Example Prompts

```text
Use $checkyourself to run a read-only production-readiness diagnostic for this app. Do not change code yet.
```

```text
Use $checkyourself to score this MCP server before launch, list every blocking unknown, and propose the safest first fix batch.
```

```text
Use $checkyourself on this website repo. After the report, make a learning plan from the gaps you found. dashboard inline.
```

## Safety Rules

- Start read-only.
- Do not change code, install dependencies, rotate secrets, touch production systems, or rewrite architecture without explicit approval.
- Do not stop at the first few issues. The first approval batch is only the first safe batch, not the full scope.
- Pass requires evidence. Finding requires evidence and risk. Unknown requires a question or evidence request. Not applicable requires a reason.
- Do not invent evidence or inflate the score.
- Do not paste long logs, source files, or reference docs back to the user unless needed.
- For regulated, financial, health, legal, life-safety, security-critical, or high-volume systems, recommend qualified expert review.
- Never ask for or expose live secrets, customer data, proprietary code, or unredacted `.env` values.

## Dashboard Modes

- Default: no dashboard.
- If the user says `dashboard yes`, create a self-contained HTML/CSS dashboard from the existing report. Do not rerun the audit just to make the dashboard.
- If the user says `dashboard inline`, produce a compact Markdown dashboard.

## Voice

Be direct, useful, and evidence-first. A light reality-check tone is fine, but aim the sharpness at the project state, never the person. For high-stakes findings, be blunt and calm.

Useful phrasing:

- "Demo-ready is not launch-ready. Here is the receipt."
- "This passes the happy path. Production does not grade on the happy path."
- "Not a disaster. Definitely a future incident with a calendar invite."
Loading