Skip to content
compforgePublic

About

A guard-railed, closed-loop workflow for AI coding agents: live state bus + execution-level hard intercepts for Claude Code, Codex, and DeepSeek Harness (GitHub PR / GitLab MR). From step-level to requirement-level; eval-driven, spec-driven, human-in-the-loop.

Topics

Resources

Contributing

Stars

4 stars

Watchers

0 watching

Forks

Repository files navigation

English | 简体中文

devloop

A controlled PR/MR development lifecycle for AI coding agents.

This repository is a cross-CLI plugin marketplace. Its flagship plugin, devloop, helps Claude Code, Codex, and DeepSeek Harness complete branch-based development without losing control of repository state, validation, Git mutations, or concurrent sessions.

The marketplace also distributes code-taste, a skill-only plugin for architecture, boundaries, naming, maintainability, documentation, and code review, plus quality, a skill-only plugin for evidence-driven project quality evaluation.

model-router is an independent OpenCode V2 plugin that uses the OpenAI Decisions API to route simple, medium and complex tasks to Terra, Sol and Astra.

enter repo → start branch → develop → normalize → lint ∥ test → commit → push → PR/MR → human merge

devloop supports GitHub PRs and GitLab MRs, selected from each repository's origin. Merge remains a human decision.

Why devloop

AI coding often loses time at the boundaries around the code:

  • Information lag — the agent guesses the current repository, branch, PR/MR, and validation state from conversation history.
  • Soft conventions do not enforce themselves — instructions such as “do not commit to main” or “do not use git add -A” can still be bypassed without execution-level guards.
  • Concurrent sessions collide — multiple agents sharing one checkout can switch branches underneath each other, mix uncommitted work, or resolve an operation to the wrong repository.

devloop turns those boundaries into a reusable development loop: live context tells the agent where it is, controlled transactions own Git side effects, validation runs against affected Components, and managed worktrees isolate concurrent work.

What the devloop plugin provides

  • Controlled Git/PR transactions — gcam, gcamp, and gcampr perform commit, commit + push, and commit + push + PR/MR respectively. New work starts from the intended target branch instead of inheriting accidental commits from the current HEAD.
  • Affected-Component validation — a repository may contain independent Components such as server/, cli/, or packages/*. devloop selects the Components touched by the change and records lint/test results at the same granularity.
  • One validation model — complete validation normalizes with make format, then runs static-quality and behavioral checks concurrently through canonical Make targets. Lint or test alone is reported as partial validation.
  • Current repository context — branch, working tree, PR/MR, and validation facts are surfaced to the active session and refreshed as the development state changes.
  • Execution-level guardrails — high-confidence risks such as protected-branch commits, inactive-branch edits, broad staging, and unmanaged worktree creation are denied before they mutate the repository.
  • Concurrent-session isolation — checkout ownership prevents one session from changing another session's branch or tracked files and routes parallel work to a managed worktree.
  • Safe PR/MR continuation — an existing PR/MR can receive additional commits, review output, or a resumable conflict rebase without handing merge authority to the agent.

The stable domain spine is PR/MR → Repo → Component. A workspace is an optional context that groups multiple repositories; single-repository use is fully supported.

For the validation contract, configuration, commands, and advanced workflows, see the devloop plugin README.

Quick start

Runtime requirements: Node.js 22.19+ for the shared runtime and harness adapters; uv and Python 3.11+ for skill workflows. The scripts/python launcher prepares a locked environment in uv’s cache (network access is needed on first use). Set DEVLOOP_PYTHON to select a compatible interpreter. Repository organization uses native repocli libraries; snapshot/diff operations still require the repocli CLI.

Claude Code

/plugin marketplace add https://github.com/compforge/devloop.git
/plugin install devloop@devloop

Codex

codex plugin marketplace add https://github.com/compforge/devloop.git
codex plugin add devloop@devloop

If Codex asks for hook review, open /hooks and trust the devloop hooks.

DeepSeek Harness

The native Cordis bundle targets DSH 0.1.6-alpha.1. Install it into the profile where devloop should run. This example uses the built-in headless profile; replace it with another profile name when needed:

npx --yes @deepseek-ai/dsh@0.1.6-alpha.1 plugin --profile headless add @compforge/devloop

The package declares its DSH bundle layer, exposes its bundled skills, and mounts @compforge/devloop/dsh automatically. It registers directly on DSH lifecycle and tool events; it does not shell out through the Claude/Codex hook protocol. Remove it with npx --yes @deepseek-ai/dsh@0.1.6-alpha.1 plugin --profile headless remove @compforge/devloop. If the matching DSH version is installed globally, the shorter dsh command is equivalent.

OpenCode V2

OpenCode 2.1.2+ loads the native plugin through its npm server entrypoint. Add it to opencode.json(c):

{
  "plugins": ["@compforge/devloop@0.4.61"]
}

For a source checkout, run npm ci && npm run build in devloop/, then use that directory's absolute path in plugins. The adapter registers the bundled skills, provides Board context, and applies shared tool guardrails, including CodeMode child calls. V1 is not supported.

Start a new session after installation. Repository state is initialized automatically when the agent first enters a Git repository.

Then use outcome-oriented requests instead of assembling shell commands yourself:

validate the changes
gcampr

PR/MR creation and remote state refresh require credentials for the repository host. Prefer GITHUB_TOKEN, GH_TOKEN, or GITLAB_TOKEN; host-specific configuration is documented in the plugin README.

Project validation contract

Components are discovered from project manifests, then Makefiles. Makefile-only Components have unknown language; repositories without either have no Components and skip validation without passing stamps. Each Component exposes stable, non-interactive Make targets:

make format                  # optional normalization; may rewrite source
make lint-ci | make lint  # read-only static-quality check
make test                 # read-only full behavioral suite

Projects may additionally accept TEST_FILES for focused feedback on large suites, while an empty value must retain full-suite behavior. See the validation contract and the language-specific guidance for Python, Go, or Node.js. The plugin README explains when focused tests are selected.

For this marketplace, root make lint test validates the marketplace indexes, make -C quality lint test validates quality's skill assets, and make -C devloop lint test validates the workflow plugin. Use make check-all to run all three; Component checks do not recursively run each other.

Configuration

All lifecycle hooks are opt-in. User configuration lives in ~/.devloop/config.json; a repository or workspace can provide a closer .devloop/config.json override. The same configuration controls forge credentials, lifecycle validation/review hooks, review engine selection, and managed-worktree retention.

See config/config.example.json for the complete schema. The default review engine is CCR; review is asynchronous and never blocks commit or PR/MR creation.

Scope and compatibility

  • Harnesses: Claude Code and Codex use thin process-hook adapters; DeepSeek Harness uses the native Cordis adapter, and OpenCode V2 uses its native plugin API. All four share the TypeScript Board, state, tool projection, and policy core. Skill workflow scripts remain Python and are harness-independent.
  • Forges: GitHub and GitLab are peer providers selected per repository.
  • Ownership: devloop owns the coding-harness development loop: repo/branch state, validation, commit/push, PR/MR creation, review delivery, and execution guardrails.
  • Boundary: requirement identity, cross-repository orchestration, deployment, long-running scheduling, and session wakeups belong to higher-level loops such as Baton and the ReqLoop Marketplace.
  • OpenCode scheduling: session activity triggers bounded PR/MR reconciliation. Idle-time scheduling remains external; the adapter does not create a background polling loop.

Updating

Claude Code:

/plugin marketplace update devloop
/plugin update devloop

Codex:

codex plugin marketplace upgrade devloop
codex plugin remove devloop@devloop
codex plugin add devloop@devloop

Start a new session after updating so the runtime reloads hooks and skills. User configuration under ~/.devloop/ is preserved.

Plugins

Plugin Purpose Documentation
devloop Controlled PR/MR development lifecycle for Claude Code and Codex README
code-taste Engineering judgment for architecture, boundaries, naming, maintainability, and review README
quality Operate project-owned E2E, performance, and agent trajectory quality capabilities README
example Placeholder demonstrating the multi-plugin marketplace layout README

Documentation

About

A guard-railed, closed-loop workflow for AI coding agents: live state bus + execution-level hard intercepts for Claude Code, Codex, and DeepSeek Harness (GitHub PR / GitLab MR). From step-level to requirement-level; eval-driven, spec-driven, human-in-the-loop.

Topics

Resources

Contributing

Stars

4 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages