# Deepworkplan Addon Devcontainer

> Optional DeepWorkPlan addon that adds (or reconciles) a compose-based devcontainer to a repo — base image and supporting services reasoned from the detected stack, with persistent AI-CLI auth, the dailybot-project-network, the DOCKER_DEV_ENV=vscode convention, and project-identity precedence. Opt-in, never required, reconciles existing setups instead of clobbering them. Use when the developer wan…

- **Type:** Skill
- **Install:** `agentstack add skill-dailybothq-deepworkplan-skill-devcontainer`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [DailybotHQ](https://agentstack.voostack.com/s/dailybothq)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [DailybotHQ](https://github.com/DailybotHQ)
- **Source:** https://github.com/DailybotHQ/deepworkplan-skill/tree/main/skills/deepworkplan/addons/devcontainer
- **Website:** https://deepworkplan.com/

## Install

```sh
agentstack add skill-dailybothq-deepworkplan-skill-devcontainer
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# DeepWorkPlan — Devcontainer Addon

Add a **reproducible, isolated dev container** to the target repo so any human or
AI agent gets the same environment, with **AI-CLI auth that survives rebuilds**.
This is the methodology's **first opt-in addon** — it is **never** required for a
repo to be AI-first.

> ## The rule that overrides everything: REASON about the repo, then generate
>
> ~85% of every Dailybot devcontainer is identical — that **common skeleton** is
> the stable part you carry forward. ~15% is repo-specific — base image, user,
> `workspaceFolder`, supporting services, ports, secrets — and that part you
> **reason out from the target repo's actual stack**, never by copying one
> reference repo. The one near-verbatim exception is the **AI-CLI persistence
> entrypoint** (`templates/entrypoint.md`): it is stable enough to copy with only
> the home-path / user adjusted.

## Read these first (all relative inside the skill)

- [`SPEC.md`](SPEC.md) — the normative (RFC-2119) contract: common skeleton,
  per-repo reasoning checklist, project-identity precedence, validation rule,
  public-OSS variant.
- [`templates/presets.md`](templates/presets.md) — the **7 reasoning presets**
  (node-web, node-service, node-lambda, python-service, python-cli-oss,
  static-site, orchestrator-hub). Match one as a *starting checklist*, then
  verify every assumption against the real repo — **detected reality wins**.
- The other `templates/*.md` — reasoning guides for each file you generate.
- `../README.md` — the addon mechanism (opt-in, reconcile-don't-clobber, contract).

## When this runs

- From **`onboard` Phase 7b** — after the core AI-first scaffolding, `onboard`
  offers this addon; if accepted it reads this SKILL and runs the flow below.
- **Directly** — `/deepworkplan-addon-devcontainer` on an already-onboarded repo
  to add or reconcile a devcontainer.

## The flow

### Step 0 — Consent + reconcile check
1. Confirm the developer wants a devcontainer (skip silently if declined — the
   repo stays baseline-conformant).
2. **Detect existing setup.** Look for `.devcontainer/`, `docker/`,
   `docker-compose.{yml,yaml}`, a `Dockerfile`. If any exist, you are in
   **reconcile mode**: you MUST preserve working values and MUST NOT overwrite or
   delete files without explicit approval (see SPEC §Reconcile).

### Step 1 — Reason about the stack (reuse onboard's RECON)
If `onboard` already produced `.dwp/onboard/RECON.md`, read it. Otherwise detect:
language/runtime, package manager (from the lockfile that exists), build/test/
lint/typecheck commands, supporting services implied by the app's dependencies
(DB / cache / queue / emulators), exposed ports, and whether the repo is
**public** (OSS) or private. Pick the matching **preset** from
`templates/presets.md` as a checklist.

### Step 2 — Decide the reasoned ~15% (SPEC §3 checklist)
- **Base image + user + `workspaceFolder`** from the language (Node vs Python; a
  `node` vs created `dev-user`; `/app` vs `/workspace` vs `/code/js`).
- **Supporting services** from real dependencies — only those the app actually
  uses (postgres / pgvector / redis / mailpit / dynamodb / localstack / chromium).
- **Ports**, **secrets handling** (public vs private), **multi-stage** build need,
  locales, extra CLIs (AWS, Lighthouse/chromium).

### Step 3 — Generate / reconcile the files
Using the templates, produce or reconcile:
`.devcontainer/devcontainer.json`, `docker/local/docker-compose.{yaml,yml}`,
`docker/local/{service}/Dockerfile`, `docker/local/{service}/entrypoint.sh`
(the near-verbatim AI-CLI persistence piece), `docker/custom_commands.sh`, and —
**for public repos** — `.dockerignore` + a secret-free `.env.example`. Always:
keep the **common skeleton** (AI-CLI persistence volumes, `dailybot-project-network`,
`DOCKER_DEV_ENV=vscode`→`sleep infinity`, `codecheck`/`check`/`fix`/`test`).

### Step 4 — Project identity
Set identity by the precedence in SPEC §4
(`.dailybot/profile.json` → `DAILYBOT_PROJECT_NAME` → `devcontainer.json name`).
Do not invent a new name if one already resolves.

### Step 5 — Validate (SPEC §6)
Run the validation checklist. Report what was created/reconciled, the chosen
base image + services + ports, identity source, and any deferred items. If a
container build/smoke test cannot run here, say why (don't silently skip).

## Failure-mode guardrails

- **Never required, never blocking.** If the developer declines, stop cleanly.
- **No clobber.** Existing devcontainer/docker files are reconciled or
  backed-up-and-asked, never silently overwritten.
- **No phantom services.** Only add a service the app actually depends on.
- **No secrets in images or in `.env.example`** — especially for public repos.
- **Reason wins over preset.** If the preset and the real repo disagree,
  re-derive from the repo.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [DailybotHQ](https://github.com/DailybotHQ)
- **Source:** [DailybotHQ/deepworkplan-skill](https://github.com/DailybotHQ/deepworkplan-skill)
- **License:** MIT
- **Homepage:** https://deepworkplan.com/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-dailybothq-deepworkplan-skill-devcontainer
- Seller: https://agentstack.voostack.com/s/dailybothq
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.