dev-loop

{
  "name": "dev-loop",
  "displayName": "Dev Loop: Fix, Commit and Ship",
  "description": "Three commands for the daily loop in Claude Code: fix a bug or apply a review report, commit with pre-flight checks, or run review, fix and commit as one flow, pausing after the review for your go-ahead.",
  "version": "1.3.1",
  "author": {
    "name": "Ivan Misic",
    "url": "https://ivanmisic.net"
  },
  "homepage": "https://ivanmisic.net/toolshed/plugins/dev-loop",
  "repository": "https://github.com/imisic/claude-marketplace",
  "license": "MIT",
  "keywords": [
    "git",
    "commit",
    "conventional-commits",
    "code-review",
    "debugging",
    "bug-fixing",
    "developer-workflow"
  ],
  "documentationUrl": "https://github.com/imisic/claude-marketplace/tree/main/plugins/dev-loop#readme",
  "privacyPolicyUrl": "https://github.com/imisic/claude-marketplace/tree/main/plugins/dev-loop#privacy",
  "supportUrl": "https://github.com/imisic/claude-marketplace/issues",
  "termsOfServiceUrl": "https://github.com/imisic/claude-marketplace/blob/main/LICENSE"
}

# dev-loop changelog

## 1.3.1

Clearer name, description and keywords for the plugin directory. The README now opens by saying plainly what the plugin does and for whom, and its privacy section separates what the plugin does from how Claude itself handles your conversation. Skill descriptions reworded for accuracy; no behaviour changes. `/ship` is now described correctly: it pauses once, after the review, not before every step.

## 1.3.0

`/fix` now runs a sanity check on every file it changed in a batch before calling it fixed, applies answers the review report already recorded instead of asking again, and ends with open questions as short choices with a recommendation rather than a list you have to answer in free text.

`/ship` no longer asks its own round of questions at the end. Review and fix already asked theirs, so it carries those answers into the final report and only asks when the commit step turns up something new.

## 1.2.0

The skills in this plugin now carry an `agents/openai.yaml` sidecar, so they show up in Codex's skill picker with a proper name and one-line description instead of a raw folder name. All three are explicit-only in Codex as well, matching `disable-model-invocation` on the Claude Code side.

## 1.1.0

`fix`, `commit`, and `ship` are now yours to invoke only. Each one commits, deploys, or rewrites code, and none of that should start because a model judged the moment right. Their descriptions are one line each, written to be read off the slash-command menu rather than to trigger anything.

## Earlier

1.0.0 and before predate this file. See the git history at https://github.com/imisic/claude-marketplace.

# dev-loop

dev-loop gives developers three commands for the daily loop in Claude Code. `/fix` traces a bug through your code's layers, or applies a pasted review report by severity. `/commit` checks for secrets and unwanted files, then commits your selected changes with a Conventional Commits message. `/ship` runs your project's review skill, fixes what it finds and commits, pausing after the review for your go-ahead. None of them assumes a language or framework; each layers your project's own conventions on a general method.

Once it is listed, you can also add it from Anthropic's plugin directory: **Customize > Plugins** in claude.ai, or `/plugin` in Claude Code.

## Commands

| Command | Does |
|-|-|
| `/fix` | Debug a single bug by tracing it through your architecture's layers, or batch-apply a review report by severity |
| `/commit` | Pre-flight checks, sensitive-file gate, conventional commit message, files staged individually |
| `/ship` | Chains review, fix, and commit, pausing after the review for your go-ahead |

`fix` and `commit` need no setup. `ship` calls the project's review skill, so it pairs with `a-review-optimizer` (in the dev-workflow-forge plugin), which generates one tuned to your stack.

All three commit, deploy, or rewrite code, so all three wait for you to type them. Claude never decides on its own that a change looks ready to ship.

## Examples

- `/fix the login form returns 500 when the email has a plus sign`
- `/fix` followed by a pasted review report (batch mode: it reads the severity markers and file:line table and applies Critical first)
- `/ship --no-commit` (runs your review, fixes what it finds, and stops before committing so you can look)

## Privacy

Everything runs on your machine, inside the repository you are working in. The skills read your code and git state, edit files you approve, and run your project's own checks and git commands. `/commit` pushes only when you explicitly ask it to. The plugin itself collects nothing and sends nothing anywhere, and there is no telemetry. Your conversation with Claude is processed by Anthropic under its usual terms; that is separate from the plugin. Retention: the plugin's author never receives any of it, and the only thing kept is what the plugin writes in your own project, which you can delete at any time.

## Support

Questions, bugs or a security concern: open an issue at https://github.com/imisic/claude-marketplace/issues, or email hello@ivanmisic.net.

## Install

```
/plugin marketplace add imisic/claude-marketplace
/plugin install dev-loop@imisic
```

The longer write-up lives on the storefront: [ivanmisic.net/toolshed/plugins/dev-loop](https://ivanmisic.net/toolshed/plugins/dev-loop).

---
name: commit
description: Check for secrets and unwanted files, then commit the selected changes with a Conventional Commits message.
disable-model-invocation: true
---

# Git Commit

Create a clean, well-structured commit. Generic across stacks; add your own project-specific sensitive paths and commit conventions on top of the checks below.

## Phase 1: Pre-flight Checks

Run these in parallel to assess the working tree:

```bash
git status
git diff --stat
git log --oneline -5
```

Never use `git status -uall` on a large repo. It can exhaust memory scanning untracked files.

### Sensitive File Scan

Scan the diff and untracked files for:

- `.env` files, `*.pem`, `*.key`, credential files, private keys, API secrets
- Hardcoded secrets or tokens in the diff itself (`key = "..."`, `password = "..."`, connection strings with embedded credentials)
- Scratch/experiment directories that shouldn't ship (`_debug/`, `_test/`, or whatever your project uses for throwaway work)

Tell the user to extend this list with their own project's sensitive paths (a secrets directory, a local config file, a vendor-specific credentials format). The checks above are a floor, not a ceiling.

### Gating Rules

**BLOCK (stop immediately, show what was found):**
- `.env` files or equivalent in the diff
- `*.pem`, `*.key`, or other credential files
- A literal secret, API key, or private key hardcoded in a tracked file
- Files inside a scratch/experiment directory

**WARN (show the warning, ask to confirm before proceeding):**
- Large, unrelated changes spanning many files (suggest splitting into multiple commits)
- A generated or build artifact changed without its source changing (stale build, or someone hand-edited output)
- Leftover debug logging outside scratch dirs (`console.log`, `print`, `var_dump`, `dd`, or your language's equivalent)

If blocked, explain what was found and stop. Do not stage or commit.

## Phase 2: Analyze Changes

Determine commit type from the diff:

| Type | When |
|-|-|
| `feat` | New feature or capability |
| `fix` | Bug fix |
| `refactor` | Code restructuring, no behavior change |
| `style` | Formatting, whitespace, no logic change |
| `docs` | Documentation only |
| `chore` | Build, config, dependency, maintenance |
| `perf` | Performance improvement, no behavior change |
| `test` | Test-only changes |

Determine scope from which area of the codebase changed (a directory, module, or feature name that makes the subject line legible at a glance).

## Phase 3: Draft Commit Message

Format: `type(scope): subject`

- Subject: imperative mood, 50 characters or less ("add" not "added")
- Body (optional, after a blank line): explains **why**, not what the diff already shows
- Body wraps at a reasonable width, HEREDOC preserves it exactly
- If the user supplied a message, use it but conform it to this format

Good: `fix(auth): reject expired tokens before session lookup`
Bad: `fix: fixed the auth bug that was happening`

## Phase 4: Stage Files

**Never `git add .` or `git add -A`.** Stage files individually by name.

For each candidate file, decide:
- Stage it if it's part of this commit's actual purpose
- Skip unrelated changes (suggest a separate commit)
- Skip generated/build artifacts that should be produced by the build step, not hand-committed
- Skip anything the sensitive-file scan flagged

## Phase 5: Create Commit

Use a HEREDOC so formatting survives shell quoting:

```bash
git commit -m "$(cat <<'EOF'
type(scope): subject line here

Optional body explaining why this change was made.

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
```

Only add the `Co-Authored-By:` trailer if your workflow wants one, and keep it generic. Do not hardcode a specific session, model version, or author identity into a shipped skill.

## Phase 6: Verify

Run `git status` after the commit to confirm a clean tree or show what's left uncommitted.

## Rules

- Never commit code you know is broken. If unsure, ask.
- Never use `--force` or `--no-verify`.
- Never amend an existing commit unless explicitly asked.
- If a pre-commit hook fails: the commit did not happen, so fix the issue, re-stage, and create a NEW commit. Do not amend (there is nothing to amend yet).
- Never push unless explicitly asked.

## Workflow Chain

After a clean commit, suggest running your project's deploy step if the change looks feature-complete or is a ready bug fix.

interface:
  display_name: "Commit"
  short_description: "Pre-flight checks, then a conventional commit"
policy:
  allow_implicit_invocation: false

---
name: fix
description: Diagnose and fix a bug, or apply fixes from a review report in severity order.
disable-model-invocation: true
---

# Debug and Fix

Fix bugs and review findings while staying inside the project's own patterns. This skill has no built-in bug catalog for any specific stack; it teaches a method, not a list of known errors, because that list is different for every codebase.

## Input

$ARGUMENTS

## Mode Detection

- If arguments contain severity markers (Critical, High, Medium, Low) or a file:line table: **Batch Mode**
- Otherwise: **Single Bug Mode**

---

## Single Bug Mode

### Step 1: Triage

Understand the symptom before touching code:
- What should happen versus what actually happens?
- When and where does it occur (which input, which environment, which trigger)?
- Ask clarifying questions if the description is ambiguous. Don't guess at reproduction steps.

### Step 2: Trace the Request Through the Architecture

Every stack has some version of this chain; adapt the names to what the project actually uses:

```
Entry point (route, CLI command, event handler, queue consumer)
    |
Dispatch (router, framework middleware, controller)
    |
Business logic (service, use case, domain layer)
    |
Data access (model, repository, query layer)
    |
Presentation (view, template, serializer, response)
```

Read the relevant files along this path, starting from the entry point and following the call chain. If the project has a CLAUDE.md, a rules directory, or an architecture doc, read it first: that's where the actual layer names and boundaries are defined for this specific codebase.

### Step 3: Diagnose

Identify the root cause, not just the symptom. Check neighboring code for the same pattern; a bug caused by a missing cast, a missing null check, or a missing escape often exists in more than one place.

### Step 4: Fix

Apply the fix following the project's own conventions, not a generic default:
- Match the error-handling style already in use (exceptions, result objects, error codes) rather than introducing a new one.
- Match the existing naming, layering, and helper usage. If the project has a validation helper, a response helper, or an escaping helper, use it instead of inlining the logic again.
- If the fix touches a boundary (user input, external API response, file path from a request), re-check it against the project's security rules, not just the immediate bug.

### Step 5: Verify

Sanity-check the changed code:
- Types are correct (respect the language's type system, strict mode, or type hints if the project uses them).
- The fix follows the same pattern used elsewhere in the file/module.
- No new issue was introduced (an off-by-one in the fix, a newly-unhandled edge case, a broken caller).

### After Fixing

1. Explain the root cause in plain terms.
2. Explain what changed and why.
3. Note if the same pattern might exist elsewhere and should be checked.

---

## Batch Mode

For processing review reports, architecture analyses, or tech-debt reports.

### Step 1: Parse the Report

Extract every issue. For each, capture:
- File path and line number
- Severity (Critical / High / Medium / Low)
- Description of what's wrong
- Suggested fix, if the report provides one

### Step 2: Read Affected Files First

Read ALL affected files before changing anything. Understand context before acting; a fix applied file-by-file without seeing the whole picture tends to miss cross-file duplication of the same bug.

### Step 3: Fix in Priority Order

**Critical**: fix one at a time. Show the diff before applying. Verify after each fix.

**High**: batch similar fixes together (e.g. all missing null checks, all missing escapes).

**Medium**: fix if the change is straightforward and low-risk.

**Low**: fix only if the file is already open for a higher-priority issue in the same pass.

### Step 4: Report Results

For each issue in the report, output one line:

```
Fixed:      [file:line] - [what was done]
Skipped:    [file:line] - [why]
Need input: [file:line] - [the question]
```

### Gating Rules

- **BLOCK** on anything the report marks "requires confirmation." Show the proposed change and ask first.
- **BLOCK** on every Critical fix. Always show the diff before applying.
- **SKIP** if the fix instructions are unclear. Ask rather than guess.
- Group related fixes so the diff reads as one coherent change, not a scatter of unrelated edits.
- After a batch, run a sanity check on every changed file (the project's linter, type check or a syntax check) before reporting it fixed.
- If the review report already records the user's answer beside a finding, apply that answer. Do not ask the same question again.

---

## Fix Checklist (Both Modes)

- Root cause identified, not just the symptom patched
- The fix actually addresses that root cause
- No new security issue introduced
- Types/casts correct for the language and its strictness settings
- The project's own patterns followed (not a generic textbook pattern)
- No database or network queries added inside a loop (batch or preload instead)
- No duplicated logic; check whether the same fix already exists as a helper elsewhere

## Workflow Chain

After fixing, suggest running the project's review skill on the changed files to verify the fixes, then `/commit`.

## Closing questions

Before you present the report, turn every `Need input:` line into a short set of choices for the user: each option with what it costs, and your recommendation first. A finding with one right answer is not a question; fix it and say so in a line. If nothing is left open, say "no open items" in one line rather than staying silent.

interface:
  display_name: "Fix"
  short_description: "Fix a bug or apply review findings"
policy:
  allow_implicit_invocation: false

---
name: ship
description: Review changed files with your project's review skill, fix findings, and commit; deploy with --deploy.
disable-model-invocation: true
---

# Ship Pipeline

Review, fix, and commit in one flow, pausing after the review so nothing gets fixed or committed until you have seen what was found.

This skill assumes the project already has a review skill (the kind `a-review-optimizer`, in the dev-workflow-forge plugin, generates: a project-tuned `*-review` skill in `.claude/skills/`). If none exists, say so and suggest running `a-review-optimizer` first.

## Flags

| Flag | Effect |
|-|-|
| `--no-fix` | Skip the fix phase, go review -> commit |
| `--no-commit` | Stop after the fix phase |
| `--deploy` | Run the project's deploy step after commit, if one exists |
| Other flags | Pass through to the project's review skill (e.g. `--full`, `--debt`, `--security-only`) |

Default review scope is changed files only.

## Phase 1: Review

Invoke the project's review skill with all pass-through flags (default: changed files only).

Wait for it to finish. Capture the full report.

## Gate 1: Review Results

Show a compact summary of findings by severity (Critical/High/Medium/Low counts).

- **Zero findings:** print "Clean review. Skipping fix phase." and jump to Phase 3.
- **Findings exist:** ask the user: "Fix these? (yes / skip to commit / abort)"
  - **yes** -> Phase 2
  - **skip to commit** -> Phase 3
  - **abort** -> stop, print "Aborted."

If `--no-fix` was passed, skip this gate and go straight to Phase 3.

## Phase 2: Fix

Feed the full review report to `/fix` (batch mode; it parses the severity markers and file:line table on its own).

Wait for fixes to complete before moving on.

## Phase 3: Commit

Skip if `--no-commit` was passed. Print "Stopped after fix phase." and end.

Otherwise invoke `/commit`.

## Phase 4: Suggest Deploy

After a successful commit:

- If `--deploy` was passed and the project has a deploy step (a build script, a deploy command, a CI trigger): run it.
- If `--deploy` was passed and no deploy step exists: say so plainly; don't invent one.
- Otherwise: print a reminder that the project's own deploy step (if any) is the next manual action.

## Questions along the way

Do not run a round of questions of your own at the end. The review and fix stages each asked theirs, and asking again makes the user answer twice. Ask only when the commit step itself surfaces something neither earlier stage could have seen, and ask before committing, not after. Otherwise carry the earlier stages' answers into the final report, with one line each on what review and fix settled, so the chain's report still records the decisions.

Deploy mechanics are project-specific (a build script, cPanel upload, a container push, a CI pipeline) and out of scope for this skill; it only triggers whatever the project already defines.

interface:
  display_name: "Ship"
  short_description: "Review, fix and commit in one gated run"
policy:
  allow_implicit_invocation: false