DeepSeek Harness Best Practices

Separate product facts from team policy

Read a small scope before acting

1. 01

   Read project instructions first

   Locate repository-level and nested instruction files, then identify which rules apply to the target path.

2. 02

   Inspect only the relevant surface

   Read the target files, tests, configuration, and recent local changes before expanding the search.

3. 03

   State the intended change and proof

   Name the files in scope, the expected observable result, the verification command, and the rollback point.

4. 04

   Work in reversible increments

   Make one coherent change at a time and inspect the diff before moving to the next boundary.

Use the smallest effective permission set

Keep credentials outside prompts and repositories

• Pass only the minimum credential required for the current operation, preferably through a scoped provider or short-lived token.
• Do not paste secrets into chat, project instructions, logs, screenshots, fixtures, or committed environment files.
• Before sharing a diff or artifact, scan tracked and untracked changes for secrets and sensitive local paths.
• If exposure is possible, revoke or rotate first; deleting a file does not invalidate a copied credential.

Design every change for rollback

1. 01

   Capture the baseline

   Record the current revision, configuration, tests, and any external state that the operation may change.

2. 02

   Prefer non-destructive operations

   Use scoped upserts, additive migrations, recoverable file moves, and exact targets instead of broad deletes or resets.

3. 03

   Inspect the complete diff

   Separate intended edits from pre-existing user work and confirm that generated files match their source.

4. 04

   Test recovery where failure matters

   For packages, migrations, or deployments, exercise uninstall, reverse migration, version rollback, or snapshot restore before release.

Verify real behavior, not a completion claim

1. Run the narrow test that proves the edited behavior.
2. Run type, format, build, and broader regression checks appropriate to the risk.
3. Exercise the production build and the actual browser, runtime, database, or package path involved.
4. Inspect console, network, logs, database results, and output artifacts instead of relying only on an exit code.
5. Record failures honestly; a retry is evidence only when the original cause is understood.

Treat Skills and plugins as supply-chain inputs

A Skill is a reusable instruction package, while a plugin can add executable capabilities. Before use, inspect the source and requested capabilities, pin an immutable version when possible, verify licenses and checksums, test in isolation, document ownership, and define an update and removal path. Re-review changes instead of granting permanent trust to a name.

Diagnose failures from the boundary inward

1. Reproduce with the smallest input and a clean or disposable workspace.
2. Confirm the active profile, plugin versions, provider configuration, workspace root, permission preset, and reported sandbox enforcement.
3. Separate model output problems from tool, shell, network, credential, UI, or persistence failures.
4. Inspect structured events and logs, then compare a known-good baseline.
5. Change one variable, rerun the same proof, and preserve the failing evidence until the cause is established.