Backend code review for Dify's api: evidence-first findings with a severity ladder
Revues backend fondées sur preuves — inspecter le diff, router vers les rule packs (schéma DB, architecture, repositories, SQLAlchemy), rapporter des findings P0–P3 liés à des défaillances observables
- Quoi
- Revues backend fondées sur preuves — inspecter le diff, router vers les rule packs (schéma DB, architecture, repositories, SQLAlchemy), rapporter des findings P0–P3 liés à des défaillances observables
- Coût
- Gratuit
- Prérequis
- un changement backend à revoir (idéalement le layout api/ de Dify lui-même, les rule packs étant spécifiques à Dify) — le skill est une méthodologie de revue, pas un logiciel
- Installation
- Copiez le prompt d’installation ci-dessous dans votre Muse — votre agent fait le reste.
Sélectionné par Skill Harbor — fiche courte (le repo ne déclare aucune licence, donc aucun contenu n'est reproduit) : le skill de revue de code backend de @langgenius, écrit pour le backend du projet Dify lui-même (les revues ciblent le code sous `api/`). La discipline : preuves d'abord — inspecter le diff ou les fichiers demandés, lire les lignes changées plus leurs propriétaires de comportement et les tests voisins, tracer les appelants et les frontières seulement là où ils décident de la justesse, et ne rapporter QUE des findings liés à une défaillance observable, un contrat violé, une frontière de sécurité, un risque d'intégrité de données, ou un problème de maintenance démontré. Les revues routent vers des rule packs fournis lus selon le type de diff : schéma DB, architecture, repositories, et SQLAlchemy ; quand aucun pack ne s'applique, la justesse/sécurité/comportement sont revus directement contre les contrats locaux. Les findings suivent une échelle de sévérité (P0 sécurité/perte de données/outage, P1 régression visible ou auth cassée, P2 défaut concret de justesse, P3 nettoyage mineur sur demande explicite), ordonnés par sévérité avec références file:line, contrats en échec et directions de fix — pas de sections d'éloges, pas de risques spéculatifs. Bémols honnêtes : écrit pour le layout du repo Dify lui-même (le scope `api/` et les rule packs fournis sont spécifiques à Dify) — moins utile comme reviewer générique ; licence non déclarée par le repo source — fiche courte avec lien uniquement, rien copié. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage. Découvert via skills.sh.
Version :
Installation
Prérequis : un changement backend à revoir (idéalement le layout api/ de Dify lui-même, les rule packs étant spécifiques à Dify) — le skill est une méthodologie de revue, pas un logiciel Installe-moi « Revue de code backend pour l'api de Dify : findings fondés sur preuves avec échelle de sévérité ». Il donne à mon agent le workflow de revue de @langgenius : établir le scope et inspecter le diff, lire les lignes changées avec leurs propriétaires de comportement et les tests voisins, router vers les rule packs correspondants (schéma DB, architecture, repositories, SQLAlchemy), et ne rapporter que des findings fondés sur preuves sur l'échelle de sévérité P0–P3 — pas d'éloges, pas de spéculation. IMPORTANT : le repo ne déclare aucune licence — récupérer depuis le lien seulement, et ne rien reproduire au-delà du lien. Dépôt : https://github.com/langgenius/dify/blob/main/.agents/skills/backend-code-review/SKILL.md 1. Récupère le fichier SKILL.md (et les fichiers d'aide éventuels) depuis le chemin du dépôt dans un dossier temporaire et résume en une ou deux phrases ce qu'il fait. 2. Vérification de sécurité : examine le SKILL.md et les scripts pour tout contenu suspect (appels réseau inattendus, commandes shell, collecte d'identifiants). Ce dépôt ne devrait contenir aucun secret en dur. Vérifie que c'est bien le cas ici ; STOP sur tout signal d'alerte et dis-le-moi. 3. Installe-le comme skill : copie le SKILL.md et ses fichiers d'aide dans le répertoire des skills de l'agent, dans un dossier nommé « backend-code-review ». 4. Vérifie sans appels réseau : frontmatter valide, fichiers en place. 5. Indique ce qui a été installé, où, et ce qu'il me reste à faire moi-même (p. ex. remettre à l'agent le diff ou les fichiers à revoir ; rien d'autre — c'est une méthodologie). GitHub est optionnel : si j'ai un compte GitHub ou la CLI gh, tu peux l'utiliser ; sinon l'accès public suffit. Ne jamais l'exiger sauf s'il figure dans les prérequis ci-dessus. Règles : ne touche à rien en dehors du dossier temporaire et de la cible d'installation. Si quelque chose semble anormal, arrête-toi et demande-moi.
Questions
Comment installer une création ?
Chaque fiche produit contient un prompt d’installation à copier-coller. Collez-le dans votre Muse et il installe la création pour vous — sans configuration manuelle.
Où va mon argent ?
Directement au vendeur. Skill Harbor ne traite jamais les paiements : le paiement se fait sur la page du vendeur, généralement via Stripe.
Que signifie le ✓ à côté du nom d’un créateur ?
Il signifie que nous avons confirmé l’identité de la personne derrière la fiche. Il ne dit rien sur le code lui-même — vérifiez toujours une création avant de l’installer.