lazydeepseek
LazyDeepSeek — LazySeries 系列中的 DeepSeek Harness (dsh) 成员：从 LazyZCode 移植而来的技能、钩子、MCP 服务器、命令、代理以及 Ralph/ULW 循环。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:elvinzhao10/LazyDeepSeek#b351568500bc9d2cd44c571916cd70578101200eLazydeepseek 以 lazydeepseek 发布，当前版本为 1.3.5。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →Describe the work. Keep the plan. Prove the result.
LazyDeepSeek helps you use structured, evidence-based workflows in DeepSeek Harness. It prepares local package assets and guidance; a host is only considered ready after it is observed in a fresh session.
Platform status · Get started · Host routes · 1.3.5 notes · Family · Docs
Current package version: v1.3.5. HOST READINESS: PENDING. Local checks and release archives prove package behavior; a fresh host session must prove loading, command/skill execution and MCP connections.
This is a maintenance release. It includes the workflow foundation introduced in the family since v1.3.0 and subsequent reliability work. For Kimi and DeepSeek, that describes inherited family behavior, not prior public releases of these ports. The details below describe the cumulative v1.3.5 experience; the release notes distinguish this patch's fixes from inherited features. No new speed, token-saving or cost claim is made.
| Family milestone | What you get in the current package |
|---|---|
| v1.3.0 foundation | Natural-language entry, editable plans, durable decisions and verification tiers. |
| v1.3.1 reliability | Clearer execution intent, safer isolation and evidence comparisons. |
| v1.3.2 handoff | Revision-bound verification-report contracts; generic completion APIs have separate limits. |
| v1.3.3 hardening | Host-specific hook, MCP and publication repairs. |
| v1.3.4 maintenance | Transactional run integrity, safer lifecycle and native adapter repairs. |
| v1.3.5 repairs | Real runtime exercises, bounded hooks, dependency updates and current platform guidance. |
Two entry routes converge on the same execution authority and gates:
/lazy-ulw-plan <idea> builds a new plan, and
/lazy-start-work <plan> executes a known plan. Same authority, same gates.No 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 are Markdown you own. Edit them mid-run; the harness reconciles your changes at execution boundaries instead of overwriting them:
Cross-plan decisions live in a durable ledger
(.lazydeepseek/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.
The workflow calls for verification sized to the change: a documentation inspection (V0), a focused check (V1), an integration scenario (V2), or a comprehensive security/release gate (V3, normally in CI). Valid evidence may be reused while its inputs match; affected, missing or stale checks must rerun. Native execution still needs acceptance in the selected host.
Milestones, decision gates, and full state/version semantics are shared
byte-identically with LazyBuddy, LazyTrae, and LazyQoder (see
plugins/lazydeepseek/contracts/lazyseries-shared-semantics.v1.json). The DeepSeek Harness
route boundary is unchanged: package
selection never proves host activation.
Open an AI coding assistant in your project and paste this:
Help me install LazyDeepSeek from https://github.com/elvinzhao10/LazyDeepSeek for this project. Read the repository's AGENTS.md and install guide. Verify the root package manifest and run safe package checks first. Guide me through the dsh git-spec install for that GitHub repository pinned to a commit sha, then verify the installed plugin in a fresh session. Ask me before installing or enabling the plugin.
The assistant can run local checks and guide the host steps. Installing or enabling the plugin grants it code-execution trust, so approve those actions in DeepSeek Harness after reviewing the source.
dsh --version reports exact 0.2.0-rc.2../lazydeepseek for a
local development checkout). The npm registry is not used for this package.
Installed plugins are enabled by default; no build scripts run because the
prebuilt lib/ is committed.
To upgrade an existing installation, install the new verified release SHA
into the same profile and restart the session so the generated hooks
configuration is parsed fresh.PATH for the local
launchers. Try it in a new task: skills appear via the Skill tool
when the model invokes a loaded skill; registered commands may appear as
interactive entries such as /lazy-ulw-plan where supported; observe them
rather than inferring visibility from registration.bash scripts/install.sh verifies Node.js LTS 20+ and
Git, validates the root dsh bundle manifest and route contract, runs the package load-check and
plugin doctor, and prints the profile-scoped dsh plugin install steps with
the GitHub URL (copied to the clipboard on macOS). With
--project <absolute-project-root> it additionally runs the durable lifecycle
onboard. Inside DeepSeek Harness, the /lazy-onboard, /lazy-update, and
/lazy-offboard commands walk onboarding, update, and receipt-safe removal
step by step. The git-spec profile steps above stay canonical, and package checks
never prove host readiness — the script ends with HOST READINESS: PENDING
until a fresh session shows one real skill/command and all six MCP
connections.
Manual setup is available when you prefer complete control. You need
Node.js LTS 24 (recommended) or 22 (supported alternative) — the lifecycle
also accepts Node.js LTS 20 for compatibility — and Git, plus Python 3.10+ available as python3. Start from the
verified origin
https://github.com/elvinzhao10/LazyDeepSeek and follow the
installation guide.
The git-spec install above is the primary route. For a durable install
that survives source checkouts, run onboard once to create a durable
installation; after that, use the stable launcher for update, status, and
safe offboard:
node "<install-root>/LazyDeepSeek/launcher.js" status --project "<absolute-project-root>"
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 dsh from
PATH. Optional host-manifest validation is an explicit action using
bash scripts/lazydeepseek-plugin-doctor.sh --host-validator /absolute/path
run from plugins/lazydeepseek/.
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.
Pick one route per project:
dsh-plugin-git-sha) is the default
full-plugin route: skills, commands, native role tools, seven bridged hook events, and six MCP
rows are composed from one bundle; fresh-session loading is observed separately.Skills plus manual MCP connectors are a recovery-only
(manual-skills-mcp-fallback) option. Do not run that fallback beside a
full-plugin route for the same project. Stop the session, remove only
LazyDeepSeek's previous entries through the host UI, choose one route, and start
a new session to verify it.
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 dual-entry routing introduced in v1.3.0 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.” |
LazyDeepSeek 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 native plugin installation and connector changes.
| Surface | Count | Role |
|---|---|---|
| Skills | 19 | Host-facing workflow policies for planning, execution, review, and verification. |
| Commands | 20 | Named host entry points (slash menu entries) for those workflow policies. |
| Agents | 13 | Specialist role definitions for planning, implementation, QA, security, and context. |
| Hook events | 9 declared / 7 bridged | SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, SubagentStart, SubagentStop bridge natively. PermissionRequest and PostToolUseFailure are degraded synthesis; child events are advisory. |
| MCP declarations | 6 | Local services for ledger, verification, status, context, code intelligence, and docs. |
One workflow philosophy. Six host integrations. Choose the sibling for the host you use; each keeps its own native adapters, installation route and acceptance evidence. These packages run independently.
| Sibling | Target host |
|---|---|
| LazyBuddy | CodeBuddy CLI / IDE · WorkBuddy |
| LazyTrae | TraeCode / TraeWork / TraeCode CLI |
| LazyQoder | Qoder CLI / IDE / app |
| LazyZCode | ZCode |
| LazyKimi | Kimi Code CLI · Kimi Work (experimental) |
| LazyDeepSeek ← you are here | DeepSeek Harness 0.2.0-rc.2 |
The family shares planning, evidence, decision-memory and completion contracts. The first shared verification core is vendored in every package; product adapters keep host setup and permissions explicit. Matching contracts do not make host capabilities interchangeable. In particular, Kimi Work remains experimental for LazyKimi, and DeepSeek's synthesized events are not native hooks. Use each sibling's host guide before installation.
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 LazyDeepSeek implements and where it intentionally differs, see lazydeepseek-evaluation.md.
LazyDeepSeek is primarily inspired by LazyCodex. Attribution and its relationship to OmO are recorded in NOTICE. It is an independent implementation and does not require LazyCodex or OmO at runtime.
MIT. See NOTICE for attribution and provenance.
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.