Generated and custom commands
Generated commands come from detected project metadata and known technology adapters. Custom commands cover repository-specific work that detection cannot infer, while keeping the same visible executable, arguments, working directory, and safety model.
Use generated tasks when they accurately describe the work. Create a custom task when the command has a stable team purpose that would otherwise live in a personal note or shell-history fragment.
- Give tasks outcome-based names such as Run API tests or Start web client.
- Keep the working directory explicit.
- Prefer an executable and argument list over a shell expression.
Review before the first run
Before running a newly detected or custom command, verify its working directory, execution target, arguments, and confirmation level. This one-time review prevents most cases where the right command runs against the wrong package or service.
A confirmation prompt communicates impact. Normal confirmation is appropriate for consequential but recoverable work; destructive and production levels should be reserved for commands whose effect genuinely deserves a stronger pause.
- Check whether the command runs on the host or in a container.
- Confirm optional environment values before starting.
- Never hide a destructive operation inside a harmless-looking workflow name.
Run and stop processes
The run view keeps output attached to the task and project that produced it. Standard output and error output remain distinct, and the active process state stays visible while you move through the workspace.
When DevDock starts a long-running task, stop it from the run view so the managed process tree is terminated together. Closing an output panel is not the same as stopping the process.
Build reusable workflows
A workflow combines commands that belong to one work session. Order servers, workers, watchers, and readiness checks so later steps do not claim success before their dependencies are usable.
Keep workflows focused. A Local development workflow is easier to understand and recover than one sequence that also mutates databases, seeds production-like data, and performs unrelated maintenance.
- Use readiness URLs only for local loopback services.
- Keep destructive steps manual.
- Verify stop behavior before pinning a workflow to Today.
Read run history
History answers what ran, where it ran, when it started, how it ended, and which output accompanied the result. Use it to compare a failing run with the last successful execution instead of reconstructing the command from memory.
Retention is managed so history remains useful rather than becoming an unbounded log store. If output matters outside that window, copy the relevant non-secret result into the project's normal issue or documentation workflow.
- Start with exit status and duration.
- Check target and working directory before comparing output.
- Look for the first meaningful error rather than the final cascade.
Protect environment values
Ordinary non-secret values can belong to a saved task. Secret custom-task values use operating-system protected storage, while project records keep only the reference needed to retrieve them at execution time.
Avoid printing credentials from the command itself: secure input storage cannot redact arbitrary application output reliably. When sharing run details, review the visible output first.
