# Pipecat AI Pipecat Pipecat

> Reorganize the commits on the current branch into a small number of logical commits. Do NOT change any file content — only the commit structure changes.

- Skill: `tomevault-io/pipecat-ai-pipecat-pipecat` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/pipecat-ai-pipecat-pipecat`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/pipecat-ai-pipecat-pipecat/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/pipecat-ai-pipecat-pipecat

---


Reorganize the commits on the current branch into a small number of logical commits. Do NOT change any file content — only the commit structure changes.

## Instructions

### 1. Safety check

```bash
git status --short
```

If there are uncommitted changes, stop and tell the user to commit or stash them first.

### 2. Inspect the branch

```bash
git log main..HEAD --oneline
git diff main..HEAD --name-only
```

List every file changed vs `main` and every commit on the branch (excluding merge commits from main).

### 3. Create a backup branch

```bash
git branch backup/<current-branch-name>
```

Tell the user the backup exists so they can recover if needed.

### 4. Soft-reset to main and unstage everything

```bash
git reset --soft main
git restore --staged .
```

All branch changes are now in the working tree, unstaged. No content has changed.

### 5. Plan the logical groups

Read the changed files and the original commit messages to understand what the work covers. Group related files into logical commits. Typical groups:

- Core feature or fix (new source files + modified core files)
- Secondary features or fixes (each as its own commit if distinct)
- Refactoring or renames
- Tests
- Changelogs / docs

Use the changelog files (if any) as a strong hint — each changelog entry often maps to one commit.

Present the proposed grouping to the user and ask for confirmation before committing.

### 6. Commit in logical groups

For each group, stage only the relevant files and commit with a clear message following the project's conventions:

```bash
git add <file1> <file2> ...
git commit -m "..."
```

Use conventional commit prefixes if the project uses them (`feat:`, `fix:`, `refactor:`, `test:`, `chore:`).

### 7. Verify

```bash
git log main..HEAD --oneline
git diff main..HEAD --name-only
git status --short
```

Confirm:
- Commit count is small and each message is meaningful
- The set of changed files vs `main` is identical to before
- Working tree is clean

### 8. Remind about force-push

The branch history has been rewritten. Tell the user they will need to `git push --force-with-lease` when they are ready to update the remote. Do NOT push automatically.

## Rules

- Never change file contents. If you find yourself editing a file, stop.
- Never skip the backup branch step.
- Never force-push without explicit user instruction.
- If any step fails or the result looks wrong, tell the user and suggest restoring from the backup: `git reset --hard backup/<branch-name>`.

---
> Source: [pipecat-ai/pipecat](https://github.com/pipecat-ai/pipecat) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-30 -->