Demande un résultat, pas une commande terminal.

Trouve les fichiers en double dans mon dossier Téléchargements et montre-moi ce qui semble pouvoir être supprimé sans rien effacer avant mon accord.

Recherche dans mes dossiers autorisés les factures de cette année et organise des copies par mois.

Compare ces deux dossiers de projet et résume les fichiers qui diffèrent.

Renomme les fichiers sélectionnés avec une convention cohérente basée sur la date et le titre.

Trouve les plus gros fichiers dans ce dossier autorisé et explique lesquels semblent pouvoir être archivés.

Crée un inventaire des documents de ce dossier avec nom, type, taille et date de modification.

Inspecte ce dépôt, explique son architecture, lance les tests et identifie l’échec le plus prioritaire.

Corrige les tests en échec, rebuild l’application et vérifie le résultat dans le navigateur.

Trouve les commentaires TODO et FIXME dans mes dépôts autorisés et regroupe-les par projet.

Compare la branche actuelle avec main et résume les changements risqués avant que je push.

Trouve le code dupliqué dans ce projet et propose le refactor le plus sûr sans changer le comportement.

Trace où cet endpoint API est appelé depuis le frontend jusqu’à la couche base de données.

Ouvre l’application locale, reproduis le bug décrit, inspecte le résultat visible et rapporte ce qui échoue.

Va sur la page admin, vérifie la nouvelle interface et liste les régressions visuelles.

Ouvre l’onglet navigateur pertinent et récupère les informations dont j’ai besoin sans rien modifier.

Prends une capture de l’état actuel de l’application et explique le problème visible.

Teste ce formulaire en largeur desktop, soumets des données de test sûres et dis-moi où le parcours casse.

Ouvre la page déployée et compare le résultat visible avec la version locale.

Connecte-toi à mon serveur autorisé, vérifie l’espace disque, les services et les erreurs récentes, puis résume son état de santé.

Lis les derniers logs de déploiement et identifie la première erreur réellement exploitable.

Vérifie si le processus de l’application tourne et redémarre-le uniquement s’il est arrêté.

Inspecte l’état Git du dépôt sur le serveur avant toute action de déploiement.

Vérifie les ports ouverts et processus liés à ce projet puis signale ce qui paraît inhabituel.

Vérifie l’endpoint de santé déployé, les logs applicatifs et l’état du service sans modifier la production.

Trouve pourquoi ce service local ne démarre pas : inspecte son processus, son port, ses logs et sa configuration sans supprimer quoi que ce soit.

Vérifie ce qui utilise le plus d’espace disque dans mon dossier autorisé et propose des candidats au nettoyage.

Diagnostique pourquoi le build fonctionne localement mais échoue en production en comparant la configuration non sensible et les sorties de build.

Inspecte le navigateur, la sortie terminal et les fichiers pertinents puis donne une hypothèse de cause racine avec des preuves.

Trouve ce qui occupe le port de développement attendu et donne la façon la plus sûre de résoudre le conflit.

Vérifie les changements récents et les logs pour identifier ce qui a le plus probablement causé cette régression.

Chaque matin, vérifie l’état de mes projets autorisés et résume les builds en échec ou les services hors ligne.

Lance les tests du projet, ouvre le résultat dans le navigateur et arrête-toi seulement lorsque le parcours principal fonctionne.

Surveille ce processus long et dis-moi lorsqu’il se termine ou affiche une erreur.

Prépare une checklist de release à partir du statut Git, des tests, du build et de la vérification navigateur.

Vérifie ce service selon une fréquence définie et alerte-moi uniquement si son endpoint de santé ou son processus change d’état.

Crée un workflow pré-déploiement reproductible qui vérifie Git, les tests, le build, la santé et le parcours navigateur critique.

Montre-moi les changements non commités, explique-les et signale ce qui ne devrait pas être inclus dans un commit.

Prépare un changelog concis à partir des commits depuis le dernier tag sans créer de release.

Lance les vérifications de release du projet et dis-moi si l’arbre de travail est sûr à taguer.

Compare deux tags et regroupe les changements en fonctionnalités, correctifs, sécurité et travail interne.

Trouve les fichiers volumineux ou sensibles suivis accidentellement par Git et explique comment les retirer proprement.

Vérifie si ma branche locale et origin sont synchronisés et résume la différence.

Inspecte ces fichiers CSV, compare leurs colonnes et rapporte les incohérences de schéma.

Trouve tous les PDF dans ce dossier et crée un tableau avec nom de fichier, taille et date de modification.

Compare ces deux fichiers de configuration et explique quelles différences modifient le comportement à l’exécution.

Recherche dans ces documents autorisés les références à ce nom de client et résume les fichiers pertinents.

Trouve les rapports exportés plus anciens que cette date et liste-les avant de déplacer quoi que ce soit.

Propose une structure de dossiers propre pour ces documents de projet et présente les déplacements avant de les exécuter.

Liste les dossiers Carlos actuellement autorisés sur cette machine et explique l’exposition de chacun.

Inspecte ce dépôt pour détecter des secrets commités par erreur sans afficher la valeur des secrets.

Vérifie la configuration liée à SSH pour repérer des permissions dangereuses sans ouvrir le contenu des clés privées.

Vérifie ce projet et identifie les fichiers qui devraient probablement être ignorés par Git.

Montre quels appareils Carlos sont en ligne et lesquels devraient être révoqués selon leur inactivité.

Inspecte l’action demandée et explique de quelles permissions elle a besoin avant d’exécuter quoi que ce soit.

Lance toute la suite de tests, build l’application, ouvre le parcours utilisateur principal et rapporte chaque échec avec des preuves.

Vérifie que ces cinq URL renvoient les codes HTTP et titres de page attendus.

Vérifie les balises canonical, les directives robots et la présence dans le sitemap pour ces pages publiques.

Ouvre la page responsive et inspecte la mise en page critique en desktop et en largeur réduite.

Valide les liens de téléchargement de l’installateur et confirme que les fichiers renvoient un statut HTTP réussi.

Lance un smoke test sur l’endpoint MCP de production et confirme que la découverte des outils fonctionne toujours.

Recherche dans cette base de code toutes les implémentations de cette fonctionnalité et explique laquelle est réellement active.

Trouve toute la configuration liée à ce fournisseur et cartographie où chaque valeur est utilisée.

Inspecte les fichiers de packages et indique quelles dépendances sont inutilisées ou dupliquées.

Trouve les points d’entrée de l’authentification et résume le parcours complet login/session.

Cartographie toutes les routes de ce projet et identifie les surfaces publiques, authentifiées et réservées aux admins.

Trace le parcours complet d’un appel d’outil Carlos Remote depuis la requête MCP jusqu’à l’appareil sélectionné.