Menu

Individual skill

weekly-ops-report

Turn raw operational data into a weekly management report that answers exactly three questions - what changed, where is it concentrated, what needs a decision. Use when the user mentions weekly report, haftalık rapor, yönetim raporu, ops review, KPI summary, or asks to summarize operational data for managers. Differentiator - contract-first reporting with plain-language findings and driver decomposition, never a chart dump.

skills-imported/weekly-ops-report/SKILL.md

Read pinned source

Source commit faf37c0859ebf627bfcb5225e8057d088691e0ae

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
Yes
Observed behavior
Not checked yet
Last checked
Nov 8, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
53
Repository last updated
Oct 10, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Weekly Ops Report

A weekly report is a contract: *what changed, where is it concentrated, what needs a decision.* Anything that does not serve one of those three questions is decoration and gets cut.

## Workflow

1. **Data-quality gate first.** Before any KPI: duplicated rows, missing calendar days, impossible values (negative quantities, dates out of range). Fix what is safe to fix, and report every finding in a footer - an unattended report must audit its own inputs.
2. **Compute the KPI set** agreed for the audience (typical core: revenue/volume, service level, stock cover; keep it under ~6). For each: this week, vs last week, and vs the trailing 8-week average. The baseline comparison prevents one unusual prior week from faking a trend.
3. **Apply movement thresholds.** Only movements beyond agreed thresholds (state defaults, e.g. |revenue| >= 5%, |service| >= 1.5 pts) become findings. Reporting every wiggle trains readers to ignore the report.
4. **Decompose every finding.** A movement without its driver is not a finding. Break the moved metric by its main dimension (region, carrier, category...) and name the concentrated segment with its share of the move.
5. **Write findings as sentences**, one line each, using: *METRIC moved X (vs baseline) - DRIVER is the main contributor (Y, ~Z% of the move) - SUGGESTED NEXT STEP.* Tag each finding positive / negative / warning. Maximum five findings; if more qualify, keep the five largest by impact.
6. **Assemble in fixed order:** headline KPI cards, findings list, trend view (13 weeks), attention lists (e.g. low-cover SKUs), data-quality footer. Same structure every week - familiarity is what makes deltas visible.
7. **Validate before delivering.** Recompute one headline KPI directly from raw rows and match it against the report value. If automation is involved, this check runs inside the pipeline, not in someone's head.