dev-loop

{
  "name": "dev-loop",
  "description": "The everyday dev loop as three stack-neutral commands: fix debugs a bug or batch-applies a review report by severity, commit runs pre-flight checks and drafts a conventional message behind a sensitive-file gate, ship chains review, fix, and commit with a gate between each phase.",
  "version": "1.0.0",
  "author": {
    "name": "Ivan Misic"
  }
}

# dev-loop

The everyday development loop as three stack-neutral commands. No built-in bug catalog and no assumed stack: each command teaches a method and layers your project's own conventions on top of a generic baseline.

## 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 with a gate between each phase |

`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.

## Install

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

---
name: commit
description: Git commit with pre-commit checks. Analyzes changes, drafts a conventional commit message, stages files individually, and gates on sensitive-file detection. Stack-neutral, works on any project.
---

# 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.

---
name: fix
description: Debug and fix bugs. Single mode traces a request through your architecture's layers. Batch mode parses a review report and fixes findings by severity. Stack-neutral, follows whatever patterns your project already uses.
---

# 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.

---

## 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`.

---
name: ship
description: "Chains review -> fix -> commit with gates between steps. Supports --no-fix, --no-commit, --deploy. Other flags pass through to your project's review skill. Stack-neutral wrapper around whatever a-review-optimizer generated for this repo."
---

# Ship Pipeline

Review, fix, and commit in one flow, with a gate between each phase so nothing gets applied or committed without a chance to stop.

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.

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.