Starter Harness Designer — Coding v1

Que fait Starter Harness Designer — Coding v1 ?

« Ce que l'agent n'a pas accompli n'était pas dû à un manque de compétence, mais à un environnement insuffisant. »

À qui s'adresse ce skill ?

• Personnes créant leur premier coding harness
• Non-développeurs / juniors voulant constituer une équipe de développement
• Personnes souhaitant démarrer rapidement avec des modèles fullstack, API ou ML éprouvés

Ce skill conserve la même philosophie en 3 étapes (Planner → Generator → Evaluator) que le skill expert harness-designer-coding, mais en adaptant la complexité des entrées et la précision des sorties au niveau débutant.

Étape	Version Expert	Starter (ce skill)
Planner	Découverte en 4 étapes, questions ouvertes	3 questions à choix multiple → correspondance avec un numéro d'exemplar
Generator	Conception → génération fichiers/structure	Clonage d'exemplar + substitution
Evaluator	Vérification indépendante sur 8 piliers	Checklist légère — substitutions manquantes, références cassées uniquement

---

Matrice des skills

              │ Expert (conception libre)            │ Débutant (clonage d'exemplar)
──────────────┼─────────────────────────────────────┼────────────────────────────────────
 Workspace    │ harness-designer-workspace          │ harness-starter-workspace
──────────────┼─────────────────────────────────────┼────────────────────────────────────
 Codage       │ harness-designer-coding             │ harness-starter-coding ★ (ce skill)

Quand ne PAS utiliser ce skill :

• Création de documents, analyses, contenu → utiliser harness-starter-workspace
• Utilisateurs avancés ayant besoin de flexibilité architecturale → utiliser harness-designer-coding
• Microservices d'entreprise → utiliser le skill enterprise

---

Flux d'exécution (5 à 10 minutes au total)

1. [Planner] 3 questions à choix multiple (type d'app, nature des données, échelle)
2. [Planner] Correspondance avec un numéro d'exemplar + recommandation du mode d'échelle + suggestion de préréglage
3. [Generator] Clonage de l'exemplar depuis harness-100
4. [Generator] Substitution du nom du projet, de la stack technique, des termes du domaine
5. [Evaluator] Checklist légère (10 secondes)
6. Notification de fin (« Vous pouvez maintenant développer comme ceci »)

---

Phase 0 : Correspondance de motifs (Planner)

Question 1 — Que voulez-vous créer ? (Choix multiple)

N°	Type d'application	Exemplar représentatif
1	🌐 Application web fullstack (frontend+backend+BDD)	#16-fullstack-webapp
2	🔌 Serveur API uniquement	#18-api-designer
3	📱 Application mobile (iOS/Android)	#17-mobile-app-builder
4	🗃️ Pipeline de données / ETL	#27-data-pipeline
5	🤖 Application AI/LLM / RAG	#41-llm-app-builder
6	🧪 Expérimentation ML / entraînement de modèles	#31-ml-experiment
7	🎨 Système de design (basé shadcn)	#36-design-system
8	🔐 Audit de sécurité / test d'intrusion	#28-security-audit
9	🚀 CI/CD / Infrastructure uniquement	#20-cicd-pipeline
10	♻️ Modernisation / refonte de legacy	#22-legacy-modernizer

Question 2 — Quelle est l'échelle ? (Choix multiple → détermine automatiquement le Mode d'échelle)

Échelle	Mode d'échelle	Agents déployés
MVP / prototype solo	Single	1 seul agent, le plus essentiel
Petite équipe / moins d'1 mois	Reduced	3 agents (architecte + développeur principal + QA)
Équipe moyenne ou plus / production	Full	5 agents (architecte + frontend + backend + QA + DevOps)

Question 3 — Quel est le nom du projet ?

Basé sur le nom du dossier. La stack technique n'est pas demandée — la stack par défaut de l'exemplar est conservée (l'utilisateur pourra la changer plus tard si nécessaire).

Stacks par défaut (conservées sans modification) :

• Fullstack : Next.js + Prisma + SQLite
• API : FastAPI ou Express
• Mobile : React Native (Expo)
• Données/ML : Python + pandas + scikit-learn
• RAG : Next.js + Vercel AI SDK + pgvector

Question 4 — Voulez-vous garder un historique des modifications ? (Optionnel, oui/non)

« Souhaitez-vous créer un espace pour enregistrer ce qui a changé et pourquoi lorsque vous améliorerez ce harness plus tard ? »

• oui → Création automatique d'un wiki 05-flow-history/ + fichier 00-system/protocols/flow-change-protocol.md (la construction initiale est enregistrée comme change 0001). Référence : ~/.claude/skills/harness-designer-workspace/references/flow-history-template.md
• non → Pas de création (ajout manuel possible plus tard)

Objectif : rétrospective d'amélioration du flux, justification en cas de rollback, référence pour créer d'autres harness similaires. Pour un prototype de 1 à 2 semaines, non recommandé.

Principe de gestion : Cet historique enregistre uniquement les changements dans le système de workflow (prompts, protocoles, templates, commandes, CLAUDE.md). Les artefacts produits par le système (code, résultats de build, logs de déploiement) ne sont pas concernés. Critère de distinction : « Si ce changement n'avait pas eu lieu, le résultat de la prochaine exécution serait-il différent ? » → Oui = changement système = enregistrer / Non = artefact = pas d'enregistrement nécessaire Détails : 00-system/protocols/flow-change-protocol.md

---

Phase 1 : Choix du préréglage (pondération de l'évaluation)

Préréglage	Description	Recommandation automatique
[Équilibré] (par défaut)	Tous les critères de qualité à poids égal	Valeur par défaut
[Qualité prioritaire]	Pondération ×2 pour OWASP, tests, Reviewer	Audit de sécurité, paiement, médical, finance
[Vitesse prioritaire]	Scale=Single, tests minimisés	Hackathon, prototype solo

Le choix est enregistré dans _workspace/00_input.md.

---

Phase 2 : Générateur — Clonage et substitution de l'exemplar

Étapes de clonage (fallback automatique)

Détection automatique de la présence de gh pour télécharger de manière optimale. Fonctionne également avec git seul.

EXEMPLAR="{NN}-{exemplar-name}"   # Résultat de la correspondance du Planner (ex: 16-fullstack-webapp)
BASE="ko/$EXEMPLAR/.claude"

if command -v gh &>/dev/null && gh auth status &>/dev/null 2>&1; then
  # ── Méthode A : GitHub CLI (gh) ──────────────────────────────
  echo "📡 Téléchargement via gh api..."
  FILES=$(gh api "repos/revfactory/harness-100/git/trees/main?recursive=1" \
    --jq ".tree[] | select(.path | startswith(\"$BASE/\")) | select(.type==\"blob\") | .path")
  mkdir -p .claude/agents .claude/skills
  while IFS= read -r filepath; do
    rel="${filepath#$BASE/}"
    dest=".claude/$rel"
    mkdir -p "$(dirname "$dest")"
    gh api "repos/revfactory/harness-100/contents/$filepath" \
      --jq '.content' | base64 -d > "$dest"
    echo "  ✅ $dest"
  done <<< "$FILES"
else
  # ── Méthode B : git sparse checkout (quand gh n'est pas disponible) ─────────────
  echo "📡 Téléchargement via git sparse checkout..."
  TMP=$(mktemp -d)
  git clone --depth 1 --filter=blob:none --sparse \
    https://github.com/revfactory/harness-100.git "$TMP"
  git -C "$TMP" sparse-checkout set "$BASE"
  mkdir -p .claude
  cp -r "$TMP/$BASE/." .claude/
  rm -rf "$TMP"
  echo "  ✅ sparse checkout terminé"
fi

Condition	Méthode utilisée	Outil nécessaire
gh installé + connecté	Méthode A (gh api)	gh
Seulement git disponible	Méthode B (sparse checkout)	git
Les deux absents ou échec	Méthode C (après confirmation utilisateur, génération directe par Claude)	Aucun

Si les méthodes A et B échouent, Claude guide directement l'utilisateur :

⚠️ Impossible de récupérer le modèle depuis GitHub.

Cause : gh et git sont indisponibles ou la connexion Internet est absente.

Dans ce cas, Claude peut écrire directement les fichiers du harness en se référant à la description de l'exemplar. Cependant, il ne s'agit pas d'un modèle réellement validé, mais d'une reproduction de la structure par Claude, la qualité peut donc varier.

Souhaitez-vous continuer ?

• Oui → Claude génère directement les fichiers .claude/ (basé sur exemplar-index.md)
• Non → Arrêt ici. Veuillez réessayer après avoir installé git ou rétabli la connexion Internet.

Si l'utilisateur choisit Oui : lire la description de l'exemplar correspondant dans references/exemplar-index.md et écrire directement la structure CLAUDE.md, agents/, skills/. Si l'utilisateur choisit Non : arrêt immédiat, guide pour réessayer.

Une fois terminé, la structure obtenue est :

.claude/
├── CLAUDE.md
├── agents/
│   ├── architect.md        — Conception des exigences, architecture, BDD, API
│   ├── frontend-dev.md     — React/Next.js (supprimé selon Scale)
│   ├── backend-dev.md      — API, BDD, Auth
│   ├── qa-engineer.md      — Tests, revue de code (Reviewer)
│   └── devops-engineer.md  — CI/CD, Infrastructure (supprimé selon Scale)
└── skills/
    ├── {orchestrator}/skill.md
    ├── component-patterns/skill.md
    └── api-security-checklist/skill.md

3. Supprimer les fichiers d'agents selon le Mode d'échelle :
   • Single → garder uniquement l'architecte (ou 1 seul agent le plus pertinent)
   • Reduced → garder architecte + développeur principal + QA
   • Full → garder les 5 agents
4. Créer le dossier _workspace/. Convention de numérotation des artefacts :
   • 00_input.md — Entrée utilisateur organisée
   • 01_architecture.md — Conception architecturale
   • 02_api_spec.md — Spécification API
   • 03_db_schema.md — Schéma de base de données
   • 04_test_plan.md — Plan de test
   • 05_deploy_guide.md — Guide de déploiement
   • 06_review_report.md — Rapport de revue

Règles de substitution

Original	Substitution	Remarque
Nom du harness	Nom du projet utilisateur	16-fullstack-webapp → mon-app-todo
Stack technique (Next.js/Prisma etc.)	Conserver par défaut	Remplacer uniquement si l'utilisateur le spécifie
Mots-clés de déclenchement	Mots-clés du domaine	« todo app » → mot-clé du projet
_workspace/NN_*.md	Conserver	Ne jamais modifier la convention de numérotation
Injections OWASP/SOLID/DORA	Toujours conserver	Cœur de l'expertise domaine
Tableau des Modes d'échelle	Conserver	Préserver les définitions Full/Reduced/Single
Protocole SendMessage	Conserver	Mécanisme de communication entre agents

Principes de comportement des agents de codage (inspirés de Karpathy, insertion obligatoire)

Après le clonage de l'exemplar, ajouter obligatoirement la section suivante à la fin de .claude/CLAUDE.md (ne pas substituer, à préserver) :

## Principes de comportement des agents de codage (inspirés de Karpathy)

Tout agent de codage respecte les 4 principes suivants pendant son travail.
Les détails se trouvent dans le skill karpathy-guidelines (déclenchement automatique).

1. Think Before Coding — Énoncer les hypothèses, questionner en cas d'ambiguïté, proposer des alternatives
2. Simplicity First — Faire uniquement ce qui est demandé. Pas d'abstraction ou de fonctionnalité spéculative.
3. Surgical Changes — Modifier uniquement les lignes demandées. Pas d'amélioration du code environnant.
4. Goal-Driven Execution — Critères de succès vérifiables → boucle → vérification.

Ajouter l'élément « Section des 4 principes Karpathy dans CLAUDE.md » à la checklist légère de l'Evaluateur.

Liste des éléments à ne pas substituer

• Noms de frameworks : OWASP Top 10, SOLID, DDD, Test Pyramid, DORA Metrics, CWE Top 25, Star/Snowflake Schema, SHAP/LIME, Great Expectations
• Protocoles : SendMessage, TaskCreate, TaskUpdate
• Conventions de dossiers : _workspace/, src/, préfixes numérotés
• Définitions des Modes d'échelle
• Structure des 3 scénarios de test (Normal / Existing / Error)
• Corrections automatiques bkit : les 4 principes Karpathy, OWASP Top 10, DORA Metrics, Modes d'échelle ne doivent pas être modifiés par les propositions des agents bkit (code-analyzer, pdca-iterator, etc.)
• Éléments de boucle : critères d'achèvement (condition de sortie), ordre de revue du Reviewer (qa-engineer), format de décision du review_report — ne pas substituer ni supprimer (une boucle nécessite Objectif + Vérification + Condition de sortie pour exister)

Vulgarisation des termes (pour expliquer à l'utilisateur)

Terme technique	Explication simple
architect	Concepteur·trice
frontend-dev	Développeur·se frontend
backend-dev	Développeur·se backend
qa-engineer	Relecteur·trice qualité
devops-engineer	Responsable déploiement
Dependency DAG	Ordre des tâches
Scale Mode	Taille de l'équipe

Les fichiers internes conservent les termes techniques, seules les conversations avec l'utilisateur utilisent les termes simplifiés.

---

Phase 3 : Évaluateur — Checklist légère

Vérifications automatiques (10 secondes)

• .claude/CLAUDE.md existe
• Le nombre de fichiers agents/ correspond au Mode d'échelle (Single=1, Reduced=3, Full=5)
• Le rôle de Reviewer (qa-engineer) est inclus
• skills/<orchestrateur>/skill.md existe
• Au moins 1 skill agent-extending (component-patterns ou api-security-checklist) est présent
• Le dossier _workspace/ + les modèles d'artefacts numérotés ont été créés
• Les noms de frameworks (OWASP, SOLID, etc.) sont préservés (vérifier le nombre d'occurrences originales via grep)
• La section Trigger Boundaries should-NOT existe
• Le tableau des Modes d'échelle existe
• La section des 3 scénarios de test (Normal / Existing / Error) existe
• 0 occurrence du nom original de l'exemplar (ex : 16-fullstack-webapp) subsiste
• (Si question 4 = oui) Le dossier 05-flow-history/ + le fichier 00-system/protocols/flow-change-protocol.md ont été créés
• Le skill.md de l'orchestrateur contient des critères d'achèvement vérifiables (condition de sortie)
• L'artefact du Reviewer (review_report) inclut un format de décision (réussite / modifications nécessaires)

En cas d'échec

• Substitution manquante → le Planner repose la question
• Perte de framework → re-clonage de l'exemplar puis nouvelle substitution
• 3 échecs → proposer de basculer vers la version experte harness-designer-coding

---

Phase 4 : Notification de fin (rapport simplifié pour non-développeur)

✅ Le coding harness est prêt !

📁 Emplacement : /mon-projet-app/.claude/
👥 Équipe de développement (mode Reduced, 3 personnes) :
   - Concepteur·trice (architect) : Conception BDD, API, architecture
   - Développeur·se backend : Next.js API + Prisma
   - Relecteur·trice qualité (QA) : Tests, revue de code

🛠️ Stack par défaut : Next.js + Prisma + SQLite (remplaçable)

🚀 Utilisation :
   1. Dans Claude Code, demandez « Crée la fonction de connexion pour l'app Todo »
   2. L'équipe travaille dans l'ordre :
      Concepteur·trice → Développeur·se backend → Relecteur·trice qualité
   3. Résultats : _workspace/01_architecture.md ~ 06_review_report.md
   4. Code source : créé dans le dossier src/

🔒 Sécurité et qualité intégrées :
   - Checklist OWASP Top 10 appliquée automatiquement
   - Revue de code basée sur les principes SOLID
   - 3 scénarios de test (Normal, Fichier existant, Erreur)

🔄 Fonctionnement de l'équipe (boucle) :
   L'équipe fonctionne selon une boucle « Objectif → Implémentation → Vérification → Terminé si OK ».
   Le dernier rapport du relecteur·trice qualité (06_review_report.md) est le résultat de validation.
   Si le résultat ne vous convient pas, refaites une demande spécifique —
   ce jugement final est votre rôle (boucle externe).

📘 Prochaines étapes :
   - Pour passer à 5 personnes, ajoutez les responsables frontend et déploiement (mode Full)
   - Pour une personnalisation avancée, utilisez le skill harness-designer-coding

---

Références

• exemplar-index.md — Index des 27 exemplars de codage + Modes d'échelle + frameworks
• Original : https://github.com/revfactory/harness-100 (Apache-2.0)
• Variante experte : harness-designer-coding
• Variante workspace : harness-starter-workspace