LazyBuddy

Name: LazyBuddy
Author: elvinzhao10

LazyBuddy helps you use structured, evidence-based workflows in CodeBuddy
CLI, CodeBuddy IDE, and WorkBuddy. It prepares local package assets
and guidance; a host is only considered ready after it is observed in a fresh
session.

The current package version is v1.3.4. Fresh native-host acceptance remains
pending; package checks do not prove a host loaded it.

v1.3.4 makes run updates transactional, preserves checkpoints and concurrent
plan edits, and reports blocked, failed and exhausted work explicitly. See release notes.

Introduced in v1.3.0: work the way you talk

v1.3.0 introduced the major workflow release. You no longer need to remember commands —
the harness meets you at the level of your request.

Just ask, or use a command — both work

Two entry routes converge on the same execution authority and gates:

Natural language: describe the work plainly — "Fix the typo in the
welcome label" — and the smallest sufficient workflow is selected and run.
Explicit commands: /lazy-ulw-plan <idea> builds a new plan, and
/lazy-start-work <plan> executes a known plan. Same authority, same gates.

No slash command is required for a clear implementation request. Conversely,
asking to explain, quoting a command, or saying "plan only" never touches
your files: the persisted execution_intent stays plan_only until you
actually ask for execution, and a vague "ok" with several open questions never
grants execution by itself.

Plans you can edit while work runs

Plans are Markdown you own. Edit them mid-run; the harness reconciles your
changes at execution boundaries instead of overwriting them:

Cosmetic edits (wording, reordering, checking a box) keep all evidence.
Semantic edits (acceptance, dependencies, verification commands) invalidate
only the affected task and its dependents — unrelated work is untouched.
Your checkbox is an assertion, not a verdict: a checked box alone never
counts as verified completion, and unchecking reopens the task.

Decisions the harness remembers

Cross-plan decisions live in a durable ledger (.lazybuddy/decisions/ledger.jsonl).
When plan two hits a question plan one already answered — with evidence — it
recalls the decision instead of re-asking you. Contradictions are surfaced as
supersessions, defects become scoped corrections that block only the affected
work, and nothing in memory can override your current instructions.

Verification sized to the change

Checks run once, at the right tier: documentation edits get a light inspect
(V0), small changes a focused check (V1), cross-module behavior an integration
scenario (V2), and security/release boundaries the comprehensive gate (V3,
normally in CI). A green check is reused while its inputs are unchanged — the
same test is never rerun just because a phase changed.

Milestones, decision gates, and full state/version semantics are shared
byte-identically with LazyTrae and LazyQoder (see
lazybuddy-plugin/contracts/lazyseries-shared-semantics.v1.json).

Recommended: install with AI help

You do not need to manually work through every setup detail. Open an AI coding
assistant in your project and paste this:

Help me install LazyBuddy from https://github.com/elvinzhao10/LazyBuddy for
this project. Use the published v1.3.1 route. Run safe package checks first,
explain each step plainly, and ask me before changing marketplace, plugin,
Skills, MCP, account, credential, or trust settings.

The assistant can guide onboarding, but you approve every host-managed change.

Manual setup

Manual setup is available when you prefer complete control. You need
Node.js LTS 24 (recommended) or 22 (supported alternative) and Git. The lifecycle also accepts Node.js LTS 20 for compatibility. Start from the verified origin
https://github.com/elvinzhao10/LazyBuddy and follow the
installation guide.

Run onboard once to create a durable installation. After that, use the stable
launcher for update, status, and safe offboard:

node "<install-root>/LazyBuddy/launcher.js" status

What “ready” means

Package readiness means the copied package and local checks are valid.
Host readiness needs a fresh host session, one real Skill or command,
and every expected MCP connection.

Until that is observed, the honest result is HOST READINESS: PENDING.
Local files and load checks never prove that a host loaded the plugin.

The default package doctor does not discover or execute codebuddy from
PATH. Optional host-manifest validation is an explicit action using
bash scripts/lazybuddy-plugin-doctor.sh --host-validator /absolute/path.
The release verifier runs classified shell regressions serially, all package
tests/*.test.js with conservative Node concurrency, and Python tests under
tests/ and tooling/; its JSON names those outcomes separately.

Choose one route

Pick one host route during onboarding:

CodeBuddy CLI uses the documented local marketplace route.
CodeBuddy IDE uses that marketplace route when the CLI is available.
WorkBuddy uses its full-plugin marketplace route.

Skills plus manual MCP connectors are a recovery-only option. Do not run that
fallback beside a full-plugin route for the same project. Stop the session,
remove only LazyBuddy's previous entries through the host UI, choose one route,
and start a new session to verify it.

Design mindset

Start with the result you want and how you will know it worked. Then use the
smallest amount of structure that fits the task. You can simply describe the
work in plain language; the modes are guidance, not commands you need to
memorize. The v1.3.0 dual-entry routing picks one of these for you.

Mode	Use it when	Example request
Direct	The change is small and clear.	“Fix this error and run the relevant test.”
Assisted	You need help understanding an unfamiliar area or failure.	“Help me find why this command fails, then verify the fix.”
Planned	The work has several parts or important choices.	“Make a plan for this feature before changing files.”
Orchestrated	The work affects a release, security, or a risky change.	“Review this release and prepare it for publication.”
Long-horizon	The goal needs to continue across sessions.	“Keep working on this migration with checkpoints.”

Keep host changes deliberate

LazyBuddy does not automate credentials, OAuth values, private registries, or
trust settings. It asks for approval before any host-managed action and keeps
safe package checks separate from marketplace and connector changes.

Package inventory

Surface	Count	Role
Skills	14	Host-facing workflow policies for planning, execution, review, and verification.
Commands	14	Named host entry points for those workflow policies.
Agents	13	Specialist role definitions for planning, implementation, QA, security, and context.
MCP declarations	6	Local services for ledger, verification, status, context, code intelligence, and docs.

Technical reference and evaluation

The source-level explanation lives in docs/README.md. It
maps the package structure, request flow, state model, security boundaries,
MCP lifecycle, and release checks with diagrams tied to the implementation.

For a capability-by-capability comparison with the original LazyCodex design,
including what LazyBuddy implements and where it intentionally differs, see
lazybuddy-evaluation.md.

LazyBuddy is primarily inspired by LazyCodex
(upstream project). Its
relationship to OmO and upstream sources is recorded in NOTICE.
It is an independent implementation and does not require LazyCodex or OmO at
runtime.

Learn more

License

MIT. See NOTICE for attribution and provenance.

Contributing

Issues and pull requests are welcome. Read CONTRIBUTING.md
for development checks, release expectations, and guidance for reporting
sanitized reproduction details. Report vulnerabilities privately according to
SECURITY.md.