Executing Plans Inline
obra/superpowers
Has the agent carry out an implementation plan itself, task by task in the current session, keeping a ledger, proving each step with a test and ending with one whole-branch review.
Create an implementation plan and work orders from approved requirements and current system designs.
Install Plan
$ npx skills add kdlbs/kandev --skill plan -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install kdlbs/kandev plan --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/plan .claude/skills/plan && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "plan" agent skill from https://github.com/kdlbs/kandev/tree/main/.agents/skills/plan into .claude/skills/plan/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "plan", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/kdlbs/kandev/tree/main/.agents/skills/planType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add kdlbs/kandev --skill plan -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install kdlbs/kandev plan --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/plan .agents/skills/plan && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "plan" agent skill from https://github.com/kdlbs/kandev/tree/main/.agents/skills/plan into .agents/skills/plan/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "plan", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add kdlbs/kandev --skill plan -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install kdlbs/kandev plan --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/plan .cursor/skills/plan && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "plan" agent skill from https://github.com/kdlbs/kandev/tree/main/.agents/skills/plan into .cursor/skills/plan/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "plan", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/kdlbs/kandev.git --path .agents/skills/plan--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add kdlbs/kandev --skill plan -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install kdlbs/kandev plan --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/plan .gemini/skills/plan && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "plan" agent skill from https://github.com/kdlbs/kandev/tree/main/.agents/skills/plan into .gemini/skills/plan/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "plan", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install kdlbs/kandev planInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add kdlbs/kandev --skill plan -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/plan .github/skills/plan && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "plan" agent skill from https://github.com/kdlbs/kandev/tree/main/.agents/skills/plan into .github/skills/plan/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "plan", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add kdlbs/kandev --skill plan -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install kdlbs/kandev plan --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/kdlbs/kandev.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/plan .opencode/skills/plan && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "plan" agent skill from https://github.com/kdlbs/kandev/tree/main/.agents/skills/plan into .opencode/skills/plan/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "plan", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
plan- GitHub stars
- 909
- Token cost
- ~2.2k tokens
- SKILL.md length
- 798 words
- Files
- 1
- Skills in repo
- 45
- Repo updated
- First seen
- Licence
- AGPL-3.0
At a glance
Create an implementation plan and work orders from approved requirements and current system designs.
- Works in 5 steps: Map the change → Write plan.md → Write work orders → …
- Tasks that involve Planning
- SKILL.md covers Inputs, Outputs and Workflow
- Calls python3 and git
What it does
Plan is an agent skill from kdlbs/kandev. Create an implementation plan and work orders from approved requirements and current system designs. Leave the design package uncommitted for review before implementation.
Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Agent Workflows, covering Planning. The repository describes itself as: AI Kanban & Development Environment. Orchestrate multiple agents, review changes, open PRs. Multi-provider, self-hostable, no telemetry. The licence is AGPL-3.0.
When your agent uses it
- Tasks that involve Planning
Example prompts
- “/plan”
Requirements
- Python 3
Workflow steps
5 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit b734113. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
python3git
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Plan loads about 2.2k tokens when it runs. Until then it costs about 44 tokens; SKILL.md has 798 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from kdlbs/kandev at commit b734113, republished under its AGPL-3.0 licence (© kdlbs). 798 words, ~2,236 tokens.
Download SKILL.mdSave it as
.claude/skills/plan/SKILL.md (or your agent's skills folder).- name
- plan
- description
- Create an implementation plan and work orders from approved requirements and current system designs. Leave the design package uncommitted for review before implementation.
Create an Implementation Plan
Translate requirements and system designs into a delivery plan under
docs/plans/<initiative>/. The plan and its work-order files are implementation
records. They are not product specifications.
Read docs/specs/guide/plans-and-work-orders.md and
docs/specs/guide/traceability-and-lifecycle.md before you write the plan.
Inputs
Read these sources in full:
- The applicable requirement documents and
REQ-*orAC-*IDs. - The applicable system-design documents.
- Related ADRs.
- The relevant source, tests, and one similar implementation.
Use the legacy feature specification during migration only when no replacement requirement or design exists.
Read each spec's Implementation Plans and related-plan links, then inventory
all existing companion plan directories. Treat linked packages as one
synchronized implementation record: reconcile every affected task scope, E2E
scenario matrix, status, and exact final verification results/counts before
completion.
Outputs
Create:
docs/plans/<initiative>/plan.md
docs/plans/<initiative>/task-<NN>-<short-slug>.mdplan.md is the work-package manifest. Each task-*.md file is one work order.
Workflow
1. Map the change
Run the /interview-me assumption check, reusing settled specification choices.
Resolve material blockers before decomposing the affected work. For large
uncertain initiatives, use that skill's decision-mapping reference first.
Identify:
- The required outcomes and acceptance criteria.
- The design boundaries that implementation must preserve.
- Existing models, repositories, services, handlers, clients, stores, and UI.
- Existing tests and end-to-end patterns.
- The dependency order for implementation.
Use python3 scripts/list-docs.py decisions --text <capability-term> --format paths
to locate relevant decisions. Stop when the requirements, system design, ADRs,
and code disagree on a material boundary.
2. Write plan.md
Use this structure:
---
created: YYYY-MM-DD
status: draft
requirements:
- REQ-<SYSTEM>-<CAPABILITY>-001
system_design:
- ../../specs/<system>/system-design/<capability>.md
legacy_specs: []
---
# Implementation Plan: <Initiative>
## Overview
State the result, the implementation order, and the reason for that order.
## Scope
### In scope
- List the owned outcomes.
### Out of scope
- List explicit exclusions.
## Technical approach
Name exact files, symbols, schema changes, contracts, and integration points.
Organize this section by implementation boundary or vertical slice.
For a shared provider or adapter path, include a compact compatibility matrix
covering the provider, transport, identity or capability shape, intended
behavior, verification evidence, and unsupported-shape fallback. Shared
implementation does not imply that every provider is supported; state
conditional coverage explicitly.
## ASCII UI preview
Required when rendered UI changes. Follow the preview contract in
`docs/specs/guide/plans-and-work-orders.md`: show labelled views, relevant
states, desktop/phone composition, and structural requirements. Omit for
packages without UI changes.
## Tests
Map every relevant acceptance criterion to its unit or integration evidence.
Name the exact test file and method.
## E2E tests
Include this section when the change has user-visible behavior. Map each flow
to the applicable `AC-*` IDs and name the Playwright file and project.
## Work orders
- [ ] [Task 01: <Title>](task-01-<slug>.md)
## Verification results
Pending.
## Risks
- Name concrete delivery or compatibility risks.
## Open questions
Delete this section when it is empty.Do not place complete work-order bodies in plan.md.
3. Write work orders
Use this structure:
---
id: "01-<slug>"
title: "<Title>"
status: pending
wave: 1
depends_on: []
plan: "plan.md"
requirements:
- REQ-<SYSTEM>-<CAPABILITY>-001
acceptance_criteria:
- AC-<SYSTEM>-<CAPABILITY>-001.1
system_design:
- ../../specs/<system>/system-design/<capability>.md
---
# Task 01: <Title>
## Summary
State the implementation outcome in two or three sentences.
## In scope
- List the responsibilities that this work order owns.
## Out of scope
- List adjacent work that this work order does not own.
## Acceptance
- Give one to three concrete implementation conditions.
## ASCII UI preview
For a UI work order, include its relevant view or excerpt from the plan with
the same view label, a link to the full preview, and applicable AC references.
Omit for work orders without rendered UI changes.
## Verification
```bash
<exact targeted command>
```
## Files likely touched
- `path/to/file`
## Dependencies
Name prior work orders or write `None`.
## Risks
- Name concrete implementation or compatibility risks, or write `None`.
## Parallelism
`sequential`
## Inputs
- Requirement and system-design sections.
- Existing code and test patterns.
## Results
Pending.Each work order must deliver one independently verifiable outcome in one focused implementation pass. Prefer a narrow end-to-end slice. Split by layer only for a real dependency or verification boundary, not because files occupy different directories. Title wording does not determine task boundaries.
For broad migrations that cannot proceed in vertical slices, sequence compatible expansion, bounded caller migrations, and final removal of the old contract. If a batch cannot pass independently, keep it with its required integration in one work order. Add only dependencies that actually block the outcome. Preserve the exact acceptance IDs, likely files, and verification commands in each work order.
Use parallel-safe only when files are disjoint and the tasks share no schema,
migration, generated contract, lockfile, or package configuration. A wave does
not authorize subagents.
Show full SKILL.md (422 more words)Show less
4. Define verification
Every work order needs exact commands. Use repository make targets when they
exist. Frontend work in a fresh worktree includes the workspace dependency
installation before the first package command.
Write each verification block so that a user can run the complete block in one shell. If commands change directories, use one directory change or isolated subshells.
When implementation is complete, replace Pending with every required command
and its result. Include specification and diff gates that run outside the
product test commands.
User-facing behavior needs end-to-end evidence somewhere in the work package. A low-level work order does not need an artificial browser test.
After implementation and targeted checks pass, run every listed verification
command from its documented working directory. In a multi-command block, root
each command independently with (cd <dir> && ...) or an explicit root reset;
never rely on a preceding cd. Confirm each referenced path exists and stays
inside the tool or package scope, and that every changed test suite is covered
before marking Results complete. Record actual results, not planned or stale counts.
Before marking a new plan package complete, run git diff --check -- docs/plans/<initiative> and git status --short -- docs/plans/<initiative>;
the status check catches untracked work orders. Confirm every work order names
existing REQ-*/AC-* IDs and an existing system-design path. Also verify that
every requirement named by a work order is declared by at least one of its
referenced system designs, and that every work-order design is included by the
plan's system-design list. Run the repository's PR-documentation coverage
preflight when one is available; list-docs and specification lint alone do
not prove this cross-reference coverage.
Do not add generic QA, review, simplify, security, or full-verification tasks. Task checks provide pre-PR evidence. Configured PR reviewers provide semantic review after the PR opens.
5. End the design turn
Leave the full design package, including requirements, system designs, ADRs,
plan, and work orders, unstaged and uncommitted so the user can review its diff
in the workspace. Do not stage or commit these files unless the user explicitly
asks. Check git status --short and include the changed paths in the handoff.
Report the requirement IDs, system designs, plan, work orders, dependency order, exact checks, and open risks. For UI changes, also render a compact ASCII preview inline in the final conversation summary; links alone are not enough. Follow the shared preview contract, including phone composition when it differs. Then end the turn.
Do not ask for plan approval or a model switch. The user reviews the artifacts and sends a later explicit implementation request.
© kdlbs, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in .agents/skills/plan of kdlbs/kandev.
Open the folder on GitHubat commit b734113
Compare with similar skills
Plan next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Plan this skillkdlbs/kandev | 909 | — | ~2.2k | Automated safety check: Pass | AGPL-3.0 | |
| Executing Plans Inlineobra/superpowers | 296k | 2 repos | ~5.1k | Automated safety check: Pass | MIT | |
| Interview Meaddyosmani/agent-skills | 103k | 6 repos | ~3.8k | Automated safety check: Pass | MIT | |
| OpenSpec Guided OnboardingFission-AI/OpenSpec | 71k | 1 repos | ~4.5k | Automated safety check: Pass | MIT | |
| Writing Plansgeeksblabla/stateofdev.ma | 163 | 57 repos | ~661 | Automated safety check: Pass | None | |
| Subagent Driven DevelopmentAsvarox/allkaraoke | 261 | 38 repos | ~1.2k | Automated safety check: Pass | None |
Similar skills
Interview Me
addyosmani/agent-skills
Asks one question at a time, each with a best guess attached, until the agent is about 95 percent sure what you really want, before any plan, spec or code.
OpenSpec Guided Onboarding
Fission-AI/OpenSpec
Walks you through a complete OpenSpec workflow cycle with narration while doing real work in your codebase.
Writing Plans
geeksblabla/stateofdev.ma
A skill your agent uses when design is complete and you need detailed implementation tasks for engineers with zero codebase context - creates comprehensive implementation plans with exact file…
Subagent Driven Development
Asvarox/allkaraoke
A skill your agent uses when executing implementation plans with independent tasks in the current session
Planning With Files
jd-opensource/JoySafeter
Implements Manus-style file-based planning for complex tasks.
More from kdlbs/kandev
All 45 skills in this repoPR Walkthrough
kdlbs/kandev
Generate a single-file HTML walkthrough that explains a PR's purpose, user impact, interface changes, compatibility risks, and implementation.
Debug
kdlbs/kandev
Diagnose Kandev bugs, running-instance issues, UI/browser failures, and runtime behavior.
Harness Improvement
kdlbs/kandev
Improve Kandev's AI harness from session learnings or explicit requests.
Diagram Design
kdlbs/kandev
Create branded architecture, IT current-state, flowchart, sequence, state machine, ER/data model, timeline, swimlane, quadrant, radar/spider, polar chart (polar/radial lollipop), loop/flywheel…
TDD
kdlbs/kandev
Implement changes using Test-Driven Development (Red-Green-Refactor).
Verify
kdlbs/kandev
Run a broad local verification audit only when the user explicitly requests it or PR/CI remediation requires it.
Related
Categories
Questions about Plan
What does Plan do?
Create an implementation plan and work orders from approved requirements and current system designs. Plan is an agent skill from kdlbs/kandev. Create an implementation plan and work orders from approved requirements and current system designs.
When should I use Plan?
Plan fits situations like: tasks that involve Planning.
How do I install Plan in Claude Code?
Run `npx skills add kdlbs/kandev --skill plan -a claude-code`. Or copy the skill folder (.agents/skills/plan in kdlbs/kandev) into .claude/skills/plan in your project. Claude Code loads it when a task matches its description.
How do I install Plan in Codex?
Run `npx skills add kdlbs/kandev --skill plan -a codex`. Or copy the skill folder (.agents/skills/plan in kdlbs/kandev) into .agents/skills/plan in your project. Codex loads it when a task matches its description.
Can I use Plan in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add kdlbs/kandev --skill plan -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/plan, .gemini/skills/plan, .github/skills/plan and .opencode/skills/plan in your project.
What does Plan need to run?
Going by SKILL.md and its folder, Plan needs the command-line tools its instructions call (python3 and git). Our summary lists: Python 3.
Does Plan access the network?
SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Plan safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Plan use?
Plan is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Plan use?
About 2.2k tokens (SKILL.md is roughly 8.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Plan?
Skills that share tags, products or a category with Plan: Executing Plans Inline (obra/superpowers, 296k stars), Interview Me (addyosmani/agent-skills, 103k stars), OpenSpec Guided Onboarding (Fission-AI/OpenSpec, 71k stars) and Writing Plans (geeksblabla/stateofdev.ma, 163 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Plan?
kdlbs (a GitHub organization) maintains it in kdlbs/kandev, which has 909 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on October 8, 2026.
Source: kdlbs/kandev on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.