Report Revisions Agent Skill
List APIView revisions created or actually opened/viewed in a date range, broken out by language and type. Use for: created revisions, opened revisions, viewed revisions, revision counts, how many revisions, revisions for March, revision breakdown, revision types, automatic vs manual revisions, PR revisions, pull request revisions, page views, actually viewed, who opened reviews, opened revision breakdown.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/Azure/azure-sdk-tools --skill report-revisionsThe instruction itself
12 sections, as written by the authorReport Revisions
Two commands for counting APIView revisions by language and type:
| Command | What it counts | Data source |
|---------|---------------|-------------|
| list-created-revisions | Revisions created in the date window | Cosmos DB |
| list-opened-revisions | Revisions actually opened/viewed by users | Application Insights + Cosmos DB |
Choose the right command based on the user's intent. If they ask about "created" or "how many revisions", use list-created-revisions. If they ask about "opened", "viewed", "actually looked at", or "page views", use list-opened-revisions.
By default, list-opened-revisions counts all revisions belonging to viewed reviews regardless of when those revisions were created. If the user wants to limit to revisions created within the window (e.g. to pair with list-created-revisions), add --created-in-window.
Defaults
Unless the user says otherwise, always apply these defaults:
- Environment:
production - Exclude: Do NOT pass
--excludeunless the user explicitly asks to omit languages
Date Resolution
The user will typically specify a calendar month by name (e.g. "March", "January 2025"). Resolve to the full month date range:
| User says | start_date | end_date |
|-----------|-----------|----------|
| "March" (current year) | YYYY-03-01 | YYYY-03-31 |
| "January 2025" | 2025-01-01 | 2025-01-31 |
| "March 1 to March 15" | YYYY-03-01 | YYYY-03-15 |
When only a month name is given without a year, use the current year. Be careful with month lengths (28/29/30/31 days).
> Note: list-opened-revisions queries Application Insights, which has a default retention of 90 days. Queries beyond that window may return incomplete data.
Running the Command
Step 1: Run the Command
Show the resolved command and run it immediately in a foreground terminal with a 120-second timeout (timeout: 120000). Always redirect output to a file so follow-up questions can be answered without re-querying.
Created revisions
New-Item -ItemType Directory -Path output -Force | Out-Null; if (Test-Path output/created_revisions_output.txt) { Remove-Item output/created_revisions_output.txt }; python cli.py apiview list-created-revisions -s <start_date> -e <end_date> 2>&1 | Out-File -Encoding UTF8 output/created_revisions_output.txt
Output file: output/created_revisions_output.txt
Opened revisions
New-Item -ItemType Directory -Path output -Force | Out-Null; if (Test-Path output/opened_revisions_output.txt) { Remove-Item output/opened_revisions_output.txt }; python cli.py apiview list-opened-revisions -s <start_date> -e <end_date> 2>&1 | Out-File -Encoding UTF8 output/opened_revisions_output.txt
Output file: output/opened_revisions_output.txt
With --exclude
Append --exclude Java Go (or whatever languages) to either command.
After the command completes, read the output file with read_file to get the results. Summarize the findings for the user.
Step 2: Answer Follow-up Questions
For follow-up questions about the same data, read the output file instead of re-running the command.
Examples
# Created revisions for March 2026
python cli.py apiview list-created-revisions -s 2026-03-01 -e 2026-03-31
# Opened revisions for March 2026
python cli.py apiview list-opened-revisions -s 2026-03-01 -e 2026-03-31
# Exclude Java and Go
python cli.py apiview list-created-revisions -s 2026-03-01 -e 2026-03-31 --exclude Java Go
python cli.py apiview list-opened-revisions -s 2026-03-01 -e 2026-03-31 --exclude Java Go
# Staging environment
python cli.py apiview list-created-revisions -s 2026-03-01 -e 2026-03-31 --environment staging
Available Flags (same for both commands)
| Flag | Type | Default | Description |
|------|------|---------|-------------|
| --start-date / -s | string | required | Start date (YYYY-MM-DD) |
| --end-date / -e | string | required | End date (YYYY-MM-DD) |
| --environment | string | production | production or staging |
| --exclude | string(s) | None | Languages to exclude (e.g., --exclude Java Go) |
Output Format
Both commands print a table with one row per language and one column per revision type (Automatic, Manual, PullRequest). Each type cell shows the count and its percentage of that column's total. The Total column shows the language's count and its percentage of the grand total.
Other skills for the same job
different authors, same section of the catalogue
> Generate a Markdown triage report for open, non-draft pull requests in microsoft/ebpf-for-windows, including CI, freshness, sign-offs, and next-owner routing.
Self-heal + report bugs to make the ecosystem better. When you hit ANY defect in comfyui-mcp / the sidebar panel, OR in a third-party custom node / ComfyUI core, use this: diagnose it, and for OUR repos (comfyui-mcp / comfyui-mcp-panel) **fix it locally FIRST** — patch the code where it actually runs so the user is unblocked immediately — then file a report that includes the diff, so reports arrive as near-PRs, not just tickets. (Attempt the fix exactly ONCE; if it's genuinely upstream-only, mark it and include the precise change needed.) Report it the right way: our intake Worker for our repos; the node's own GitHub for third-party. For OUR repos (artokun/comfyui-mcp, comfyui-mcp-panel, comfyui-mcp-issue-worker) act **autonomously** — fix-then-file and just inform the user, no per-step permission. For THIRD-PARTY / ComfyUI-core it is **offer-and-ask**: propose the workaround/report and act only with the user's go-ahead. **BETA — bias HARD toward fix-then-file (our repos):** trigger on any comfyui-mcp/panel defect you notice — an error, a crash, a tool that returns wrong/misleading/empty output, a silent failure, a confusing result, or a limitation that forced an awkward workaround — EVEN IF you recovered or worked around it. You do NOT need to be blocked. Also on "report this" / "fix this bug". If a future user would hit the same friction, fix-and-file it — the intake Worker dedupes, so over-reporting is cheap and under-reporting costs us the bug. THIRD-PARTY / ComfyUI-core bugs stay offer-and-ask.
> Scan codebases for technical debt with AST parsing, prioritize by impact, and generate trend dashboards. Use when tracking tech debt, prioritizing refactoring, calculating cost-of- delay, planning sprint debt, or reporting debt to execs.
This skill should be used when designing, running, validating, or auditing statistical experiments on personal or observational time-series data (health metrics, speech/text corpora, behavioral logs, diaries, n-of-1 self-tracking). It enforces pre-registration, exact permutation tests, FDR discipline, data-validation gates, adversarial code review, and cross-validation with external models. Triggers on "design an experiment", "test this hypothesis on my data", "is this correlation real", "audit these findings", "pre-register", "validate this dataset", or any n-of-1 / quantified-self analysis request.
Load when an existing Web product, especially a dashboard, dense-data view, or multi-step app, needs a deep evidence-backed experience review; report findings only, and use design-taste-frontend for marketing-page direction, code-review for source diffs, web-design-guidelines for checklist compliance, or frontend-design for implementation.
> Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Includes tech debt analyzer, team scaling calculator, engineering metrics frameworks, technology evaluation tools, and ADR templates. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.
OpenTelemetry Weaver registry authoring, codegen, and CI enforcement. Use when adopting Weaver, authoring or reviewing a registry (manifest, attributes, metrics, spans, events), writing Jinja2 templates against the resolved schema, migrating hand-maintained telemetry constants, or wiring `weaver registry check`/`generate`/`diff` into CI.
> Query GitHub repository activity (PRs, issues) for a date range using the gh CLI. Use this skill whenever you need to fetch pull request or issue data from a GitHub repository, compute statistics like counts, merge times, or identify top contributors. Triggers on tasks involving GitHub activity reports, community pulse summaries, or repository metrics gathering.
How to use it
Take azure/report-revisions from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.