Normes Git d'Orchestrator

VérifiéSûr

Conventions Git spécifiques à Orchestrator AI : noms de branches conventionnels, commits structurés et historique propre. Essentiels pour maintenir une qualité de code et une collaboration optimales.

Spar Skills Guide Bot
DeveloppementDébutant
11/03/2026
Claude CodeCursorWindsurfCopilotCodex
#git#conventional-commits#branching#workflow#version-control

Recommandé pour

Synthèse automatique

Cette skill impose des conventions Git standardisées pour les projets Orchestrator AI : nommage des branches, format Conventional Commits et hygiène de l'historique.

Points forts

  • Fournit des listes explicites de noms de branches corrects et incorrects, faciles à appliquer
  • Couvre le cycle complet : création de branche, commit, push, puis rebase sur main
  • Inclut un tableau des types de commits (feat, fix, chore, docs, test, refactor, style, perf) avec exemples
  • Donne des exemples de bons et mauvais messages de commit avec corps détaillé

Limites

  • Se limite aux conventions Git : aucun outil d'automatisation ou de validation (hooks, lint de commit) n'est fourni
  • Les règles de nommage sont propres à Orchestrator AI et peu transposables telles quelles à d'autres organisations
  • Le document est tronqué à la section « Branch Organization » et ne détaille pas les branches de release ou hotfix
Quand l'utiliser

À utiliser dès qu'il faut créer une branche, rédiger un message de commit ou organiser le flux de travail Git d'un dépôt.

Quand l'éviter

Ne pas s'y référer pour des opérations Git avancées comme la résolution de conflits complexes, le cherry-pick ou la gestion de sous-modules, qui ne sont pas traitées.

Analyse de sécurité

Sûr
Score qualité82/100

The skill only documents Git branch naming, commit conventions, and common workflow commands. It does not instruct destructive operations, exfiltration, obfuscation, or safety-disabling behavior; Git commands shown are standard and legitimate.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Create a feature branch and commit
Create a branch for adding OAuth login to the API and commit the changes following conventional commits.
Fix a vague commit message
My last commit message was 'fix stuff'. Rewrite it as a proper conventional commit for a memory leak fix in the api service.
Rebase before opening a PR
Main has new commits since I branched. Walk me through rebasing my feature/user-authentication branch onto main and pushing it for a PR.

name: Orchestrator Git Standards description: Orchestrator AI-specific Git conventions and standards. Branch naming, commit workflow, repository organization. CRITICAL: Follow conventional branch names, use conventional commits, maintain clean git history. allowed-tools: Read, Write, Edit, Bash, Grep, Glob

Orchestrator Git Standards Skill

CRITICAL: Follow Orchestrator AI Git standards: conventional branch names, conventional commits, clean history.

When to Use This Skill

Use this skill when:

  • Creating branches
  • Making commits
  • Organizing git workflow
  • Following project Git standards

Branch Naming Standards

✅ CORRECT

feature/user-authentication
feature/add-api-endpoint
fix/login-bug
fix/memory-leak
chore/update-dependencies
chore/refactor-service
docs/update-readme
test/add-unit-tests
refactor/auth-service

❌ WRONG

❌ my-feature
❌ bugfix
❌ update
❌ feature_branch
❌ FEATURE-BRANCH
❌ feature/user authentication (spaces)

Commit Message Standards

See Conventional Commits Skill for complete format. Quick reference:

# Format
<type>(<scope>): <description>

# Examples
feat(auth): add user authentication
fix(api): resolve memory leak
chore(deps): update dependencies
docs(readme): update installation guide
test(auth): add unit tests for auth service
refactor(api): restructure service layer

Git Workflow Pattern

1. Create Branch

# From main
git checkout main
git pull

# Create feature branch
git checkout -b feature/user-authentication

2. Make Changes

# Edit files
vim apps/api/src/auth/auth.service.ts

# Stage changes
git add .

# Commit with conventional format
git commit -m "feat(auth): add user authentication service"

3. Push and PR

# Push branch
git push origin feature/user-authentication

# Open PR on GitHub
# Follow PR process (see GitHub Workflow Skill)

4. Update Branch

# If main has new commits
git checkout main
git pull
git checkout feature/user-authentication
git rebase main  # or git merge main

Commit Types

| Type | Purpose | Example | |------|---------|---------| | feat | New feature | feat(auth): add login | | fix | Bug fix | fix(api): resolve memory leak | | chore | Maintenance | chore(deps): update packages | | docs | Documentation | docs(readme): update install | | test | Tests | test(auth): add unit tests | | refactor | Refactoring | refactor(api): restructure | | style | Formatting | style: format code | | perf | Performance | perf(api): optimize query |

Scope Guidelines

Scopes should match affected areas:

# API scopes
feat(api): add endpoint
fix(api): resolve bug

# Module scopes
feat(auth): add authentication
fix(llm): resolve provider issue

# Feature scopes
feat(agents): add new agent type
fix(webhooks): resolve status tracking

Git History Best Practices

✅ DO

  • Keep commits focused (one logical change per commit)
  • Use descriptive commit messages
  • Write clear commit descriptions
  • Rebase before PR (clean history)
  • Squash commits in PR if needed

❌ DON'T

  • Don't commit unrelated changes together
  • Don't use vague commit messages
  • Don't force push to shared branches
  • Don't commit broken code
  • Don't commit secrets or credentials

Commit Message Examples

✅ Good Commit Messages

feat(auth): add JWT token authentication

- Implement JWT token generation
- Add token validation middleware
- Update auth service with token logic

fix(api): resolve memory leak in service

The service was holding references to completed requests.
Now properly cleans up after request completion.

chore(deps): update NestJS to v10

- Update @nestjs/core to 10.0.0
- Update @nestjs/common to 10.0.0
- Resolve breaking changes

❌ Bad Commit Messages

❌ fix stuff
❌ update
❌ changes
❌ WIP
❌ asdf
❌ fixed bug

Branch Organization

Main Branches

  • main - Production-ready code
  • develop - Integration branch (if used)

Feature Branches

feature/<feature-name>
# Examples:
feature/user-authentication
feature/add-metrics-dashboard

Fix Branches

fix/<fix-name>
# Examples:
fix/login-error
fix/memory-leak

Chore Branches

chore/<chore-name>
# Examples:
chore/update-dependencies
chore/refactor-service-layer

Git Commands Reference

Common Commands

# Create branch
git checkout -b feature/my-feature

# Stage changes
git add .

# Commit
git commit -m "feat(module): description"

# Push
git push origin feature/my-feature

# Update from main
git checkout main
git pull
git checkout feature/my-feature
git rebase main

# View status
git status

# View log
git log --oneline

# View changes
git diff

Repository Organization

Directory Structure

orchestrator-ai/
├── apps/
│   ├── api/          # NestJS backend
│   ├── web/          # Vue frontend
│   └── n8n/          # N8N workflows
├── storage/          # Database snapshots
├── scripts/          # Utility scripts
└── .github/          # GitHub workflows

Ignore Patterns

.gitignore should include:

  • node_modules/
  • .env
  • dist/
  • *.log
  • .DS_Store

Checklist for Git Standards

When working with Git:

  • [ ] Branch name follows convention (feature/, fix/, etc.)
  • [ ] Commit message follows conventional format
  • [ ] Commit is focused (one logical change)
  • [ ] Commit message is descriptive
  • [ ] No secrets or credentials committed
  • [ ] Code quality gates pass before commit
  • [ ] Git history is clean (rebase if needed)

Related Documentation

  • Conventional Commits: See Conventional Commits Skill
  • GitHub Workflow: See GitHub Workflow Skill
  • Quality Gates: See Quality Gates Skill
  • Worktree Lifecycle: See Worktree Lifecycle Skill

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/orchestrator-git-standards-mmlj2ocl/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/orchestrator-git-standards-mmlj2ocl' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/orchestrator-git-standards-mmlj2ocl/download' --output '.skill-downloads/orchestrator-git-standards-mmlj2ocl/SKILL.md.part' && mv '.skill-downloads/orchestrator-git-standards-mmlj2ocl/SKILL.md.part' '.skill-downloads/orchestrator-git-standards-mmlj2ocl/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/orchestrator-git-standards-mmlj2ocl/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires