Wrap-up de fonctionnalité avec PR

VérifiéPrudence

Finalise le développement d'une fonctionnalité en consolidant les commits, générant une description de PR et créant la demande de fusion après validation des tests.

Spar Skills Guide Bot
DevOpsIntermédiaire
04/03/2026
Claude CodeCursor
#git#pull-request#commit-squash#github-cli#code-review

Recommandé pour

Synthèse automatique

Automatise la fin d'une fonctionnalité : validation de l'environnement Git, exécution des tests, squash des commits et création d'une pull request GitHub à partir du contexte Specimin.

Points forts

  • Enchaîne un flux complet et ordonné : vérifications Git, tests, revue des changements, squash puis PR
  • Génère le message de commit et la description de PR à partir des fichiers spec.md, plan.md et implementation.md du projet
  • Bloque explicitement en cas de working tree sale, de branche principale, d'absence de commits ou de tests en échec
  • Demande une confirmation utilisateur avant le squash et affiche l'historique des commits et les fichiers modifiés

Limites

  • Dépend fortement de la structure .specimin/plans/{branche}/ et échoue si le projet n'a pas été initialisé avec /init
  • Ne cible que GitHub via le CLI gh (installation et authentification requises), pas GitLab ni Bitbucket
  • Suppose un dépôt avec une branche main ou master détectable et ne décrit aucune gestion des conflits de fusion
Quand l'utiliser

À utiliser une fois la fonctionnalité implémentée, testée et committée, quand vous voulez laver l'historique et ouvrir une PR prête pour la revue.

Quand l'éviter

Ne pas l'invoquer pendant le développement en cours, sur la branche principale, ou si les tests échouent encore ou si le dépôt n'est pas configuré pour Specimin.

Analyse de sécurité

Prudence
Score qualité80/100

The skill uses powerful tools (git history rewriting, arbitrary test execution, and GitHub CLI PR creation) but each for an explicitly stated, legitimate purpose and gated behind a user confirmation prompt before the destructive-ish squash step. There is no obfuscation, no curl|sh, no secret/token exfiltration, and no attempt to disable safety. The main residual risks are executing repo-defined test commands and irreversible-ish history squashing, both typical for a wrap-up workflow, so it fits 'caution' rather than 'risky'.

Points d'attention
  • •Executes arbitrary repository test commands (e.g., `npm test`, `pytest`, `make test`) detected from the repo, which run project-supplied scripts/code
  • •Rewrites local git history with `git reset --soft {MAIN_BRANCH}` followed by a new commit (recoverable via reflog, but history-altering)
  • •Creates a remote pull request and may trigger a push via `gh pr create`, modifying server-side state on the user's GitHub repo
  • •Uses `run_terminal_cmd` broadly across stages; no allowlisting or dry-run mode for the squash/PR steps
Comment cette analyse est faite

Exemples

Wrap up and open PR
The feature is done — wrap it up: run the tests, squash my commits into one, and open a pull request for review.
Prepare branch for review
Prepare this branch for code review with gh, using the spec and plan in .specimin to write the PR description.
Clean history before PR
Squash all my commits since main into a single conventional commit and create the pull request.

name: "specimin-wrap" description: "Squash commits and create a pull request after feature implementation is complete. Only invoke when user explicitly requests to wrap up, create a PR, prepare for review, or finish the feature." allowed-tools:

  • run_terminal_cmd
  • read_file

Feature Wrap-Up Command

Prepare completed work for code review: squash commits, generate PR description, create pull request.

Stage 1: Validate Environment

Actions:

  1. Check uncommitted changes: git status
  2. Get current branch: git rev-parse --abbrev-ref HEAD → store as CURRENT_BRANCH
  3. Detect main branch (try in order):
    git show-ref --verify --quiet refs/heads/main && echo "main" || \
    git show-ref --verify --quiet refs/heads/master && echo "master" || \
    echo "unknown"
    
    Store as MAIN_BRANCH. If "unknown", ask user: "What is your main branch name?"
  4. Verify branch is not main: If CURRENT_BRANCH == MAIN_BRANCH, error and exit
  5. Check initialization: Verify .specimin/plans/{CURRENT_BRANCH}/ exists
  6. Read feature context (for PR description generation):
    • .specimin/plans/{CURRENT_BRANCH}/spec.md
    • .specimin/plans/{CURRENT_BRANCH}/plan.md
    • .specimin/plans/{CURRENT_BRANCH}/implementation.md

Context Extraction Goals (from spec/plan):

  • Feature objective (1-2 sentence summary)
  • High-level changes by phase/component
  • Acceptance criteria
  • Testing approach

Error Handling:

  • Uncommitted changes: Warning: Uncommitted changes detected. Commit or stash before wrapping up. → Exit
  • On main branch: Error: Cannot wrap up main branch. Switch to feature branch first. → Exit
  • Not initialized: Error: Specimin not initialized. Run /init first. → Exit
  • No commits ahead: Error: No commits to squash. Branch up to date with {MAIN_BRANCH}. → Exit
  • gh not installed: Error: GitHub CLI not installed. Install: https://cli.github.com/ → Exit
  • Not authenticated: Error: Not authenticated with GitHub CLI. Run: gh auth login → Exit

Checkpoint: Verify environment valid (no uncommitted changes, on feature branch, has commits to squash) before proceeding.

Stage 2: Run Tests

Actions:

  1. Detect test framework and run appropriate test command:

    • Python: python3 -m pytest or pytest
    • JavaScript/TypeScript: npm test or yarn test
    • Ruby: bundle exec rspec or rake test
    • Go: go test ./...
    • Rust: cargo test
    • Java: mvn test or gradle test
    • Other: Check for Makefile with test target, or ask user
  2. Run tests and capture output

  3. Error Handling:

    • Tests fail: Display failure summary and exit with message:
      ✗ Tests failed. Fix failing tests before wrapping up.
      
      {test failure summary}
      
      Run tests again after fixes and retry wrap.
      
    • Tests pass: Proceed to next stage
    • No tests found: Warn user but continue:
      ⚠ No tests detected. Consider adding tests before creating PR.
      Proceed anyway? (yes/no)
      

Checkpoint: Verify all tests pass before proceeding to review changes.

Stage 3: Review Changes

Show user what will be squashed:

  1. Commit history:

    git log {MAIN_BRANCH}..HEAD --oneline
    
  2. Change summary:

    git diff {MAIN_BRANCH}...HEAD --stat
    
  3. Files changed:

    git diff {MAIN_BRANCH}...HEAD --name-only
    

Present:

I'll squash these commits into one:

[commit history]

Files changed:
[file list]

Proceed with squash and PR creation? (yes/no)

Wait for confirmation. If "no", exit gracefully.

Stage 4: Squash Commits

Once confirmed:

  1. Generate commit message:

    • Use feature objective from spec.md
    • Summarize WHAT changed (not HOW)
    • 1-2 sentences max
    • Follow conventional commits: feat:, fix:, refactor:, docs:
  2. Perform squash:

    git reset --soft {MAIN_BRANCH}
    git commit -m "{COMMIT_MESSAGE}"
    

    CRITICAL: No --author, no Co-Authored-By:, no co-authoring metadata. User authorship only.

  3. Verify squash:

    git log --oneline -1
    

    Confirm only one commit since main branch.

Checkpoint: Verify squash succeeded (single commit, correct message) before creating PR.

Stage 5: Create Pull Request

  1. Generate PR title:

    • Use commit message or feature name from spec
    • Under 72 characters
    • Clear and descriptive
  2. Generate PR description (use template below with extracted context):

## Summary

{1-2 sentence feature objective from spec.md}

## Changes

{Bulleted list of high-level changes from plan.md phases or implementation.md completed tasks}

## Testing

{Testing approach from plan.md, or manual test scenarios}

## Acceptance Criteria

{Criteria from spec.md}
  1. Create PR:

    gh pr create --title "{PR_TITLE}" --body "$(cat <<'EOF'
    {PR_DESCRIPTION}
    EOF
    )"
    
  2. Display result:

    ✓ Squashed {N} commits into 1 commit
    ✓ Created pull request: {PR_URL}
    
    Your feature is ready for review!
    

No upstream remote: gh pr create will prompt to push if needed.

Complete Examples

Example 1: Simple CRUD Feature

Spec objective: "Add user profile management allowing users to update their name and email"

Commit message:

feat: add user profile management with update functionality

PR title:

feat: add user profile management

PR description:

## Summary

Add user profile management allowing users to update their name and email through a settings page.

## Changes

- Added User schema with name and email fields
- Implemented update_user/2 function with validation
- Created ProfileLive page with edit form
- Added integration tests for profile updates

## Testing

- Unit tests: Accounts.update_user/2 with valid/invalid inputs
- Integration tests: ProfileLive form submission and validation errors
- Manual: Navigate to /profile, update name/email, verify saved

## Acceptance Criteria

- [x] Users can view current profile information
- [x] Users can update name and email
- [x] Invalid emails show validation errors
- [x] Changes persist after page refresh

Example 2: Complex Integration Feature

Spec objective: "Integrate Stripe payment processing with retry logic and webhook handling for subscription management"

Commit message:

feat: integrate Stripe payment processing with webhook support

PR title:

feat: integrate Stripe payment processing

PR description:

## Summary

Integrate Stripe payment processing with automatic retry logic for failed charges and webhook handlers for subscription lifecycle events.

## Changes

- Added Stripe client module with exponential backoff retry logic
- Implemented payment processing functions (create_charge, refund_charge)
- Created webhook handler for subscription events (created, updated, canceled)
- Added Payment schema and database migrations
- Implemented error handling for network failures and invalid cards

## Testing

- Unit tests: StripeClient module with mocked HTTP responses
- Integration tests: Payment creation flow with test API keys
- Webhook tests: Event handling for all subscription states
- Manual: Create test charge in Stripe dashboard, verify webhook receipt

## Acceptance Criteria

- [x] Charges created successfully with valid cards
- [x] Network failures retry up to 3 times with backoff
- [x] Invalid cards return clear error messages
- [x] Webhooks update subscription status in database
- [x] Payment history visible to users

Note: This prompt optimized using research-backed principles: token efficiency (-30%), verification checkpoints (Reflexion 91%), consolidated examples (2-5 optimal), explicit context extraction (CGRAG 4x improvement), and minimal preamble (GPT-5-Codex guidance).

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/feature-wrap-up-with-pull-request-mmbizjr5/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/feature-wrap-up-with-pull-request-mmbizjr5' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/feature-wrap-up-with-pull-request-mmbizjr5/download' --output '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/SKILL.md.part' && mv '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/SKILL.md.part' '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/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

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/SKILL.md' && test -s '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/specimin-wrap' && cp -R '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5' '.claude/skills/specimin-wrap'

Cursor
test -f '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/SKILL.md' && test -s '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/specimin-wrap' && cp -R '.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5' '.cursor/skills/specimin-wrap'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/feature-wrap-up-with-pull-request-mmbizjr5'

openskills read 'feature-wrap-up-with-pull-request-mmbizjr5'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

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/feature-wrap-up-with-pull-request-mmbizjr5/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