Docs/readme powered by dailybot

AGENTS.md

@@ -39,6 +39,7 @@ the same instructions other agents do.
 | `resume` sub-skill | [skills/deepworkplan/resume/SKILL.md](skills/deepworkplan/resume/SKILL.md) |
 | `status` sub-skill | [skills/deepworkplan/status/SKILL.md](skills/deepworkplan/status/SKILL.md) |
 | `onboard` sub-skill (make any repo AI-first) | [skills/deepworkplan/onboard/SKILL.md](skills/deepworkplan/onboard/SKILL.md) |
+| `author` sub-skill (author/update skills, agents, commands) | [skills/deepworkplan/author/SKILL.md](skills/deepworkplan/author/SKILL.md) |
 | Methodology guide | [skills/deepworkplan/guide/GUIDE.md](skills/deepworkplan/guide/GUIDE.md) |
 | Context detection + `.dwp/` resolution | [skills/deepworkplan/shared/context.sh](skills/deepworkplan/shared/context.sh) |
 | `.dwp/` output path convention | [skills/deepworkplan/shared/dwp-paths.md](skills/deepworkplan/shared/dwp-paths.md) |
@@ -98,6 +99,7 @@ deepworkplan-skill/
     ├── resume/SKILL.md                         ← resume an interrupted plan
     ├── status/SKILL.md                         ← report plan status
     ├── onboard/SKILL.md                        ← make any repo AI-first (+ presets/)
+    ├── author/SKILL.md                         ← author/update skills, agents, commands (+ templates/)
     ├── guide/GUIDE.md                          ← methodology guide
     ├── examples/                               ← plan + orchestrator templates
     └── addons/devcontainer/SKILL.md            ← opt-in devcontainer addon

README.md

@@ -25,6 +25,7 @@ living in a gitignored `.dwp/` directory.
 | **deepworkplan-refine** | Refine a plan draft, or modify the scope/tasks of an existing final plan. |
 | **deepworkplan-resume** | Resume an interrupted plan from its recorded progress state. |
 | **deepworkplan-status** | Report the status of a plan — completed tasks, what's left, and blockers — without executing. |
+| **deepworkplan-author** | Author or update reusable skills, agents, and commands in the current repo — reasons about the repo's `.agents/` layout, follows the Open Agent Skills frontmatter contract, and keeps the `.agents/docs/` catalog in sync. Backs the `/skill-create` and `/agent-create` aliases. |
 
 A root **deepworkplan** meta-skill acts as a router — it describes all
 capabilities and routes to the right sub-skill based on the developer's intent.
@@ -99,6 +100,7 @@ sub-skill:
 - "Create a plan to ship feature X" → **deepworkplan-create**
 - "Execute the plan" / "continue the plan" → **deepworkplan-execute**
 - "What's left on the plan?" → **deepworkplan-status**
+- "Create a skill / agent" / "evolve the kit" → **deepworkplan-author** (also `/skill-create`, `/agent-create`)
 
 Or invoke directly: `/deepworkplan-create`, `/deepworkplan-onboard`, etc.
 
@@ -178,4 +180,4 @@ checklist. Deeper background lives under [`docs/`](docs/) — [DESIGN.md](docs/D
 
 ## :electric_plug: Powered by [Dailybot](https://www.dailybot.com?utm_source=dailybotopensource&utm_medium=deepworkplan-skill)
 
-Dailybot is an [AI Assistant](https://www.dailybot.com/product/ai) powered by ChatGPT that takes chat and collaboration to the next level helping to automate: daily standups, team check-ins, surveys, kudos, virtual watercooler, 1:1 intros, motivation tracking, chatops and more. [Learn more](https://www.dailybot.com?utm_source=dailybotopensource&utm_medium=deepworkplan-skill).
+[Dailybot](https://www.dailybot.com/product/ai) is an AI-powered async communication platform that keeps **people and agents** visible — without adding more meetings or tools. It lives where your team already works (Slack, Teams, Google Chat, Discord, VS Code, and the CLI) and turns scattered signals into clear progress: async check-ins and standups, AI summaries that detect blockers and read team sentiment, workflow automation and approvals, team analytics, and recognition. As AI agents join the workflow, Dailybot surfaces their status and activity right alongside your team's — so long-running agents never go dark. [Learn more](https://www.dailybot.com?utm_source=dailybotopensource&utm_medium=deepworkplan-skill).

docs/SUB_SKILL_GUIDE.md

@@ -1,8 +1,8 @@
 # Adding a New Sub-Skill
 
 Step-by-step for adding a new capability under `skills/deepworkplan/`. Use this
-when you have a new verb that's distinct enough from the existing six
-(`onboard`, `create`, `execute`, `refine`, `resume`, `status`) to deserve its own
+when you have a new verb that's distinct enough from the existing seven
+(`onboard`, `create`, `execute`, `refine`, `resume`, `status`, `author`) to deserve its own
 `SKILL.md`, but tightly enough coupled to the DeepWorkPlan methodology that it
 belongs in this pack rather than a separate repo.
 

skills/deepworkplan/SKILL.md

@@ -41,6 +41,7 @@ full step-by-step flow.
 | "resume", "continue the interrupted plan", "/dwp-resume" | **Resume** → read [`resume/SKILL.md`](resume/SKILL.md) |
 | "plan status", "what's left", "/dwp-status" | **Status** → read [`status/SKILL.md`](status/SKILL.md) |
 | "make this repo AI-first", "onboard this repo", "set up AGENTS.md + docs + .agents" | **Onboard** → read [`onboard/SKILL.md`](onboard/SKILL.md) |
+| "create/update a skill or agent", "evolve the kit", "/skill-create", "/agent-create" | **Author** → read [`author/SKILL.md`](author/SKILL.md) |
 
 If the intent is ambiguous between planning and managing existing work, ask the
 developer which they mean before routing.

skills/deepworkplan/addons/README.md

@@ -62,9 +62,12 @@ An addon MAY additionally ship per-stack presets, examples, or migration notes.
 |-------|--------|--------|
 | Devcontainer support | [`addons/devcontainer/`](devcontainer/SKILL.md) | **Authored** — compose-based `.devcontainer/` + `docker/` with AI-CLI persistence, `dailybot-project-network`, `DOCKER_DEV_ENV=vscode`, project-identity precedence, public-OSS variant, 7 reasoning presets. |
 | Dailybot integration | [`addons/dailybot/`](dailybot/SKILL.md) | **Authored** — opt-in install of the Dailybot agent skill / CLI, auth **deferred** to the Dailybot skill's own consent flow, and an **optional, best-effort, never-blocking** progress/milestone report wired into DWP execution (a plan completion → a Dailybot milestone report). The core methodology has **zero** Dailybot dependency. |
+| Dependency upgrade | [`addons/dependency-upgrade/`](dependency-upgrade/SKILL.md) | **Authored** — opt-in, **package-manager-agnostic** dependency upgrades: detect the repo's real manager (npm/pnpm/yarn + ncu, pip/poetry/uv, cargo, go mod, bundler, composer…), classify by semver, upgrade in safe batches, run the repo's **real** validation gate after each batch, revert a failing batch, summarize. Installs a `/lib-upgrade` delegator into the repo's `.agents/commands/` only when accepted. |
 
 > This README is the mechanism doc. The first addon, `addons/devcontainer/`, is
 > the methodology's proof that the mechanism works; the second,
 > `addons/dailybot/`, shows an addon can layer optional team visibility while
-> keeping the methodology fully vendor-neutral (a repo is conformant with zero
-> addons).
+> keeping the methodology fully vendor-neutral; the third,
+> `addons/dependency-upgrade/`, shows an addon can encode a recurring maintenance
+> workflow that reasons about each repo's actual stack (a repo is conformant with
+> zero addons).

skills/deepworkplan/addons/dependency-upgrade/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: deepworkplan-addon-dependency-upgrade
+description: Optional DeepWorkPlan addon that safely upgrades a repo's dependencies — reasoning about the repo's ACTUAL package manager (npm/pnpm/yarn + ncu, pip/poetry/uv, cargo, go mod, bundler, composer, and more) rather than assuming npm — with a batched, validated, revertible workflow that detects the manager and manifests/lockfiles, classifies upgrades (patch/minor/major), upgrades in safe batches, runs the repo's real validation gate after each batch, reverts a failing batch, and summarizes. Opt-in, never required, reconciles with the repo's existing tooling. Use when the developer wants to bring dependencies up to date without breaking the build.
+version: "2.0.2"
+documentation_url: https://deepworkplan.com
+user-invocable: true
+allowed-tools: Bash, Read, Grep, Glob, Edit, Write
+metadata: {"openclaw":{"emoji":"⬆️","homepage":"https://deepworkplan.com"}}
+---
+
+# DeepWorkPlan — Dependency-Upgrade Addon
+
+Safely bring a repo's dependencies up to date with a **batched, validated,
+revertible** workflow. This is the methodology's **third opt-in addon** — it is
+**never** required for a repo to be AI-first.
+
+> ## The rule that overrides everything: REASON about the package manager, then upgrade
+>
+> The legacy version of this workflow assumed npm. **It does not.** The first job
+> is to **detect the repo's actual package manager from the manifest and lockfile
+> that exist** (see `SPEC.md` §2 and `templates/ecosystems.md`), then drive that
+> manager's real upgrade and install commands. Never run `ncu`/`pnpm` in a Go,
+> Rust, Python, Ruby, or PHP repo. Never assume a lockfile you have not seen.
+
+## Read these first (all relative inside the skill)
+
+- [`SPEC.md`](SPEC.md) — the normative (RFC-2119) contract: detection, semver
+  classification, batched-upgrade rule, validate-after-each-batch gate,
+  revert-on-failure rule, reconcile-don't-clobber, validation step.
+- [`templates/ecosystems.md`](templates/ecosystems.md) — the **per-ecosystem
+  reasoning table**: how to detect each manager and its real detect / classify /
+  upgrade / install / lockfile commands. Match the row for the detected stack as
+  a *checklist*, then verify against the real repo — **detected reality wins**.
+- [`templates/upgrade-report.md`](templates/upgrade-report.md) — the report shape
+  to summarize what was upgraded, skipped, reverted, and validated.
+- [`templates/lib-upgrade-command.md`](templates/lib-upgrade-command.md) — the
+  `/lib-upgrade` delegator this addon installs into the target repo's
+  `.agents/commands/` **only when accepted**.
+- `../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-dependency-upgrade` on an already-onboarded
+  repo to upgrade dependencies, or via the installed `/lib-upgrade` delegator.
+
+## The flow
+
+### Step 0 — Consent + clean tree
+1. Confirm the developer wants a dependency upgrade (skip silently if declined —
+   the repo stays baseline-conformant).
+2. **Require a clean (or backed-up) working tree.** Run `git status`; if there
+   are uncommitted changes, ask the developer to commit or stash first. A clean
+   tree is what makes a batch revertible (Step 4).
+
+### Step 1 — Detect the package manager (the part you MUST reason about)
+Detect the manager(s) from the **manifest + lockfile that actually exist**, never
+by assuming npm. Use `templates/ecosystems.md`:
+
+- **JS/TS** → `package.json` + which lockfile: `pnpm-lock.yaml` (pnpm),
+  `yarn.lock` (yarn), `package-lock.json` (npm). `ncu` is the cross-manager
+  version checker; the install/update verb is the detected manager's.
+- **Python** → `pyproject.toml` + `poetry.lock` (poetry) / `uv.lock` (uv);
+  `requirements*.txt` (pip / pip-tools); `Pipfile.lock` (pipenv).
+- **Rust** → `Cargo.toml` + `Cargo.lock` (`cargo update`).
+- **Go** → `go.mod` + `go.sum` (`go get -u` / `go get` per module + `go mod tidy`).
+- **Ruby** → `Gemfile` + `Gemfile.lock` (`bundle update`).
+- **PHP** → `composer.json` + `composer.lock` (`composer update`).
+
+A repo MAY have **more than one** ecosystem (e.g. a JS frontend + a Python
+service). Handle each ecosystem with its own manager, in its own batches.
+
+### Step 2 — Classify upgrades (patch / minor / major)
+For every outdated dependency, classify by semver against the version in the
+manifest/lockfile:
+
+- **patch** `X.Y.Z → X.Y.(Z+1)` — safest (bug fixes).
+- **minor** `X.Y.Z → X.(Y+1).0` — usually safe (additive, backward-compatible).
+- **major** `X.Y.Z → (X+1).0.0` — breaking changes possible.
+
+Group **patch + minor** as the auto-batchable set. **Majors require explicit
+developer approval** before inclusion (present them and wait). Upgrade tightly
+coupled packages **together** (e.g. `typescript` + its plugins; a framework + its
+companion packages) so a peer-dependency constraint is not split across batches.
+
+### Step 3 — Upgrade in safe batches
+Apply upgrades in **small, coherent batches** — never all at once (that makes a
+failure impossible to isolate). A reasonable order: patch batch → minor batch →
+each approved major **on its own**. For each batch, run the detected manager's
+**update-manifest + install** commands (e.g. `ncu -u --target minor` then the
+manager's install; `cargo update -p <crate>`; `go get <module>@latest`;
+`poetry update <pkg>`; `bundle update <gem>`; `composer update <pkg>`). The
+lockfile is regenerated by the manager — never hand-edit it.
+
+### Step 4 — Validate after EACH batch (the gate)
+After every batch, run the **repo's real validation gate** — the commands the
+repo actually uses, discovered from `AGENTS.md` Quick Commands /
+`docs/DEVELOPMENT_COMMANDS.md` / the manifest's scripts, or the devcontainer's
+`codecheck`/`check`/`fix`/`test` aliases if that addon is present. Examples:
+`pnpm run biome:check && pnpm run astro:check && pnpm run build`;
+`ruff check && mypy && pytest`; `cargo test`; `go build ./... && go test ./...`;
+`bundle exec rspec`; `composer test`. **Never invent a gate** — use the repo's
+real one.
+
+### Step 5 — Revert a failing batch
+If the gate fails for a batch, **revert just that batch** and continue:
+restore the manifest **and** lockfile (`git checkout -- <manifest> <lockfile>`),
+re-run install to resync, confirm the gate passes again, then record the batch as
+**skipped/failed** with the reason. Optionally retry the batch one package at a
+time to isolate the culprit. A failing major is set aside, not forced.
+
+### Step 6 — Summarize
+Produce the report from `templates/upgrade-report.md`: upgraded (by tier),
+skipped (with reason), reverted (with the failing gate), the manager(s) used, the
+files changed (manifest + lockfile), and recommended follow-ups. **Do not commit
+automatically** — surface the diff and let the developer commit (suggest
+`chore(deps): …`).
+
+## Failure-mode guardrails
+
+- **Never required, never blocking.** If the developer declines, stop cleanly.
+- **Reason about the manager.** Never run npm/ncu in a non-JS repo; never assume a
+  lockfile you have not seen.
+- **Never all-at-once.** Batch so a failure is isolable and revertible.
+- **Real gate only.** Validate with the repo's actual commands, never a guess.
+- **Revert, don't push through.** A failing batch is reverted and recorded, never
+  force-installed past a broken gate.
+- **Don't hand-edit lockfiles.** The manager owns them; regenerate via install.
+- **Don't auto-commit.** Surface the diff; the developer commits.