A systematic methodology for building full-stack applications - opinionated Claude Code skills covering infrastructure, database, backend, and frontend development.
This plugin provides a comprehensive set of skills that guide Claude Code through a structured, step-by-step approach to building production-ready applications. Each skill follows established best practices and provides clear, opinionated guidance for common development tasks.
Installs the plugin so it loads automatically on every claude session — no flags needed.
Step 1 — Clone the repo
git clone https://github.com/dkoenawan/systematic-dev-kit.gitStep 2 — Register as a local marketplace
claude plugin marketplace add /path/to/systematic-dev-kitStep 3 — Install the plugin
claude plugin install systematic-dev-kit@systematic-dev-kitStep 4 — Verify
claude plugin list
# systematic-dev-kit@systematic-dev-kit should show Status: ✔ enabledAll skills are now available in every claude session. To update later:
claude plugin update systematic-dev-kit@systematic-dev-kitLoads the plugin for the current session only. Nothing is written to your user config.
claude --plugin-dir /path/to/systematic-dev-kitgit clone https://github.com/dkoenawan/systematic-dev-kit.git
cd systematic-dev-kit
claude --plugin-dir .This plugin follows the Claude Code plugin architecture:
systematic-dev-kit/
├── .claude-plugin/
│ └── plugin.json # Plugin manifest
├── skills/ # Agent-based skills
│ ├── init/ # Project initialization (recommended)
│ │ └── SKILL.md
│ ├── brand-designer/ # Brand identity design through discovery
│ │ └── SKILL.md
│ ├── explore/ # Token-efficient codebase investigation
│ │ └── SKILL.md
│ ├── plan/ # Feature planning and spec generation
│ │ ├── SKILL.md
│ │ ├── template.md
│ │ └── examples/
│ │ └── user-management/
│ │ └── feature-spec.md
│ └── bootstrap-new-project/ # Full-stack project bootstrap (deprecated)
│ └── SKILL.md
├── commands/ # Quick command skills (future)
├── hooks/ # Development workflow hooks (future)
├── README.md # This file
└── CLAUDE.md # Guidance for Claude Code instances
Initialize a new full-stack project from a template repository with opt-out component selection.
Default Stack (Opinionated):
| Component | Technology |
|---|---|
| Frontend | React + Vite + TypeScript |
| Backend | Node.js + TypeScript + Prisma |
| Database | PostgreSQL |
| Infrastructure | Docker with docker-compose |
Usage:
/systematic-dev-kit:initHow it works:
- Clones the dev-kit-scaffolding template
- Asks which components to EXCLUDE (opt-out approach)
- Removes unwanted components and updates configs
- Optionally initializes git and installs dependencies
Interactive prompts:
- Project name (default: "my-project")
- Target directory (default: ./{project-name})
- Components to exclude (multi-select, default: none)
- Initialize git? (default: yes)
- Install dependencies? (default: no)
After init:
- Frontend: http://localhost:3000
- Backend: http://localhost:4000
- Database: PostgreSQL on localhost:5432
Design a distinctive brand identity through systematic emotional discovery — generates brand guidelines, CSS custom properties, and optional Tailwind config.
What it produces:
| File | Description |
|---|---|
brand/brand-guideline.md |
Comprehensive brand identity doc (colors, typography, spacing, component tokens, voice & tone) |
brand/brand-theme.css |
CSS custom properties in HSL format with intentionally designed dark mode |
brand/tailwind.brand.js |
Tailwind theme config (only if selected) |
Usage:
/systematic-dev-kit:brand-designerHow it works (6 phases):
- Brand Soul Discovery — Understand the brand's story, future vision, and personality archetype
- Emotional Mapping — Define the three core emotions, sensory environment, and anti-inspiration
- Visual Direction — Gather references, assess existing assets, confirm technical context
- Creative Direction Synthesis — AI presents a narrative creative brief for approval before generating anything
- File Generation — Produces brand guidelines, CSS theme, and optional Tailwind config
- Handoff Summary — Google Fonts snippet, import instructions, and next steps
Key principle: Colors are derived from emotions, not picked from palettes. The skill spends most of its time understanding the brand through discovery before generating any design artifacts.
Token-efficient codebase investigation — reads docs before code, stops when context is sufficient.
What it produces:
A structured Investigation Report covering tech stack, data models, backend structure, frontend structure, key architectural patterns, and relevance to the investigation focus.
Usage:
/systematic-dev-kit:exploreHow it works (3 tiers, stops early):
- Tier 1 — Docs First (always): README → docs/ → CLAUDE.md. Stops here if tech stack, structure, and focus context are clear.
- Tier 2 — Structure (only if needed): package.json → Prisma schema → directory listings. Stops here if focus is answered.
- Tier 3 — Targeted Code (only if needed): ≤5 files, no import chain following, no broad scanning.
Key principle: Thoroughness is not a virtue; precision is. The skill gathers exactly enough context to answer the investigation focus, then stops. Runs on Haiku to minimize token cost.
Invocation modes:
- Standalone: Invoke directly and provide an investigation focus (e.g., "auth system", "order management", "overall architecture")
- Via plan: Automatically invoked by the plan skill when a feature extends existing code — no manual invocation needed
Systematic feature planning through structured discovery — generates detailed specs (DB → Backend → Frontend) that eliminate re-scanning and token waste in future implementation prompts.
What it produces:
| File | Description |
|---|---|
specs/{feature-name}.md |
Complete feature spec with Prisma models, CQRS commands/queries, API shapes, routes, and implementation order |
Usage:
/systematic-dev-kit:planHow it works (5 phases):
- Feature Intent — Understand what the user wants to build, whether it's new or extends existing code, and assess complexity signals
- Layer-by-Layer Design — Walk through Database → Backend → Frontend with adaptive depth (simple features get fewer questions, complex features get the full set plus tradeoff surfacing)
- Spec Synthesis — Synthesize all answers into a complete spec with Prisma models, CQRS operations, TypeScript interfaces, routes, and component hierarchy
- Approval Gate — Present full spec for user approval with option to adjust or rethink
- File Generation & Handoff — Generate spec file and explain how to reference it for implementation
Key principle: Plan once, implement by referencing the spec. Each section of the generated spec is detailed enough to implement a full layer (DB, Backend, or Frontend) without re-scanning the codebase or re-explaining context.
Adaptive depth: The skill adjusts question count based on feature complexity — a simple CRUD feature gets 3 core questions per layer, while a feature with auth, real-time updates, and file uploads gets the full question set plus inline tradeoff surfacing.
Builds and maintains a C4-layered documentation tree that grows incrementally — one file per run. Designed so both humans and agents can navigate to exactly the information they need without reading everything.
The C4 navigation model:
| Level | File | What it answers | When to read |
|---|---|---|---|
| L1 | docs/solution-design.md |
What is this system, who uses it, what external systems does it touch? | Always — it's the entry point |
| L2 | docs/containers.md |
What services run, how do they communicate, how is it deployed? | When you need infrastructure context |
| L3 | docs/<domain>/overview.md |
What is this domain, how does it work end-to-end, which files touch it? | When working in a specific domain |
Key principle: init generates L1 only. Each subsequent maintain run adds or improves exactly one file — L2 first, then one L3 domain per run, then daily clarity reviews. Token cost scales with task scope.
What it produces:
| File | Description |
|---|---|
docs/solution-design.md |
L1 system context: purpose, users, external systems, domain map with drill-down links |
docs/containers.md |
L2 container architecture: deployable units, data flows, deployment model |
docs/<domain>/overview.md |
L3 per-domain: object lifecycle, core entities, code map, gotchas |
docs/clarity-log.md |
Running log of daily clarity reviews — one entry per run |
Usage:
/systematic-dev-kit:doc-maintainer # auto-detect: init if docs/ absent, else maintain
/systematic-dev-kit:doc-maintainer init # generate L1 (solution-design.md) only
/systematic-dev-kit:doc-maintainer maintain # one unit of work: next missing doc, stale patch, or clarity review
/systematic-dev-kit:doc-maintainer refresh # full rewrite of all docs
/systematic-dev-kit:doc-maintainer refresh <domain> # full rewrite of one named domainHow maintain mode prioritises work (one per run):
- Generate
docs/containers.md(L2) if missing - Generate the next missing
docs/<domain>/overview.md(L3), oldest-discovered domain first - Accuracy-patch the most stale existing doc (>30 days old)
- Clarity review — improve prose quality of the oldest-reviewed doc
Scheduling (unattended daily runs):
# Install a daily cron job for a target repo
bash skills/doc-maintainer/scripts/install-schedule.sh /path/to/repo --time 13:15
# Run Monday–Friday only
bash skills/doc-maintainer/scripts/install-schedule.sh /path/to/repo --time 09:00 --days mon-fri
# Uninstall
bash skills/doc-maintainer/scripts/uninstall-schedule.sh /path/to/repo
# Check installed jobs
crontab -l | grep doc-maintainerFile size discipline: Any doc that grows beyond 500 lines is automatically split into a subfolder (docs/<domain>/index.md + sub-files) so no single file ever needs to be read in full to get oriented.
Future direction — feature-tracing (L4): The current C4 tree is architecture-first (system → containers → domains). A natural complement is use-case-first documentation: given a named feature (e.g. "weekly reconciliation", "assessment upload"), trace the end-to-end path it takes through the stack — frontend → backend → domain → adapter → database — naming the specific objects, files, and state transitions at each layer. This would live as docs/features/<feature-name>.md and be generated on-demand rather than scheduled. Not yet implemented; noted here for future development.
Runs large GitHub issues autonomously via cron over multiple days. An interactive planning conversation decomposes an issue into hour-sized tasks, then executes up to 3 per scheduled run — rebasing, implementing, testing, committing, and opening a PR on completion.
Why 6-hour cadence: Aligns with the ~5h Claude quota window so runs don't exhaust quota mid-task.
What it produces:
| Artifact | Description |
|---|---|
specs/<feature-name>/tasks.md |
Plan file with frontmatter (issue, branch, test command, retry counts) + dependency-annotated checklist |
feat/<feature-name> branch |
One commit per completed task, conventional-commit format |
| GitHub PR | Opened automatically on completion, linked to the issue |
Usage:
/systematic-dev-kit:task-executor # auto: show status or start planning
/systematic-dev-kit:task-executor plan <issue-number> # interactive planning conversation
/systematic-dev-kit:task-executor status # show active plan summary
/systematic-dev-kit:task-executor stop # pause (preserves branch + plan)
/systematic-dev-kit:task-executor resume # resume a paused planTypical workflow:
- Open a GitHub issue describing the feature
- Run
plan <issue-number>— 9-phase conversation produces tasks.md, creates branch, installs cron - Come back in a day or two — skill has been committing completed tasks every 6h
- Review the auto-opened PR
Task checklist states:
- [ ]pending- [x]complete- [!] <desc> (failed YYYY-MM-DD: <reason>)failed/skipped
Failure recovery: Failed tasks are marked - [!] after two consecutive failures. Dependent tasks are skipped. If all remaining tasks are blocked, a draft PR is opened with the completed work.
Deprecated: Use
/systematic-dev-kit:initinstead. This skill generates files directly which is less token-efficient.
Bootstrap a complete full-stack project with systematic structure and best practices.
What it creates:
- Infrastructure: Docker setup with docker-compose.yml orchestration
- Backend: Node.js + TypeScript with Clean Architecture
- Domain, Usecases, Interface, Infrastructure layers
- CQRS pattern (commands and queries separated)
- Express.js server with health endpoint
- Swagger API documentation
- OpenAPI specification
- Frontend: React + TypeScript + Vite + Material-UI
- Atomic design structure (atoms, molecules, organisms, templates, pages)
- MUI theme configuration
- Landing page component
- Routing setup
- Database: Placeholder directory for future implementation
- Agent: Placeholder directory for agentic AI workflows
Usage:
/systematic-dev-kit:bootstrap-new-projectInteractive prompts:
- Project name
- Target directory
- Initialize git repository?
- Install dependencies?
After bootstrap:
- Frontend: http://localhost:3000
- Backend API: http://localhost:4000
- API Docs: http://localhost:4000/api-docs
- Health Check: http://localhost:4000/health
To develop this plugin locally:
- Clone the repository
- Make changes to skills, commands, or hooks
- Test using
claude --plugin-dir . - Submit pull requests for improvements
Contributions are welcome! Please feel free to submit pull requests or open issues for:
- New skills for systematic development workflows
- Improvements to existing skills
- Documentation enhancements
- Bug fixes
MIT License - see LICENSE file for details.
Daniel Koenawan