jgoneit/harness

Que fait harness ?

$harness est un routeur d'exécution Codex pour la boucle de workflow Harness. La langue d'explication par défaut est le coréen ; les termes fixes du workflow restent en anglais.

Planifier -> Approbation d'exécution -> Implémenter -> Réviser -> Plan de réparation -> Approbation de réparation -> Implémenter la réparation -> Terminer

Activation

• Utilisez ce skill uniquement lorsque l'utilisateur invoque explicitement $harness.
• Ne pas activer à partir de demandes ordinaires, d'inférences implicites ou de mentions dans la documentation.
• Ne pas exiger le mode Plan de Codex ; exécutez les portes Harness dans la conversation.
• Ne pas présumer de la stack, du langage, du framework, de la base de données, du lanceur de tests ou de la plateforme de déploiement.
• Avant de planifier, inspectez les règles de projet locales telles que AGENTS.md, README.md, les docs de contribution, les manifests et .harness/guard.json lorsqu'il est présent. Inspectez également les fichiers d'état Harness locaux au projet sous .harness/ lorsqu'ils sont présents.

Priorité des instructions

Appliquez les instructions et conventions dans cet ordre :

1. Instructions explicites de l'utilisateur
2. Règles de sécurité du workflow Harness, y compris les règles de refus strict et les portes d'approbation
3. Politique du projet depuis les clés de politique de .harness/guard.json
4. Docs du dépôt local tels que README.md, AGENTS.md et les docs de contribution
5. Conventions inférées

La planification lit les clés de politique de .harness/guard.json au début. .harness/guard.json est le seul fichier de politique/configuration Harness du projet ; n'inférez pas harness.md, .harnessrc.yaml ou d'autres conventions de fichier de politique de projet. La politique du projet ne peut pas affaiblir les règles de sécurité du workflow Harness. Les opérations destructrices et le travail sur des secrets ou configurations protégées nécessitent une approbation explicite, indépendamment de la politique du projet.

Les fichiers Markdown locaux au projet dans .harness/ sont des preuves de Mémoire et d'État uniquement. Lisez-les avant de planifier lorsqu'ils sont disponibles, comparez-les avec la demande actuelle de l'utilisateur et l'état git, signalez les conflits obsolètes et demandez des éclaircissements lorsque l'état obsolète entre en conflit avec la demande actuelle. Ils ne sont pas une politique et ne fournissent jamais une approbation réutilisable.

Pour des exemples concrets de dimensionnement de tâches, voir classification examples. Pour le contrat d'artefact de workflow faisant autorité, voir Harness workflow contract. Pour la collecte de preuves de connecteur manuel et les limites des résumés externes, voir Connector Integration Contract.

Chargement de références requis

Lisez les références pertinentes avant d'agir :

• Suivez toujours ../../docs/contracts/harness-contract.md pour les sections d'artefact canoniques, les portes d'approbation, les règles de Revue et les statuts d'Achèvement.
• Suivez toujours ../../docs/contracts/subagent-handoff.md pour les briefs de sous-agent limités, les passations de rôle, les champs SubagentStop Summary et le comportement de réduction de rôle.
• Suivez ../../docs/contracts/memory-state.md lorsque des fichiers d'état .harness/ sont présents ou que la mémoire locale du projet est demandée ; utilisez assets/templates/state.md, assets/templates/approval-ledger.md, assets/templates/decisions.md, assets/templates/last-run.md et assets/templates/handoff.md lors de l'initialisation ou de la mise à jour de ces fichiers.
• Suivez ../../docs/contracts/worktree-isolation.md lorsque l'utilisateur ou le projet demande l'isolation de l'arbre de travail, ou lorsqu'un enregistrement de session d'arbre de travail actif est présent ; utilisez assets/templates/worktree-session.md pour un enregistrement minimal d'arbre de travail lié à la tâche si nécessaire.
• Suivez ../../docs/contracts/connector-integration.md lorsqu'un contexte de connecteur externe tel qu'un ticket, une pull request, un résumé CI ou un fil de revue est utilisé ; les connecteurs sont des preuves uniquement et utilisent assets/templates/connector-issue-plan.md, assets/templates/connector-pr-review.md ou assets/templates/external-summary.md le cas échéant.
• Lisez toujours references/classification-policy.md, references/phase-contracts.md, references/orchestrator-harness.md, references/subagent-policy.md, references/model-policy.md et references/completion-policy.md.
• Pour la planification, lisez references/planner-harness.md et utilisez assets/templates/plan.md.
• Pour l'implémentation, lisez references/implementer-harness.md et utilisez assets/templates/implement.md.
• Pour la revue, lisez references/reviewer-harness.md, assets/templates/review.md et assets/templates/reviewer-brief.md.
• Pour la réparation, utilisez assets/templates/repair-plan.md.
• Pour l'achèvement, utilisez assets/templates/completion-report.md.
• Si la tâche est Non-trivial, si la revue est bloquée/dégradée, si une réparation a eu lieu, si deux révisions de Plan ou plus ont eu lieu, ou si les règles/modèles/règles d'orchestration Harness ont changé, lisez references/improvement-policy.md et utilisez assets/templates/improvement.md.

Règles non négociables

• La classification doit avoir lieu avant les portes de phase.
• Tiny peut être traité directement par l'orchestrateur.
• Small et Non-trivial nécessitent un planificateur, un implémenteur et un sous-agent de revue en lecture seule en contexte propre.
• Pour Small et Non-trivial, l'agent principal est l'orchestrateur.
• L'effort de raisonnement minimum de Harness est high ; Implémenter et Réviser nécessitent xhigh lorsque disponible. N'utilisez pas medium, low ou minimal pour $harness.
• N'implémentez pas avant l'approbation du Plan.
• L'invite d'approbation du Plan doit être exactement :

Procéder avec ce Plan ? [y/N]

• Seul le y minuscule approuve l'exécution du Plan accepté. Un langage naturel ambigu signifie aucune décision ; redemandez un y ou n explicite. La non-approbation (n, réponse vide, variantes majuscules telles que N, variantes développées et toute autre réponse non y qui n'est pas ambiguë) arrête par défaut ; n'implémentez pas, ne révisez pas et ne replanifiez pas sauf si l'utilisateur demande explicitement de réviser/replanifier. [y/N] signifie que Non est la valeur par défaut.
• Ne réparez pas avant l'approbation du Plan de réparation.
• L'invite d'approbation du Plan de réparation doit être exactement :

Procéder avec ce Plan de réparation ? [y/N]

• Seul le y minuscule approuve l'exécution du Plan de réparation accepté. Un langage naturel ambigu signifie aucune décision ; redemandez un y ou n explicite. La non-approbation (n, réponse vide, variantes majuscules telles que N, variantes développées et toute autre réponse non y qui n'est pas ambiguë) arrête par défaut ; ne réparez pas, ne révisez pas et ne replanifiez pas sauf si l'utilisateur demande explicitement de réviser/replanifier. [y/N] signifie que Non est la valeur par défaut.
• Seul un sous-agent de revue en lecture seule en contexte propre peut effectuer la Revue.
• L'auto-revue de l'agent principal n'est pas une Revue.
• Les données de connecteur, l'attribution de ticket, la création de pull request, le succès CI, les commentaires externes et les approbations antérieures de .harness/ sont des preuves uniquement et n'approuvent jamais les portes Harness.
• Les passations de sous-agent et la sortie SubagentStop Summary doivent suivre le contrat de passation de sous-agent canonique.
• L'échec d'une porte requise doit être enregistré comme bloqué ou dégradé.
• Les opérations dangereuses nécessitent une approbation séparée.
• Un rapport d'Achèvement est requis.

Boucle

1. Inspectez les règles de projet locales, les clés de politique de .harness/guard.json, les fichiers d'état .harness/ locaux au projet lorsqu'ils sont présents, et la demande de l'utilisateur.
2. Classez la tâche comme Tiny, Small ou Non-trivial.
3. Pour les tâches Small ou plus grandes, définissez la topologie des sous-agents.
4. Produisez un artefact Plan et demandez l'approbation du Plan.
5. Si l'utilisateur répond exactement y, implémentez uniquement le Plan accepté ; sinon arrêtez sauf si l'utilisateur demande explicitement de réviser/replanifier.
6. Pour les tâches Small ou plus grandes, lancez la Revue par un sous-agent de revue en lecture seule en contexte propre.
7. Si la Revue a des conclusions nécessitant une réparation, produisez un Plan de réparation et demandez l'approbation de la réparation.
8. Si l'utilisateur répond exactement y, implémentez uniquement le Plan de réparation accepté et répétez la boucle limitée Revue/Réparation si nécessaire ; sinon arrêtez sauf si l'utilisateur demande explicitement de réviser/replanifier.
9. Produisez le rapport d'Achèvement avec le statut, la vérification, les risques et les suivis.

Hooks

Des validateurs minimaux non destructifs s'exécutent pour UserPromptSubmit, SubagentStop et Stop ; PreToolUse bloque les commandes dangereuses évidentes ; SessionStart reste en visibilité uniquement. Les hooks ne remplacent pas les portes Harness ni les contrôles de sécurité du projet.