@hasna/terminal 2.3.0 → 2.3.1

package/temp/rtk/.claude/skills/pr-triage/SKILL.md

@@ -1,315 +0,0 @@
----
-description: >
-  PR triage: audit open PRs, deep review selected ones, draft and post review comments.
-  Args: "all" to review all, PR numbers to focus (e.g. "42 57"), "en"/"fr" for language, no arg = audit only in French.
----
-
-# PR Triage
-
-## Quand utiliser
-
-| Skill | Usage | Output |
-|-------|-------|--------|
-| `/pr-triage` | Trier, reviewer, commenter les PRs | Tableau d'action + reviews + commentaires postés |
-| `/repo-recap` | Récap général pour partager avec l'équipe | Résumé Markdown (PRs + issues + releases) |
-
-**Déclencheurs** :
-- Manuellement : `/pr-triage` ou `/pr-triage all` ou `/pr-triage 42 57`
-- Proactivement : quand >5 PRs ouvertes sans review, ou PR stale >14j détectée
-
----
-
-## Langue
-
-- Vérifier l'argument passé au skill
-- Si `en` ou `english` → tableaux et résumé en anglais
-- Si `fr`, `french`, ou pas d'argument → français (défaut)
-- Note : les commentaires GitHub (Phase 3) restent TOUJOURS en anglais (audience internationale)
-
----
-
-Workflow en 3 phases : audit automatique → deep review opt-in → commentaires avec validation obligatoire.
-
-## Préconditions
-
-```bash
-git rev-parse --is-inside-work-tree
-gh auth status
-```
-
-Si l'un échoue, stop et expliquer ce qui manque.
-
----
-
-## Phase 1 — Audit (toujours exécutée)
-
-### Data Gathering (commandes en parallèle)
-
-```bash
-# Identité du repo
-gh repo view --json nameWithOwner -q .nameWithOwner
-
-# PRs ouvertes avec métadonnées complètes (ajouter body pour cross-référence issues)
-gh pr list --state open --limit 50 \
-  --json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body
-
-# Collaborateurs (pour distinguer "nos PRs" des externes)
-gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'
-```
-
-**Fallback collaborateurs** : si `gh api .../collaborators` échoue (403/404) :
-```bash
-# Extraire les auteurs des 10 derniers PRs mergés
-gh pr list --state merged --limit 10 --json author --jq '.[].author.login' | sort -u
-```
-Si toujours ambigu, demander à l'utilisateur via `AskUserQuestion`.
-
-Pour chaque PR, récupérer reviews existantes ET fichiers modifiés :
-
-```bash
-gh api "repos/{owner}/{repo}/pulls/{num}/reviews" \
-  --jq '[.[] | .user.login + ":" + .state] | join(", ")'
-
-# Fichiers modifiés (nécessaire pour overlap detection)
-gh pr view {num} --json files --jq '[.files[].path] | join(",")'
-```
-
-**Note rate-limiting** : la récupération des fichiers est N appels API (1 par PR). Pour repos avec 20+ PRs, prioriser les PRs candidates à l'overlap (même domaine fonctionnel, même auteur).
-
-**Note** : `author` est un objet `{login: "..."}` — toujours extraire `.author.login`.
-
-### Analyse
-
-**Classification taille** :
-| Label | Additions |
-|-------|-----------|
-| XS | < 50 |
-| S | 50–200 |
-| M | 200–500 |
-| L | 500–1000 |
-| XL | > 1000 |
-
-Format taille : `+{additions}/-{deletions}, {files} files ({label})`
-
-**Détections** :
-- **Overlaps** : comparer les listes de fichiers entre PRs — si >50% de fichiers en commun → cross-reference
-- **Clusters** : auteur avec 3+ PRs ouvertes → suggérer ordre de review (plus petite en premier)
-- **Staleness** : aucune activité depuis >14j → flag "stale"
-- **CI status** : via `statusCheckRollup` → `clean` / `unstable` / `dirty`
-- **Reviews** : approved / changes_requested / aucune
-
-**Liens PR ↔ Issues** :
-- Scanner le `body` de chaque PR pour `fixes #N`, `closes #N`, `resolves #N` (case-insensitive)
-- Si trouvé, afficher dans le tableau : `Fixes #42` dans la colonne Action/Status
-
-**Catégorisation** :
-
-_Nos PRs_ : auteur dans la liste des collaborateurs
-
-_Externes — Prêtes_ : additions ≤ 1000 ET files ≤ 10 ET `mergeable` ≠ `CONFLICTING` ET CI clean/unstable
-
-_Externes — Problématiques_ : un des critères suivants :
-- additions > 1000 OU files > 10
-- OU `mergeable` == `CONFLICTING` (conflit de merge)
-- OU CI dirty (statusCheckRollup contient des échecs)
-- OU overlap avec une autre PR ouverte (>50% fichiers communs)
-
-### Output — Tableau de triage
-
-```
-## PRs ouvertes ({count})
-
-### Nos PRs
-| PR | Titre | Taille | CI | Status |
-| -- | ----- | ------ | -- | ------ |
-
-### Externes — Prêtes pour review
-| PR | Auteur | Titre | Taille | CI | Reviews | Action |
-| -- | ------ | ----- | ------ | -- | ------- | ------ |
-
-### Externes — Problématiques
-| PR | Auteur | Titre | Taille | Problème | Action recommandée |
-| -- | ------ | ----- | ------ | -------- | ------------------ |
-
-### Résumé
-- Quick wins : {PRs XS/S prêtes à merger}
-- Risques : {overlaps, tailles XL, CI dirty}
-- Clusters : {auteurs avec 3+ PRs}
-- Stale : {PRs sans activité >14j}
-- Overlaps : {PRs qui touchent les mêmes fichiers}
-```
-
-0 PRs → afficher `Aucune PR ouverte.` et terminer.
-
-### Copie automatique
-
-Après affichage du tableau de triage, copier dans le presse-papier :
-```bash
-pbcopy <<'EOF'
-{tableau de triage complet}
-EOF
-```
-Confirmer : `Tableau copié dans le presse-papier.` (FR) / `Triage table copied to clipboard.` (EN)
-
----
-
-## Phase 2 — Deep Review (opt-in)
-
-### Sélection des PRs
-
-**Si argument passé** :
-- `"all"` → toutes les PRs externes
-- Numéros (`"42 57"`) → uniquement ces PRs
-- Pas d'argument → proposer via `AskUserQuestion`
-
-**Si pas d'argument**, afficher :
-
-```
-question: "Quelles PRs voulez-vous reviewer en profondeur ?"
-header: "Deep Review"
-multiSelect: true
-options:
-  - label: "Toutes les externes"
-    description: "Review {N} PRs externes avec agents code-reviewer en parallèle"
-  - label: "Problématiques uniquement"
-    description: "Focus sur les {M} PRs à risque (CI dirty, trop large, overlaps)"
-  - label: "Prêtes uniquement"
-    description: "Review {K} PRs prêtes à merger"
-  - label: "Passer"
-    description: "Terminer ici — juste l'audit"
-```
-
-**Note sur les drafts** :
-- Les PRs en draft sont EXCLUES des options "Toutes les externes" et "Prêtes uniquement"
-- Les PRs en draft sont INCLUSES dans "Problématiques uniquement" (car elles nécessitent attention)
-- Pour reviewer un draft : taper son numéro explicitement (ex: `42`)
-
-Si "Passer" → fin du workflow.
-
-### Exécution des Reviews
-
-Pour chaque PR sélectionnée, lancer un agent `code-reviewer` via **Task tool en parallèle** :
-
-```
-subagent_type: code-reviewer
-model: sonnet
-prompt: |
-  Review PR #{num}: "{title}" by @{author}
-
-  **Metadata**: +{additions}/-{deletions}, {changedFiles} files ({size_label})
-  **CI**: {ci_status} | **Reviews**: {existing_reviews} | **Draft**: {isDraft}
-
-  **PR Body**:
-  {body}
-
-  **Diff**:
-  {gh pr diff {num} output}
-
-  Apply your security-guardian and backend-architect skills for this review.
-  Additionally, apply the RTK-specific checklist:
-  - lazy_static! regex (no inline Regex::new())
-  - anyhow::Result + .context() (no unwrap())
-  - Fallback to raw command on filter failure
-  - Exit code propagation
-  - Token savings ≥60% in tests with real fixtures
-  - No async/tokio dependencies
-
-  Return structured review:
-  ### Critical Issues 🔴
-  ### Important Issues 🟡
-  ### Suggestions 🟢
-  ### What's Good ✅
-
-  Be specific: quote the file:line, explain why it's an issue, suggest the fix.
-```
-
-Récupérer le diff via :
-```bash
-gh pr diff {num}
-gh pr view {num} --json body,title,author -q '{body: .body, title: .title, author: .author.login}'
-```
-
-Agréger tous les rapports. Afficher un résumé après toutes les reviews.
-
----
-
-## Phase 3 — Commentaires (validation obligatoire)
-
-### Génération des drafts
-
-Pour chaque PR reviewée, générer un commentaire GitHub en utilisant le template `templates/review-comment.md`.
-
-**Règles** :
-- Langue : **anglais** (audience internationale)
-- Ton : professionnel, constructif, factuel
-- Toujours inclure au moins 1 point positif
-- Citer les lignes de code quand pertinent (format `file.rs:42`)
-
-### Affichage et validation
-
-**Afficher TOUS les commentaires draftés** au format :
-
-```
----
-### Draft — PR #{num}: {title}
-
-{commentaire complet}
-
----
-```
-
-Puis demander validation via `AskUserQuestion` :
-
-```
-question: "Ces commentaires sont prêts. Lesquels voulez-vous poster ?"
-header: "Poster"
-multiSelect: true
-options:
-  - label: "Tous ({N} commentaires)"
-    description: "Poster sur toutes les PRs reviewées"
-  - label: "PR #{x} — {title_truncated}"
-    description: "Poster uniquement sur cette PR"
-  - label: "Aucun"
-    description: "Annuler — ne rien poster"
-```
-
-(Générer une option par PR + "Tous" + "Aucun")
-
-### Posting
-
-Pour chaque commentaire validé :
-
-```bash
-gh pr comment {num} --body-file - <<'REVIEW_EOF'
-{commentaire}
-REVIEW_EOF
-```
-
-Confirmer chaque post : `✅ Commentaire posté sur PR #{num}: {title}`
-
-Si "Aucun" → `Aucun commentaire posté. Workflow terminé.`
-
----
-
-## Gestion des cas limites
-
-| Situation | Comportement |
-|-----------|--------------|
-| 0 PRs ouvertes | `Aucune PR ouverte.` + terminer |
-| PR en draft | Indiquer dans tableau, skip pour review sauf si sélectionnée explicitement |
-| CI inconnu | Afficher `?` dans colonne CI |
-| Review agent timeout | Afficher erreur partielle, continuer avec les autres |
-| `gh pr diff` vide | Skip cette PR, notifier l'utilisateur |
-| PR très large (>5000 additions) | Avertir : "Review partielle, diff tronqué" |
-| Collaborateurs API 403/404 | Fallback sur auteurs des 10 derniers PRs mergés |
-
----
-
-## Notes
-
-- Toujours dériver owner/repo via `gh repo view`, jamais hardcoder
-- Utiliser `gh` CLI (pas `curl` GitHub API) sauf pour la liste des collaborateurs
-- `statusCheckRollup` peut être null → traiter comme `?`
-- `mergeable` peut être `MERGEABLE`, `CONFLICTING`, ou `UNKNOWN` → traiter `UNKNOWN` comme `?`
-- Ne jamais poster sans validation explicite de l'utilisateur dans le chat
-- Les commentaires draftés doivent être visibles AVANT tout `gh pr comment`

package/temp/rtk/.claude/skills/pr-triage/templates/review-comment.md

@@ -1,71 +0,0 @@
-# Review Comment Template
-
-Use this template to generate GitHub PR review comments. Fill in each section based on the code-reviewer agent output. Comments are posted in **English** (international audience).
-
----
-
-## Template
-
-```markdown
-## Review
-
-**Scope**: Security, code quality, performance, test coverage, architecture
-
-### Summary
-
-{1–2 sentences: overall assessment. Be direct — what's the main takeaway?}
-
-### Critical Issues 🔴
-
-{List blocking issues that must be fixed before merge. For each:}
-{- `file.rs:42` — Description of the problem. Why it matters. Suggested fix.}
-
-{If none: "None found."}
-
-### Important Issues 🟡
-
-{List significant issues that should be fixed. For each:}
-{- `file.rs:42` — Description. Why it matters. Suggested fix.}
-
-{If none: "None found."}
-
-### Suggestions 🟢
-
-{List nice-to-haves and minor improvements. For each:}
-{- Description. Context. Optional fix.}
-
-{If none: omit this section.}
-
-### What's Good ✅
-
-{Always include at least 1 positive point. Be specific — what works well and why.}
-{- Description of what's done right.}
-
----
-*Automated review via [rtk](https://github.com/rtk-ai/rtk) `/pr-triage`*
-```
-
----
-
-## Formatting Rules
-
-**Citation format** : `file.rs:42` or `` `code snippet` `` for inline references
-
-**Issue severity** :
-- 🔴 Critical : security vulnerability, data loss risk, broken functionality, test missing for new feature
-- 🟡 Important : error handling gap, performance regression, scope creep, missing token savings assertion
-- 🟢 Suggestion : naming, DRY opportunity, documentation, style
-
-**RTK-specific checks to mention if relevant** :
-- `lazy_static!` for regex (not inline `Regex::new()`)
-- `anyhow::Result` + `.context("msg")` (no bare `?`, no `.unwrap()`)
-- Fallback to raw command on filter failure
-- Exit code propagation (`std::process::exit(code)`)
-- Token savings assertion ≥60% in tests
-- Real fixtures (not synthetic test data)
-- No async/tokio dependencies (startup time)
-
-**Tone** : Professional, constructive, factual. Challenge the code, not the person.
-No superlatives ("great", "amazing", "perfect"). No filler ("as mentioned", "it's worth noting").
-
-**Length** : Aim for 200–400 words. Long enough to be useful, short enough to be read.

package/temp/rtk/.claude/skills/repo-recap.md

@@ -1,206 +0,0 @@
----
-description: Generate a comprehensive repo recap (PRs, issues, releases) for sharing with team. Pass "en" or "fr" as argument for language (default fr).
----
-
-# Repo Recap
-
-Generate a structured recap of the repository state: open PRs, open issues, recent releases, and executive summary. Output is formatted as Markdown with clickable GitHub links, ready to share.
-
-## Language
-
-- Check the argument passed to this skill
-- If `en` or `english` → produce the recap in English
-- If `fr`, `french`, or no argument → produce the recap in French (default)
-
-## Preconditions
-
-Before gathering data, verify:
-
-```bash
-# Must be inside a git repo
-git rev-parse --is-inside-work-tree
-
-# Must have gh CLI authenticated
-gh auth status
-```
-
-If either fails, stop and tell the user what's missing.
-
-## Steps
-
-### 1. Gather Data
-
-Run these commands in parallel via `gh` CLI:
-
-```bash
-# Repo identity (for links)
-gh repo view --json nameWithOwner -q .nameWithOwner
-
-# Open PRs with metadata
-gh pr list --state open --limit 50 --json number,title,author,createdAt,changedFiles,additions,deletions,reviewDecision,isDraft
-
-# Open issues with metadata
-gh issue list --state open --limit 50 --json number,title,author,createdAt,labels,assignees
-
-# Recent releases (for version history)
-gh release list --limit 5
-
-# Recently merged PRs (for contributor activity)
-gh pr list --state merged --limit 10 --json number,title,author,mergedAt
-```
-
-Note: `author` in JSON results is an object `{login: "..."}` — always extract `.author.login` when processing.
-
-### 2. Determine Maintainers
-
-To distinguish "our PRs" from external contributions:
-
-```bash
-gh api repos/{owner}/{repo}/collaborators --jq '.[].login'
-```
-
-If this fails (permissions), fallback: authors with write/admin access are those who merged PRs recently. When in doubt, ask the user.
-
-### 3. Analyze and Categorize
-
-#### PRs — Categorize into 3 groups:
-
-**Our PRs** (author is a repo collaborator):
-- List with PR number (linked), title, size (+additions, files count), status
-
-**External — Reviewable** (manageable size, no major blockers):
-- Additions ≤ 1000 AND files ≤ 10
-- No merge conflicts, CI not failing
-- Include: PR link, author, title, size, review status, recommended action
-
-**External — Problematic** (any of: too large, CI failing, overlapping, merge conflict):
-- Additions > 1000 OR files > 10
-- OR CI failing (reviewDecision = "CHANGES_REQUESTED" or checks failing)
-- OR touches same files as another open PR (= overlap)
-- Include: PR link, author, title, size, specific problem, action taken/needed
-
-**Size labels** (use in "Taille" column for quick visual triage):
-
-| Label | Additions |
-| ----- | --------- |
-| XS | < 50 |
-| S | 50-200 |
-| M | 200-500 |
-| L | 500-1000 |
-| XL | > 1000 |
-
-Format: `+{additions}, {files} files ({label})` — e.g., `+245, 2 files (S)`
-
-#### Detect overlaps:
-Two PRs overlap if they modify the same files. Use `changedFiles` from the JSON data. If >50% file overlap between 2 PRs, flag both as overlapping and cross-reference them.
-
-#### Flag clusters:
-If one author has 3+ open PRs, note it as a "cluster" with suggested review order (smallest first, or by dependency chain).
-
-#### Issues — Categorize by status:
-- **In progress**: has an associated open PR (match by PR body containing `fixes #N`, `closes #N`, or same topic)
-- **Quick fix**: small scope, actionable (bug reports, small enhancements)
-- **Feature request**: larger scope, needs design discussion
-- **Covered by PR**: an existing PR addresses this issue (link it)
-
-### 4. Derive Recent Releases
-
-From `gh release list` output, extract version, date, and name. List the 5 most recent.
-
-If no releases found, check merged PRs for release-please pattern (title matching `chore(*): release *`) as fallback.
-
-### 5. Executive Summary
-
-Produce 5-6 bullet points:
-- Total open PRs and issues count
-- Active contributors (who has the most PRs/issues)
-- Main risks (oversized PRs, CI failures, merge conflicts)
-- Quick wins (small PRs ready to merge — XS/S size, no blockers)
-- Bug fixes needed (hook bugs, regressions)
-- Our own PRs status
-
-### 6. Format Output
-
-Structure the full recap as Markdown with:
-- `# {Repo Name} — Récap au {date}` as title (FR) or `# {Repo Name} — Recap {date}` (EN)
-- Sections separated by `---`
-- All PR/issue numbers as clickable links: `[#123](https://github.com/{owner}/{repo}/pull/123)` for PRs, `.../issues/123` for issues
-- Tables with Markdown pipe syntax for all listings
-- Bold for emphasis on actions and risks
-- Cross-references between related PRs and issues (e.g., "Covered by [#131](link)")
-
-**Empty data handling**:
-- 0 open PRs → display "Aucune PR ouverte." (FR) or "No open PRs." (EN) instead of empty table
-- 0 open issues → display "Aucune issue ouverte." (FR) or "No open issues." (EN)
-- 0 releases → display "Aucune release récente." (FR) or "No recent releases." (EN)
-
-### 7. Copy to Clipboard
-
-After displaying the recap, automatically copy it to clipboard:
-
-```bash
-cat << 'EOF' | pbcopy
-{formatted recap content}
-EOF
-```
-
-Confirm with: "Copié dans le presse-papier." (FR) or "Copied to clipboard." (EN)
-
-## Output Template (FR)
-
-```markdown
-# {Repo Name} — Récap au {date}
-
-## Releases récentes
-
-| Version | Date | Highlights |
-| ------- | ---- | ---------- |
-| ...     | ...  | ...        |
-
----
-
-## PRs ouvertes ({count} total)
-
-### Nos PRs
-
-| PR | Titre | Taille | Status |
-| -- | ----- | ------ | ------ |
-
-### Contributeurs externes — Reviewables
-
-| PR | Auteur | Titre | Taille | Status | Action |
-| -- | ------ | ----- | ------ | ------ | ------ |
-
-### Contributeurs externes — Problématiques
-
-| PR | Auteur | Titre | Taille | Problème | Action |
-| -- | ------ | ----- | ------ | -------- | ------ |
-
----
-
-## Issues ouvertes ({count} total)
-
-| # | Auteur | Sujet | Priorité |
-| - | ------ | ----- | -------- |
-
----
-
-## Résumé exécutif
-
-- **Point 1**: ...
-- **Point 2**: ...
-```
-
-## Output Template (EN)
-
-Same structure but with English headers:
-- "Recent Releases", "Open PRs", "Our PRs", "External — Reviewable", "External — Problematic", "Open Issues", "Executive Summary"
-- Action labels: "To review", "Rebase requested", "Split requested", "Trim requested", "CI broken", "Waiting on author", "Feature request", "Quick fix", "Covered by PR"
-
-## Notes
-
-- Always use `gh` CLI (not GitHub API directly, except for collaborators list)
-- Derive repo owner/name from `gh repo view`, don't hardcode
-- Keep tables compact — truncate long titles if needed (max ~60 chars)
-- Cross-reference overlapping PRs/issues whenever possible
-- `author` in gh JSON is an object — always use `.author.login`

package/temp/rtk/.claude/skills/rtk-tdd/SKILL.md

@@ -1,78 +0,0 @@
----
-name: rtk-tdd
-description: >
-  Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on
-  implementation, testing, refactoring, and bug fixing tasks. Provides
-  Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and
-  Arrange-Act-Assert workflow.
----
-
-# Rust TDD Workflow
-
-## Three Laws of TDD
-
-1. Do NOT write production code without a failing test
-2. Write only enough test to fail (including compilation failure)
-3. Write only enough production code to pass the failing test
-
-Cycle: **RED** (test fails) -> **GREEN** (minimum to pass) -> **REFACTOR** (cleanup, cargo test)
-
-## Red-Green-Refactor Steps
-
-```
-1. Write test in #[cfg(test)] mod tests of the SAME file
-2. cargo test MODULE::tests::test_name  -- must FAIL (red)
-3. Implement the minimum in the function
-4. cargo test MODULE::tests::test_name  -- must PASS (green)
-5. Refactor if needed, re-run cargo test (still green)
-6. cargo fmt && cargo clippy --all-targets && cargo test  (final gate)
-```
-
-Never skip step 2. If the test passes immediately, it tests nothing.
-
-## Idiomatic Rust Test Patterns
-
-| Pattern | Usage | When |
-|---------|-------|------|
-| Arrange-Act-Assert | Base structure for every test | Always |
-| `assert_eq!` / `assert!` | Direct comparison / booleans | Deterministic values |
-| `assert!(result.is_err())` | Error path testing | Invalid inputs |
-| `Result<()>` return type | Tests with `?` operator | Fallible functions |
-| `#[should_panic]` | Expected panic | Invariants, preconditions |
-| `tempfile::NamedTempFile` | File/I/O tests | Filesystem-dependent code |
-
-## Patterns by Code Type
-
-| Code Type | Test Pattern | Example |
-|-----------|-------------|---------|
-| Pure function (str -> str) | Input literal -> assert output | `assert_eq!(truncate("hello", 3), "...")` |
-| Parsing/filtering | Raw string -> filter -> contains/not-contains | `assert!(filter(raw).contains("expected"))` |
-| Validation/security | Boundary inputs -> assert bool | `assert!(!is_valid("../etc/passwd"))` |
-| Error handling | Bad input -> `is_err()` | `assert!(parse("garbage").is_err())` |
-| Struct/enum roundtrip | Construct -> serialize -> deserialize -> eq | `assert_eq!(from_str(to_str(x)), x)` |
-
-## Naming Convention
-
-```
-test_{function}_{scenario}
-test_{function}_{input_type}
-```
-
-Examples: `test_truncate_edge_case`, `test_parse_invalid_input`, `test_filter_empty_string`
-
-## When NOT to Use Pure TDD
-
-- Functions calling `Command::new()` -> test the parser, not the execution
-- `std::process::exit()` -> refactor to `Result` first, then test the Result
-- Direct I/O (SQLite, network) -> use tempfile/mock or test the pure logic separately
-- Main/CLI wiring -> covered by integration/smoke tests
-
-## Pre-Commit Gate
-
-```bash
-cargo fmt --all --check
-cargo clippy --all-targets
-cargo test
-```
-
-All 3 must pass. No exceptions. No `#[allow(...)]` without documented justification.