From iterative-dev
Lightweight, plan-mode-driven iterative development workflow with issue-driven sessions. Use when the user asks to "bootstrap a project", "start a session", "init session", "start development", "review project", "project review", "session closeout", "wrap up", or any iterative development activity. Triggers: bootstrap, init, session, iterative, review project, project review, wrap up, closeout, start development, new project. When this skill is invoked, identify the sub-command from the argument (bootstrap, init, or review) and follow the corresponding workflow in the commands/ directory. Load the github-cli:github-cli skill for issue and PR operations.
How this skill is triggered — by the user, by Claude, or both
Slash command
/iterative-dev:iterative-devThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A lightweight, plan-mode-driven development workflow with issue-driven sessions. Each session maps to one GitHub issue, one branch, and one PR.
A lightweight, plan-mode-driven development workflow with issue-driven sessions. Each session maps to one GitHub issue, one branch, and one PR.
Route based on $ARGUMENTS:
| Command | File | Purpose |
|---|---|---|
bootstrap | commands/bootstrap.md | Scaffold a new project with the iterative-dev workflow |
init <issue-number> | commands/init.md | Start a development session from a GitHub issue |
review | commands/review.md | Analyze project state and alignment |
Read the corresponding command file and follow its instructions. If no sub-command is provided, explain the available commands and the workflow conventions below.
.claude/project/ — The Authoritative DocumentThe source of truth for the project, organized as a directory of focused files. README.md is the index — vision, high-level architecture, and pointers to detail files. Sub-files cover specific concerns (schemas, requirements, configuration, etc.).
Every session reads README.md to orient, then loads sub-files as needed. The structure adapts to the project, but generally:
These documents are alive. Check off completed requirements. Add new ones as they emerge. Keep each file focused on a single concern.
Each development session is tied to a GitHub issue. The issue body contains the session's scope, approach, constraints, and acceptance criteria. Session continuity flows through the issue chain: each closeout creates the next issue.
Developer owns: production source code, configuration files, infrastructure definitions. Source code is written without doc comments — those are added by the AI during closeout.
AI owns:
tests/ (or the project's equivalent)README.md, project docs (.claude/project/ or equivalent like _project/), CLAUDE.md, memory filesThe boundary is concrete: if a line lives in a .go/.ts/.py source file, the developer writes it (without comments); if it lives anywhere else — docs, comments, tests, prose — the AI writes it.
During init sessions, the AI creates an implementation guide after plan mode. The developer executes the guide. The AI resumes for testing, validation, documentation, and closeout.
Created during init sessions at .claude/context/guides/[issue-number]-[slug].md. Contains problem context, architecture approach, and step-by-step implementation. Archived to .claude/context/guides/.archive/ at session closeout.
Guide conventions:
README.md, project docs, CLAUDE.md, memory files all stay out of the guideLitmus test: if a line would still belong in the file six months later via git blame, it's source code (the developer writes it during execution, the AI adds doc comments during closeout). If it's only useful while reading the guide, it stays in the guide as prose (the AI writes it once when authoring the guide).
Each development session works on its own branch, created from main at session start. Branch names follow the [issue-number]-[slug] pattern (e.g., 7-state-architecture, 12-codex-layer).
Start session (init <issue-number>)
└─ Read issue for session context
└─ Create branch [issue-number]-[slug] from main
└─ Read .claude/project/ for context
└─ Plan in plan mode
└─ Create implementation guide
└─ STOP — developer executes guide
└─ AI resumes: testing, validation, docs
└─ Pre-commit review
├─ Reconcile project docs
├─ Discuss next steps, create next issue
└─ Commit, push, PR (closes current issue)
Before committing, run a structured closeout:
Reconcile project docs — review .claude/project/ against the session's changes. Check off completed requirements, update architecture/schema/state docs, add new sub-files if new concepts emerged. The goal: someone reading the project docs after this session sees a coherent, current picture.
Discuss next steps — have a genuine conversation with the user about what comes next:
Create next issue — capture the discussion's outcome as a new GitHub issue with scope, approach, and acceptance criteria. Tell the user the issue number.
Commit, push, and PR — open a pull request that closes the current issue.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub tailored-agentic-units/tau-marketplace --plugin iterative-dev