x-dev-pipeline

中文说明

A recordable, auditable, and reviewable workflow framework for AI-assisted development.

Most of the time, AI coding agents don't fail because they can't write code — they fail because they drift off track mid-task, and leave behind little useful process information:

• Why was this change made?
• What exactly was modified?
• What decisions were made along the way?
• Which issues have already been addressed?
• Which risks are still unresolved?

When someone picks up the work later, they're forced to re-ask, re-read, and re-analyze from scratch.

x-dev-pipeline exists to solve this problem.

It turns throwaway, chat-style development into something closer to real engineering: get things done, leave a clear trail, and keep reviewing, fixing, and iterating.

Battle-tested on Claude Code. Designed to work with any AI coding tool.

If this is your first time using this repo, don't jump into the full pipeline right away.

Try /x-qdev first:

/x-qdev add dark mode toggle to the settings page

It's best for:

• Adding a small feature to a page
• Making a localized optimization
• Modifying a small module
• Filling in an interaction detail
• Running a lightweight validation

What you get isn't just "one reply" — it's a process closer to real development:

1. AI understands the task scope
2. Creates a task directory
3. Generates a task description and dev checklist
4. Implements items one by one, recording key changes
5. Leaves artifacts ready for follow-up review and fix

Typical output looks like this:

dev-pipeline/tasks/<task-name>/
├── README.md
└── changelog.md
reports/
├── cr/cr-report-*.md
├── fix/fix-report-*.md
└── fix/fix-note-*.md

This is the best way to experience x-dev-pipeline for the first time:

Complete a small feature smoothly, and leave an engineering trail behind.

Common problems when using AI coding agents directly:

• The task is small, but the process is messy
• Changes are made, but no clear record is left
• Reviews are ad-hoc and inconsistent in quality
• Work ends after the fix, with no feedback loop
• The next person picking it up has no idea what happened before

x-dev-pipeline doesn't solve "can AI generate code" — it solves:

How to make AI work at a more stable, traceable, engineering-grade pace.

For day-to-day development, this is the path I recommend most:

/x-qdev -> /x-cr -> /x-fix

Quickly ship a small feature, tweak, or module.

Run a structured review on the completed changes — no more "looks fine at a glance."

Fix issues from the review report, closing the feedback loop for real.

This path is great for:

• Small feature iterations
• UI interaction additions
• Module tweaks
• Localized optimizations
• Small-scale refactors

The point isn't to make the process heavy — it's to give even small tasks a sense of engineering discipline.

With x-dev-pipeline, you don't get a throwaway chat log — you get a set of artifacts you can continue using, tracking, and reviewing.

Typically, you'll get:

• Task directory
• Task description
• Dev checklist
• Changelog
• Code review report
• Fix report or fix note

These artifacts mean:

• Recorded: you know what changed
• Auditable: you know why it changed
• Reviewable: you can pick up where you left off
• Retrospectable: you can look back at decisions and issues

This is one of the core values of this repo:

Don't just get things done — turn the development process into truly traceable engineering assets.

x-dev-pipeline isn't just /x-qdev.

For more complex tasks, it provides a full development flow:

x-spec -> x-req -> x-plan -> x-dev -> x-cr -> x-fix
                    ^
                 x-qdev

Think of it this way:

Start directly with /x-qdev — fast to complete, fast to ship.

Start with /x-req -> /x-plan -> /x-dev — when you need clear requirements and an execution plan.

Walk the full pipeline — for system design, complex modules, and architecture-level changes.

In short:

• Keep it light for small things
• Keep it solid for big things
• Always close with review and fix

Lightweight quick development entry point. Best for small features, localized optimizations, and module tweaks. The recommended way to start.

Structured code review. Runs tiered checks on changes, flags issues, risks, and improvement suggestions, and writes the CR main report to reports/cr/cr-report-YYYYMMDD-HHmmss.md.

Fix by review report. Review doesn't end at reading — problems get actually solved, and the repair record is written to the same CR main report plus reports/fix/.

Requirements analysis. Turns a development task into a clear, structured requirements spec.

Development plan. Breaks down requirements into steps, scope, and execution order.

Execute the plan. Development with a checklist, status tracking, and a changelog.

System architecture planning. For larger projects, complex modules, architecture design, or long-term evolution tasks.

curl -fsSL https://raw.githubusercontent.com/KtKID/x-dev-pipeline/main/install.sh | bash

git clone https://github.com/KtKID/x-dev-pipeline.git ~/.claude/plugins/x-dev-pipeline

Register the local marketplace:

cd ~/.claude/plugins/x-dev-pipeline
claude plugin marketplace add ./.claude-plugin/marketplace.json

Install the plugin:

claude plugin install x-dev-pipeline@x-dev-pipeline --scope user

This repo ships a repo-scoped Codex marketplace at .agents/plugins/marketplace.json.

Open the repo in Codex and Local can discover x-dev-pipeline directly from the workspace.

Clone to the local plugin directory:

mkdir -p ~/.codex/plugins
git clone https://github.com/KtKID/x-dev-pipeline.git ~/.codex/plugins/x-dev-pipeline

On Windows, you can sync the current checkout into Codex and refresh the user-level marketplace files with:

./install-codex.ps1

Directory layout:

~/
├── .agents/
│   └── plugins/
│       └── marketplace.json
└── .codex/
    └── plugins/
        └── x-dev-pipeline/

The current official way to install local plugins is to manually maintain ~/.agents/plugins/marketplace.json, then open the plugin directory in Codex to install. There's no standalone plugin install subcommand, but the official docs provide an interactive entry:

codex
/plugins

You'll need to manually add the local marketplace entry:

{
  "name": "local-plugins",
  "interface": {
    "displayName": "Local Plugins"
  },
  "plugins": [
    {
      "name": "x-dev-pipeline",
      "source": {
        "source": "local",
        "path": "./.codex/plugins/x-dev-pipeline"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
}

You can also reference the example file in the repo:

examples/codex-marketplace.json

Two things to note:

• source.path is resolved relative to the root directory where ~/.agents/plugins/marketplace.json lives
• For personal marketplaces, the common pattern in the official docs is ./.codex/plugins/<plugin-name>
• The repo-scoped marketplace in this repo uses ../.. so Codex can resolve the plugin root from .agents/plugins/marketplace.json

If you already have ~/.agents/plugins/marketplace.json, just append the plugin entry above to the plugins array — don't overwrite existing plugins. Save, restart Codex, then run:

codex
/plugins

Find x-dev-pipeline in the plugin directory and install it. (You may need to switch to Local.)

After installation, try this to get started:

/x-qdev add dark mode toggle to the settings page

This repo is especially suited for:

• Developers using AI coding agents daily who want a more disciplined process
• People who want AI development to feel more like engineering, not just chat
• Anyone who wants every change to leave a clear record
• Those who want review and fix to form a real feedback loop
• People looking to build a stable, repeatable development rhythm

This repo might not be the best fit if you currently need:

• A zero-config, plug-and-play general-purpose coding assistant
• A heavy enterprise process management platform

x-dev-pipeline's workflow design is not tied to any specific tool. It's been deeply validated on Claude Code, but the core principles apply to all AI coding agents:

• Small tasks should ship fast
• Every change should be recorded
• Every decision should be traceable
• Reviews shouldn't stay verbal
• Fixes should close the loop

If you're using another tool (Cursor, Codex, Windsurf, Cline, etc.), just tell your AI:

"Keep the x-dev-pipeline workflow intact, but adapt it to Cursor (or whatever tool you're using)."

The AI will adjust task directory locations and trigger mechanisms based on the target tool's conventions, while preserving the full workflow chain.

Note: The default task output directory in the skills is dev-pipeline/tasks/. During adaptation, the AI may ask whether you'd like to change it to a different path (e.g., .codex/tasks/) — just confirm based on your setup.

All skills share a unified task status system:

The goal isn't to make the process heavy — it's to make development:

Structured when you need it, lightweight when you don't.

It's not a rigid methodology you must follow end-to-end. It's a workflow toolkit you can freely pick from based on task complexity.

We'll continue strengthening these areas:

• Smoother /x-qdev first-time experience
• Clearer task artifact structure
• Stronger review / fix feedback loops
• More real-world usage examples
• Better multi-language, multi-stack support
• Official adapters for more tools (Cursor, Codex, Windsurf, etc.)

MIT