finish-feature

Run verification checks, validate surgical changes, and create a PR via gh.

1|Updated Mar 3, 2026
One-click install
npx skills add https://github.com/AndreJorgeLopes/devflow --skill finish-feature-andrejorgelopes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: finish-feature
Source: https://github.com/AndreJorgeLopes/devflow/tree/main/skills/finish-feature
Command: npx skills add https://github.com/AndreJorgeLopes/devflow --skill finish-feature-andrejorgelopes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents half-finished work by ensuring a feature is verified, reviewed, and handed off through a PR while capturing what was learned during the session.

Core Features & Use Cases

  • Run the full completion pipeline: assesses the current branch state, runs devflow verification checks (or falls back to lint/build/test), and halts immediately on failures to avoid shipping broken changes.
  • Gatekeep unexpected diff changes: performs a “surgical changes” review to surface unrelated edits, adjacent refactors, or accidental improvements.
  • Prepare a clean handoff: stages, drafts a conventional-commit message for approval, pushes the branch, creates a PR, and retains key learnings using Hindsight.
  • Use Case: You’ve implemented a ticketed feature on an isolated work branch and want a reliable, repeatable way to finalize it with confidence, test evidence, and retained context for future sessions.

Quick Start

Use the finish-feature skill at the end of your feature session to verify changes, commit and open a PR, and retain the most important learnings.

Frequently Asked Questions about finish-feature

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate pull request creation with conventional commits after passing lint and build checks?

To automate pull request creation with conventional commits, you can finalize a feature by running automated verification like lint and build, staging changes, drafting a conventional commit, pushing to origin, and creating a PR via gh. The process halts immediately if checks fail, ensuring only verified changes are handed off.

What is the best way to prevent accidental or unrelated code changes from being included in a pull request?

To prevent unrelated code changes in a pull request, perform a surgical changes review before committing. This surfaces adjacent refactors or accidental edits, ensuring only the intended feature modifications are staged and pushed for review.

How does persistent memory retain feature development learnings for future git workflow sessions?

Persistent memory retains feature development learnings by capturing session context during the feature finalization process. After creating a PR, it stores key insights using Hindsight, preserving what was learned for future development sessions.

Can I use this feature finishing workflow if my git branch does not have a ticket ID?

No, you cannot use this workflow without a ticket ID. The process requires detecting a ticket ID from the current git branch to properly track and finalize ticketed feature work, preventing half-finished work from being handed off.

What happens if devflow check fails during the feature finalization pipeline?

If devflow check fails during the feature finalization pipeline, the process halts immediately to avoid shipping broken changes. It gates on failed checks, stopping the staging, committing, and PR creation steps until verification passes.

Why should I avoid merging directly to main or master when finalizing a feature?

You should avoid merging directly to main or master to ensure changes are reviewed and verified. Finalizing a feature on an isolated work branch with a PR ensures test evidence, surgical changes, and retained context before integration.