Generalize weekly-dev-report for mixed-role teams and rework rating

[ydesgagn]

Summary

Reworks the weekly-dev-report skill so it accurately covers teams that mix engineers, QA, content, and consultants — not just developers. The rating model is rebuilt around per-working-day PR throughput (the team's working baseline with AI assistance) instead of story-point burndown, and the report grows three new sections that were missing in the previous version (cycle time, daily worklog breakdown, and Jira ↔ GitHub release reconciliation).

Key changes:

• Renames the report from "Weekly Developer Report" to "Weekly Activity Report" and switches all member-facing language to generic terms ("team member", "contributor") so non-engineers aren't mislabelled.
• Adds a weekly-anchor sprint concept: when the previous Mon→Sun window falls entirely outside the active sprint (fresh sprint), fall back to the previous closed sprint for weekly metrics rather than emitting an empty report. Sprint-to-date metrics still target the active sprint.
• Replaces the SP-burndown rating with a PR-per-working-day rating: 🟢 ≥ 1 PR/day, 🟡 ≥ 0.5/day, 🔴 < 0.5/day or stalled. PR credit goes to the author of the PR, never the merger.
• Adds worklog flags that cap a member at 🟡: any working day < 7h, or every entry sharing the same start-time + duration (clock-in pattern signal).
• Adds a per-member daily time-logged table (Mon–Sun columns + Total + Flags + Jira logged), with a 28-day no-entries roster filter so consultants who don't log to Jira are silently dropped from the time table (still rated on PRs).
• Adds cycle time per ticket (In Progress → Code Review) as a new column on the team-at-a-glance table, plus a Tickets/day column.
• Adds a new Releases this week section that reconciles Jira released==true versions against GitHub tags/releases in the same window and surfaces mismatches.
• Adds an inclusion filter for the throughput table: drops roster members with zero transitions AND zero authored-merged PRs in the week (still surfaced in Time-logged or Stalled sections if applicable), and notes the dropped count in the header.
• Tightens Jira citation rule: every Jira reference must render as [KEY](.../browse/KEY) — short summary, never a bare key.
• Adds a "no skill / process meta-commentary in the rendered report" rule so the output stays a status report, not a changelog of the skill.

Types of changes

• Bugfix (fixes an issue)
• New feature (adds functionality)
• Refactoring (improves code without changing functionality)
• Breaking change (incompatible changes)
• Build or security update (updates dependencies, libraries, or security patches)
• Code style or documentation update (formatting, renaming, or documentation changes)
• Other (please describe):

Checklist

• Unit tests added to validate my fix/feature
• I have manually tested my change
• I did not add automation test. Why ?: This is a skill spec (markdown only) — behavior is exercised by running the skill against the live Jira/GitHub data, not by unit tests.
• Database changes requiring migration with downtime or reprocessing of existing data
• The SOUP file lists the risk Level, requirements and verification reasoning associated with each library
• readme.md includes sections on introduction, installation, usage, and contributing
• docs/architecture.md includes sections on the architecture diagram, software units, software of unknown provenance, critical algorithms and risk controls related to PII and security
• Impact on PII, privacy regulations (CCPA/GDPR/PIPEDA), CIS benchmarks or security (availability/confidentiality/integrity); management must be notified