Solodeveling

English | ภาษาไทย

One agent. The right amount of process. From a tiny fix to a verified release.

Solodeveling is a single-agent-first software delivery protocol for solo developers. It keeps a single primary agent oriented across discovery, planning, implementation, verification, security, release, and maintenance. Small, safe work can stay ephemeral. Resumable or risky work gains durable memory and stronger gates only when the risk justifies them.

Use the same canonical skill suite with Codex, Claude Code, Cursor, and generic Agent Skills clients. Subagents may still be used when useful, but Solodeveling does not require a multi-agent team to complete the ordinary workflow.

Status: Alpha releases are published on npm, PyPI, and as an immutable GitHub Release. Codex and Claude Code have each passed one bounded representative live scenario. Cursor has structural adapter evidence only because cursor-agent was unavailable. Tier 1 remains unverified until the full core scenario matrix passes.

Quick start

Node.js users need one command:

npx solodeveling install

For a permanent command:

npm install -g solodeveling
solodeveling install

Python users can run it without a permanent install or install it as a tool:

uvx solodeveling install
uv tool install solodeveling
pipx install solodeveling

All channels expose one public command: solodeveling. See Installation for prerequisites, platform support, upgrades, and integrity controls.

Why Solodeveling

• Single-agent-first: keep one accountable primary agent instead of requiring delegation, role hand-offs, or parallel workers for ordinary delivery.
• Quiet for small work: a safe Quick task can use zero required questions, zero project-memory writes, and verification proportional to its impact.
• Direct for read-only work: ordinary Q&A, explanation, review, status, diagnosis, and inline advice inspect only what the claim needs and skip lifecycle artifacts.
• Durable when it matters: resumable work records current state; Critical work adds explicit security, recovery, evidence, and release boundaries.
• Complete delivery lifecycle: use one vocabulary from discovery and coding through debugging, verification, release, and maintenance.
• Project-local and portable: install the same skills into the runtimes detected in the repository without searching for or modifying global agent installations.

A bounded same-session follow-up uses Ephemeral Quick before reopening or reusing prior Standard work. Reuse the existing Standard pair only when the continuation must survive a session, changes a durable decision, or belongs to an active batch with unchanged goal, acceptance, authority, risk, release boundary, and rollback. Roadmap updates happen only when priority, milestone, ordering, or a deferred-work decision changes. WORK owns scope and decisions, EVIDENCE owns checks and limitations, and state contains only the context needed to resume.

During uninterrupted Standard delivery, persist active once and write final evidence plus done and archive once after verification. Persist an intermediate phase only for a session boundary, blocker, handoff, scope/risk change, or requested checkpoint. Reuse current automated evidence for the exact coverage it proves; manual browser review fills only the remaining visual or interaction gaps.

Backend queries and API handlers default to Standard. A bounded read-only mapping, sorting, copy, or observationally equivalent refactor may stay Quick only when access, sensitivity, validation, response compatibility, stored data, and external effects remain unchanged and a focused contract test proves the exact boundary. Any uncertainty keeps the work Standard.

With and without Solodeveling

A coding agent can keep a TODO.md or write next-session notes without installing any skill. Solodeveling does not make the model inherently smarter; it packages a repeatable delivery policy so the user does not have to reconstruct it in every prompt or session.

Not every project needs Solodeveling. A small, low-risk, single-session project may be better served by a clear prompt and a TODO.md. Solodeveling earns its overhead when repeatable decisions, cross-session continuity, or risk-sensitive verification matter. The testable claim is not that a skill makes the model smarter, but that a shared protocol reduces repeated coordination and missed gates without burdening small work.

How it compares

These projects have different defaults rather than a universal winner. The table summarizes their public documentation as of July 2026; it is not a controlled speed or quality benchmark.

What faster means here

Solodeveling optimizes workflow overhead, not unmeasured model intelligence. It does not yet claim to complete coding tasks faster than the alternatives above. A fair claim requires the same repository, model, prompt, task set, and repeated runs. The repository now includes a preregistered 18-run Solodeveling/Superpowers pilot with exact source and runtime pins, hidden correctness checks, offline planning, and a separate live-authorization gate. Pilot 1 failed before inference; Pilot 2 did not activate either methodology; and Pilot 3 could not mutate through the broken Windows sandbox. These are invalid measurement runs, not a comparative result. A separate feedback measurement plan preregisters a correctness-gated 0.1.1-versus-0.1.2 pilot and a local twenty-task field scorecard. The same plan now includes an unrun, correctness-first 30-call comparison between pinned Solodeveling 0.2.0 and a true no-skill arm across read-only, Quick, Standard, continuation, and Critical-readiness work. A preregistration is a test plan, not a positive result or a public performance claim.

See EVIDENCE-006, EVIDENCE-019, and EVIDENCE-025 for methods and limitations.

Who it is for

Choose Solodeveling when you:

• maintain a project alone or with one primary coding agent;
• want tiny fixes to stay lightweight without losing discipline on risky work;
• need continuity across sessions without accumulating a document for every action;
• own both implementation and release or maintenance responsibilities; or
• switch between Codex, Claude Code, Cursor, or another Agent Skills client.

Another approach may fit better when you want specialized personas and multi-agent coordination as the default, require a formal specification artifact for every change, or need a mature ecosystem with a much larger behavioral evidence base.

Automatic project installation

The ordinary workflow has no required options:

solodeveling install
solodeveling check
solodeveling uninstall

Solodeveling first reuses any installation it already manages. Otherwise it detects project-local Codex/Agent Skills, Claude Code, and Cursor directories. It installs every distinct runtime found, and defaults to the standard .agents/skills path when the project has no runtime marker. It never searches global executables or writes outside the current project.

Installation validates the skill suite, preflights every detected target, rejects symlinks and path traversal, refuses unmanaged collisions, copies files atomically, and records managed hashes. Check detects missing, changed, or unexpected managed files. Uninstall removes only unchanged managed files and has no force-delete mode.

Start a fresh agent session after first installation, then invoke $solodeveling in Codex, /solodeveling in Claude Code or Cursor, or the client-defined invocation in another Agent Skills runtime.

Advanced overrides

Automation and unusual workspaces may still select an exact runtime or another project. --dry-run remains available as an optional preview, not a required step:

solodeveling install --runtime claude-code --project-root PATH
solodeveling install --runtime cursor --dry-run

Other commands

The install flow stays short; project memory, tracked-work helpers, and evaluation remain explicit:

solodeveling init
solodeveling validate .
solodeveling work evidence . WORK-033 --claim "Focused tests pass" --method "Automated test" --result passed --scope "Lifecycle helper"
solodeveling work transition . WORK-033 verifying
solodeveling work archive . WORK-033 --next-action "Select the next priority"
solodeveling eval probe
solodeveling version

The work helper validates memory before and after each operation, rejects invalid transitions, updates work and state together, and rolls back a partial write. Standard work reuses its evidence file automatically; audited work with multiple evidence files can select one with --evidence-id.

Live evaluation can consume model-service usage or API credits, so review Cross-agent evaluation before authorizing a live run.

Security and support boundaries

The npm launcher has no runtime dependencies and no install lifecycle script. On an explicit invocation it selects an exact-version native artifact, downloads only from the versioned GitHub Release, verifies its bundled size and SHA-256, caches it, and executes it without a shell. Windows, macOS, and Linux on x64 and arm64 are release targets only after their CI builds and native smoke tests pass. Unsupported targets fail closed and show the Python-tool fallback.

Solodeveling applies risk-scaled verification and Secure SDLC guidance, but installing it does not make a project categorically secure or compliant. Hashes detect byte changes; they do not by themselves prove publisher identity. No telemetry is collected and no publishing credentials are included.

No tag, GitHub Release, npm package, or PyPI package is created by ordinary CI. External publication requires a reviewed source revision and separate explicit authorization.

License

Apache-2.0. See LICENSE.