weekly-report

name

weekly-report

description

One-shot orchestrator that produces complete manager-adapted reports from the current git repository. Installed once per project, it reads the project's .useless-report/config.yml to know which manager profiles to generate for — no questions asked on repeat runs. Supports multiple managers: one run generates one report per saved profile. Ingests git activity, GitHub PRs, and ticket references. Renders to markdown, HTML, email, and/or slides using the project's DESIGN.md brand tokens. Use this skill when the user asks "generate my weekly report", "status update for my boss", or any one-shot report request from inside a git repo.

weekly-report

Goal

Run the entire useless-report pipeline end-to-end from inside the user's project. The skill is installed once per project and remembers everything: manager profiles, output formats, report period, brand identity. On repeat runs, one command → all reports generated, nothing to answer.

One command. Real data. Every manager covered. Nothing to answer twice.

Project configuration file

The skill reads .useless-report/config.yml at the root of the current project. This file is the source of truth for all defaults.

Structure:

# .useless-report/config.yml
# Generated by useless-report — edit freely

period: 7d          # default reporting period: 7d, 14d, sprint, month

# Profil de l'utilisateur — comment TU communiques
user:
  name: "[Ton prénom]"
  role: "[Ton titre]"
  style: assertive          # assertive | diplomatic | data-driven | storyteller | minimalist
  tone: confident           # confident | humble | collaborative | direct
  strengths:
    - "delivery track record"
    - "technical depth"
  modes:
    status_update: "data-first, let numbers speak"
    pitch:         "hook → problem → solution → ask"
    bad_news:      "solution-first, context second, timeline always"
    escalation:    "ask-first, urgency clear, specific action"

managers:
  - name: "Alice"                     # libre — used in filenames and summaries
    profile: control_oriented         # archetype (see list below)
    notes: "Veut des options et de la traçabilité. Déteste les surprises."
    formats: [html, email, qa]        # formats à générer pour ce manager

  - name: "Bob"
    profile: risk_sensitive
    notes: "Focus risques, délais, budget. Bulletpoints uniquement."
    formats: [slides, call_prep]

  # Ajouter autant de managers que nécessaire

Profils disponibles : control_oriented · risk_sensitive · process_heavy · stakeholder_oriented · low_context · volatile_priority · deadline_reactive · quality_maximalist · ambiguity_tolerant · synchronous_first

Formats disponibles : markdown · html · email · slides

Si le fichier n'existe pas, le skill le crée à la première exécution (voir Step 1).

How to use

Step 1 — Charger la config projet + vérifier le persona utilisateur

Chercher .useless-report/config.yml à la racine du projet courant.

Si présent : charger silencieusement. Ne poser aucune question — tout est déjà configuré.

Si absent : c'est la première exécution. Poser ces questions une seule fois :

1. Période par défaut (default: 7d)
2. Profil utilisateur (une fois pour toutes) :
   • Nom, rôle, style de communication (assertive / diplomatic / data-driven / storyteller / minimalist)
3. Combien de managers ? → pour chacun :
   • Nom (libre)
   • Profil archétype — si inconnu, proposer useless-report:classify-manager-style
   • Formats souhaités (html, email, slides, qa, call_prep)
   • Notes optionnelles sur ses préférences
4. Format de sortie global si pas spécifié par manager

Puis créer .useless-report/config.yml et confirmer : "Config sauvegardée → .useless-report/config.yml. Les prochaines exécutions seront silencieuses."

Step 1b — Historique (automatique)

Invoquer useless-report:track-history en mode silencieux :

• Charger les requêtes ouvertes du manager depuis le run précédent
• Préparer le delta (what changed since last time)
• Ces données s'injectent dans le rapport généré à l'étape 4

Step 2 — Ingérer le codebase

Lire le projet courant — c'est la source de vérité unique :

1. useless-report:ingest-from-git — toujours, c'est la base. Commits du projet sur la période configurée.
2. useless-report:ingest-from-github — si le repo a un remote GitHub et que gh est authentifié.
3. useless-report:ingest-from-tickets — si des commits contiennent des IDs de tickets (JIRA, Linear, GitHub Issues).

Combiner en une base de faits unique. Ne jamais inventer — si une source est inaccessible, le noter dans le rapport.

Step 3 — Charger la charte visuelle

Chercher ./DESIGN.md à la racine.

• Présent → les formats l'utilisent automatiquement. Rien à faire.
• Absent → proposer une seule fois : "DESIGN.md introuvable — veux-tu générer la charte de ta boîte ? (URL, CSS, screenshot, ou Entrée pour un design générique)"
  • Si oui → useless-report:generate-design
  • Si non → design générique appliqué automatiquement

Step 4 — Générer les rapports

Pour chaque manager dans config.yml, dans l'ordre :

1. Invoquer le skill generate-* correspondant à son profil avec la base de faits :

Profile	Skill
control_oriented	useless-report:generate-control-report
risk_sensitive	useless-report:generate-risk-report
process_heavy	useless-report:generate-process-report
stakeholder_oriented	useless-report:generate-stakeholder-brief
low_context	useless-report:generate-low-context-digest
volatile_priority	useless-report:generate-volatile-priority-update
deadline_reactive	useless-report:generate-deadline-reactive-update
quality_maximalist	useless-report:generate-quality-maximalist-report
ambiguity_tolerant	useless-report:generate-ambiguity-tolerant-update
synchronous_first	useless-report:generate-synchronous-first-update

2. Pour chaque format demandé dans manager.formats, invoquer le skill correspondant sur le markdown généré :

   • html → useless-report:format-as-html
   • email → useless-report:format-as-email
   • slides → useless-report:format-as-slides
   • qa → useless-report:format-as-qa
   • call_prep → useless-report:format-as-call-prep

3. Après chaque rapport généré, invoquer useless-report:track-history pour sauvegarder le snapshot et mettre à jour les requêtes ouvertes du manager.

Convention de nommage des fichiers :

./useless-report/[YYYY-MM-DD]/[manager-name]-[profile].[ext]

Exemples :
  useless-report/2026-05-01/alice-control.html
  useless-report/2026-05-01/alice-control-email.html
  useless-report/2026-05-01/bob-risk-deck.md
  useless-report/2026-05-01/bob-risk-deck.pdf   ← si marp disponible

Créer le dossier ./useless-report/[date]/ automatiquement s'il n'existe pas.

Step 5 — Résumé final

Afficher :

✓ Ingestion : [N] commits · [N] PRs · [N] tickets · période [période]
✓ Charte : [DESIGN.md trouvé / design générique]

Rapports générés :
  Alice (control_oriented)
    → useless-report/2026-05-01/alice-control.html
    → useless-report/2026-05-01/alice-control-email.html
  Bob (risk_sensitive)
    → useless-report/2026-05-01/bob-risk-deck.md

Prochaine exécution : /useless-report:weekly-report  (aucune question)

Exemple de flux complet (2 managers, 2e exécution)

/useless-report:weekly-report

→ Config chargée depuis .useless-report/config.yml (2 managers)
→ git log --since=7days → 23 commits
→ gh pr list → 5 PRs merged
→ Tickets extraits : AUTH-201, AUTH-202, BILL-89
→ DESIGN.md trouvé → charte Stripe appliquée
→ Génération Alice (control_oriented) → HTML + email
→ Génération Bob (risk_sensitive) → slides Marp
→ 3 fichiers sauvegardés dans useless-report/2026-05-01/

Rules

• Ne jamais inventer de faits. Tout vient du codebase. Si une source est indisponible, le noter.
• Silencieux par défaut sur les runs suivants — la config répond à tout.
• Un dossier par date — ne pas écraser les rapports précédents.
• Respecter les formats par manager — Alice et Bob n'ont pas forcément les mêmes besoins.
• Signaler gracieusement si gh n'est pas auth ou si marp n'est pas installé — continuer sans bloquer.