Contributing

DeepSeek Harness currently accepts no external PRs into the core repository — the sanctioned way to contribute is the ecosystem (see their CONTRIBUTING.md). For this project that means:

1. Workflow (mandatory since v0.2.0): every change starts as a GitHub issue on the current milestone; one issue = one branch = one PR, squash merged into main. Every PR passes two gates before merging: an independent subagent review (fresh context, template in docs/review-prompt.md, verdict APPROVE/REQUEST_CHANGES) and a green CI — a failed review or a red CI sends the branch back for fixes and re-review. See AGENTS.md in the repo root for the full convention, including the DSH-sandbox specifics (credentials, retries, Contents-API fallback).
2. Code contributions: PRs to this repository. Keep the architecture contract in docs/design.md truthful: any API dependency must cite its file:line in a tested deepseek-harness revision.
3. New capabilities: follow the existing pattern — typed domain wrapper in src/, tools registered in src/tools.ts, caps in src/config.ts, tests under tests/, docs in docs/.
4. Releases: follow the dsh-plugin-release skill (bump CHANGELOG.md, tag, CI green, npm publish, update the awesome-dsh-plugin listing — for v0.2.0+ the listing entry already exists and only needs a version/ description touch-up when relevant).

Repo conventions

• Plain TypeScript, ESM, built with tsdown into lib/ (not committed).
• Zod v4 for all runtime schemas (matches the harness).
• Tests with vitest; the memory backend is mocked with the same in-memory pattern the harness itself uses (packages/storage/storage-domain/tests).
• Two languages for user-facing docs: English primary, README.zh.md mirror.
• MIT license; DCO-free, sign-off style not required.

Verification checklist before any release

pnpm install && pnpm build && pnpm typecheck && pnpm test && npm pack --dry-run

plus the full local verification loop in docs/handoff.md §6 on a real deployment.