Appliquez des critères de qualité des commentaires lors de l'implémentation et lors du passage final de qualité des commentaires avant la revue finale, la revue multiple ou la revue d'architecture après des modifications de code. Applicable de manière égale dans Codex, Claude et OMP pour Python, Kotlin, React Web, React Native, iOS, Swift et SwiftUI.
Cette compétence (skill) « chonamdoo/comment-authoring-discipline » établit une discipline systématique pour la rédaction de commentaires de qualité dans le code source. Son objectif principal est d'appliquer des critères de qualité à la fois pendant la phase d'implémentation (en temps réel) et lors d'un passage dédié de consolidation avant les différentes étapes de revue (finale, multiple ou architecture). Elle est utile car elle garantit que seuls des commentaires pertinents, clairs et non redondants sont présents, évitant ainsi le bruit et les malentendus durant les revues de code. La compétence s'applique uniformément aux environnements Codex, Claude et OMP (One More Platform) et couvre plusieurs langages et frameworks : Python, Kotlin, React Web, React Native, iOS, Swift et SwiftUI. Son fonctionnement repose sur l'injection de directives précises dans le prompt de l'agent IA, l'incitant à analyser et réécrire les commentaires selon des règles prédéfinies (par exemple, éviter les commentaires triviaux, privilégier les commentaires explicatifs sur le « pourquoi » plutôt que le « quoi », et vérifier la cohérence avec le code adjacent).
npx skills add https://github.com/chonamdoo/agent-flow/tree/main/skills/comment-authoring-disciplineAppliquez des critères de qualité des commentaires lors de l'implémentation et lors du passage final de qualité des commentaires avant la revue finale, la revue multiple ou la revue d'architecture après des modifications de code. Applicable de manière égale dans Codex, Claude et OMP pour Python, Kotlin, React Web, React Native, iOS, Swift et SwiftUI.
This repo contains 5 individual skills — each has its own dedicated page.
Common code generation and code modification discipline for agent-flow. Use before and during implementation, TDD red/green/refactor, fix-loop, bug fixes, feature work, and any task where Codex, Claude, OMP, or another agent writes or changes code. Enforces start-before, during-implementation, and after-implementation checks without a scoring rubric.
Flutter implementation and review checklist. Use only when writing, modifying, or reviewing Flutter widget code, layout constraints, adaptive sizing, navigation and routing, platform channels, platform views, background entry points, list and image performance, async gaps across `BuildContext`, disposal, theme and design tokens, accessibility, localization, offline and error states, or Flutter test and golden coverage. Do not use for Dart language generalities, native Android or iOS internals beyond the engine and channel-registration seam a Dart entry point depends on, or broad rewrites.
Use when implementing or reviewing iOS app-wide error handling where SwiftUI views/ViewModels notify common errors and an @main App, WindowGroup AppShell, NavigationStack coordinator, or UIKit AppCoordinator owns root navigation, tab/session flow switching, alerts, sheets, toast hosts, SessionExpired handling, Maintenance handling, and root reset behavior.
Use when creating, modifying, or reviewing an iOS Clean Architecture presentation layer with SwiftUI/UIKit state holders, explicit UiState, UiModel mapping, dependency injection, and state-based presentation code review.
Synthesizes the current conversation and codebase context into a PRD, then writes or publishes it according to the caller's requested output target. Use when the user asks to turn an already-discussed idea, plan, or conversation into a PRD; use `grilling` first if key decisions are still unresolved.
ElevenLabs text-to-speech with mac-style say UX.
Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.
Capture and automate macOS UI with the Peekaboo CLI.
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".