원클릭으로 Manus에서 모든 스킬 실행

rtk-pr-review

스타4

포크0

업데이트2026년 5월 14일 19:35

Use when batch-reviewing rtk PRs from simplest to most complex — checks each PR's state (conflicts, CLA, CHANGES_REQUESTED), reads the full diff, presents one PR at a time with a 2-4 sentence summary and explicit merge prompt, never merges without a typed "ok", and posts boldguy-tone comments on blocked PRs (rebase needed, CLA missing). Args: `triage` to chain `/rtk-triage` first; `from:<num>` to resume.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

danmestas

danmestas/wardrobe

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 품질 보증 분석가·테스터컴퓨터 및 수학직·SOC 15-1253

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

helland

danmestas/wardrobe

The Pat Helland lens: treat durable data as immutable, append-only facts that carry their own identity and version; and design across service, machine, or org boundaries assuming you cannot have distributed transactions — only idempotent, at-least-once messages that must be reconciled. Apply this on in-place updates and overwrites, "just UPDATE the row," two-phase commit or distributed transactions at scale, exactly-once delivery assumptions, shared mutable state across services, and any data that crosses a boundary of service, machine, org, or time. Trigger even when Helland isn't named — the smell is mutation-in-place and pretending distributed systems can be transactional.

2026-07-184

hickey

danmestas/wardrobe

The Rich Hickey lens: pursue simple (un-braided, one role) over easy (familiar, near-at-hand), decomplect concerns that got tangled together, and separate value, identity, state, and time. Apply this whenever "easy," "convenient," or "it's what we already use" is doing the work of justifying a design; when state is braided into logic, policy into mechanism, or data into behavior; when object-soup would be plainer as data; and when a hard design decision is being made at the keyboard under time pressure instead of thought through first. Trigger even when Hickey isn't named — the smell is complecting, and confusing "easy" with "simple."

2026-07-184

carmack

danmestas/wardrobe

The John Carmack lens: minimize the mutable state you have to reason about, do the simple thing before the clever one, and treat correctness tooling — static analysis, warnings-as-errors, determinism — as non-negotiable. Apply this on sprawling mutable state, "we'll clean it up later," debugging by print- statement whack-a-mole, silenced compiler warnings, nondeterministic or non-reproducible behavior, premature abstraction, perf work that skips measurement, and any "what should we actually work on" prioritization call. Trigger even when Carmack isn't named — the smell is code whose full set of states you can't hold in your head, and effort that isn't ruthlessly focused.

2026-07-184

bellard

danmestas/wardrobe

The Fabrice Bellard lens: build the smallest self-contained thing that fully does the job, get performance from insight instead of hardware, and reuse existing machinery instead of reinventing it. Apply this whenever code is growing dependencies, frameworks, services, or infrastructure to solve a problem that a smaller, sharper implementation could handle — or whenever someone says a thing needs a cluster, a big framework, or a rewrite. Use for size/complexity audits, "do we really need this dependency/service?" questions, performance work where the reflex is to add hardware or caching, green-field "should this be one file or a platform?" decisions, and any moment the answer is trending toward "that's impractical, you'd need X." Trigger even when the user doesn't name Bellard — the smell is scope inflation and reaching for resources over insight.

2026-07-184

vault-autoresearch

danmestas/wardrobe

Use when iteratively researching a topic and filing the synthesis into an Obsidian vault for later ingestion. Output goes to `<vault>/raw/` (NOT directly into wiki pages) so that `vault-ingest` can process it on its own schedule. Triggers: '/vault-autoresearch', 'autoresearch [topic]', 'research [topic] into the vault', 'deep dive into [topic]', 'find everything about [topic] for the vault', 'research and stage'.

2026-07-144

vault-ingest

danmestas/wardrobe

Ingest sources into the Obsidian wiki vault. Reads a source, extracts entities and concepts, creates or updates wiki pages, cross-references, and logs the operation. Supports files, URLs, and batch mode. Triggers on: ingest, process this source, add this to the wiki, read and file this, batch ingest, ingest all of these, ingest this url.

2026-07-144

name	rtk-pr-review
version	1.0.0
targets	["claude-code"]
type	skill
description	Use when batch-reviewing rtk PRs from simplest to most complex — checks each PR's state (conflicts, CLA, CHANGES_REQUESTED), reads the full diff, presents one PR at a time with a 2-4 sentence summary and explicit merge prompt, never merges without a typed "ok", and posts boldguy-tone comments on blocked PRs (rebase needed, CLA missing). Args: `triage` to chain `/rtk-triage` first; `from:<num>` to resume.
category	{"primary":"workflow"}
license	{"upstream":"Apache-2.0","source":"rtk-ai/rtk@3ba1634","path":".claude/skills/pr-review/SKILL.md"}

/rtk-pr-review

Batch review des PRs RTK — du plus simple au plus complexe, une par une, avec validation utilisateur avant chaque merge.

Quand utiliser

Après un /rtk-triage pour agir sur les résultats
Régulièrement pour dégraisser le backlog
Avant une release pour vider la file quick wins

Workflow

Phase 0 — Préconditions

git rev-parse --is-inside-work-tree
gh auth status
date +%Y-%m-%d

Si l'argument triage est passé, exécuter /rtk-triage d'abord et utiliser sa liste de quick wins comme séquence. Sinon, construire la liste soi-même.

Phase 1 — Construire la liste de PRs (si pas de triage)

gh pr list --state open --limit 200 \
  --json number,title,author,additions,deletions,changedFiles,mergeable,mergeStateStatus,isDraft,statusCheckRollup,reviewDecision,body \
  | jq 'sort_by(.additions + .deletions)'

Classement par taille :

Taille	Critère	Traitement
XS	< 30 lignes, 1 fichier	En premier
S	30-100 lignes, 1-3 fichiers	Ensuite
M	100-200 lignes, logique non triviale	Après
L	> 200 lignes	Dernier ou skip
XL	> 500 lignes	Skip (session dédiée)

Filtrer d'emblée :

Exclure les PRs draft
Exclure les PRs de nous (les nôtres ont une review flow différente)
Si from:<num> passé en argument : commencer à ce numéro

Phase 2 — Pour chaque PR (une par une, dans l'ordre)

Étape A — Vérification état (AVANT de lire le diff)

# 1. Etat mergeable + CLA
gh pr view <num> --json mergeable,mergeStateStatus,statusCheckRollup,reviewDecision

# 2. Reviews existantes (CHANGES_REQUESTED ?)
gh api repos/rtk-ai/rtk/pulls/<num>/reviews \
  --jq '.[] | {author: .user.login, state: .state, body: .body}'

# 3. Commentaires inline (si CHANGES_REQUESTED)
gh api repos/rtk-ai/rtk/pulls/<num>/comments \
  --jq '.[] | {author: .user.login, body: .body, path: .path, line: .line}'

Décision rapide selon état :

État	Action
MERGEABLE + CLA ok + pas de CHANGES_REQUESTED	-> lire le diff
CONFLICTING	-> préparer commentaire rebase, skip diff
CLA non signé	-> préparer commentaire CLA, skip diff
CHANGES_REQUESTED par un maintainer	-> skip (ne pas override), noter
Draft	-> skip silencieusement

Étape B — Lire le diff complet

gh pr diff <num>

Si le diff touche une logique complexe (filter functions, regex, routing) -> lire le fichier source en contexte avec Read pour comprendre l'impact réel.

Étape C — Présenter à l'utilisateur

Format de présentation obligatoire pour chaque PR :

**PR #<num>** — https://github.com/rtk-ai/rtk/pull/<num>

**Author**: <login> | **Size**: <XS/S/M/L> (+<add> -<del>, <N> fichiers) | **CLA**: <ok/non signé> | **Mergeable**: <clean/conflit>

**Ce que ça fait** — [description en 2-4 phrases : le problème résolu, les fichiers touchés, la logique modifiée, les tests ajoutés]

**Qualité du diff** : [analyse honnête : propre/à vérifier/problème détecté]

Merge #<num> ?

Règles de présentation :

Toujours inclure le lien GitHub cliquable
Toujours mentionner si des tests couvrent le changement
Si une fonction complexe est touchée, expliquer l'impact
Ne pas embellir — si le diff est moyen, le dire
Langue : français pour l'analyse (comme ici)

Étape D — Attendre la validation

NE JAMAIS MERGER SANS RÉPONSE EXPLICITE. Les réponses attendues :

Réponse	Action
"ok" / "go" / "merge"	Merger avec `gh pr merge --merge`
"skip" / "next"	Passer à la PR suivante sans merger
"comment"	Poster un commentaire (demander le texte si pas fourni)
"close"	Fermer la PR
Retour avec instructions	Appliquer puis redemander confirmation

Étape E — Merger (si validé)

gh pr merge <num> --merge --squash

Confirmer immédiatement : Merged #<num>.

Puis vérifier que la PR suivante n'est pas passée en CONFLICTING à cause du merge (surtout si les deux touchent rules.rs, registry.rs, main.rs, ou CHANGELOG.md).

Phase 3 — PRs bloquées : commentaire boldguy-adapt

Pour les PRs avec conflit, CLA manquant, ou besoin de rebase, poster un commentaire en anglais, ton boldguy-adapt.

Règles du commentaire :

Anglais uniquement (GitHub)
Remercier la contribution en ouverture (sincèrement, pas de manière générique)
Dire clairement ce qui bloque (1-2 points max)
Donner les étapes exactes pour débloquer
Pas d'em dash (—), pas de staccato, longueurs de phrases variées
Ne pas sonner comme un bot

Template conflit + CLA :

Hey @<author>, thanks for the contribution! [mention spécifique de ce que la PR apporte]

Two things before we can merge:

1. The branch needs a rebase on `develop` — there's a conflict on [fichier]. A `git rebase origin/develop` should do it.

2. The CLA hasn't been signed yet. The CLAassistant bot left instructions in the PR — just follow the link, takes about a minute.

Once both are sorted, this will move quickly.

Template conflit seul :

Hey @<author>, good fix on [description spécifique]. One thing to address before merge: the branch has a conflict on [fichier] after recent changes to develop. A `git rebase origin/develop` should resolve it cleanly.

Template CLA seul :

Hey @<author>, thanks for [description spécifique]. The only thing blocking merge is the CLA signature — the CLAassistant bot left the link in the PR. Once that's done, we're good to go.

Phase 4 — Récap de session

Après avoir traité toutes les PRs (ou à la demande) :

## Session recap — YYYY-MM-DD

| PR | Titre | Action | Raison |
|----|-------|--------|--------|
| #N | titre | Mergé | — |
| #N | titre | Skip | CHANGES_REQUESTED (KuSh) |
| #N | titre | Commenté | Conflit + CLA |
| #N | titre | Fermé | Doublon avec #M |

Mergées : N | Skippées : N | Commentées : N

Règles

Une PR à la fois — ne jamais présenter plusieurs PRs en attente de validation
Jamais merger sans "ok" explicite — "ça a l'air bien" n'est pas un ok
Ne pas overrider un CHANGES_REQUESTED d'un maintainer sans instructions explicites de l'utilisateur
Vérifier les conflits post-merge sur la PR suivante si les deux touchent les mêmes fichiers
Langue : analyse en français, commentaires GitHub en anglais
Ton boldguy : factuel, direct, bienveillant, pas de marqueurs AI (em dash, staccato, punchline finale parfaite)

Fichiers fréquemment en conflit (surveiller)

CHANGELOG.md — toutes les PRs y touchent
src/discover/rules.rs — ajouts fréquents de règles
src/discover/registry.rs — tests de classify/rewrite
src/main.rs — routing des commandes
src/hooks/rewrite_cmd.rs — rewrites hooks