Menu
Export the office workspace config to the .kandev/ folder for version control
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | kandev-config-export |
| description | Export the office workspace config to the .kandev/ folder for version control |
| kandev | {"system":true,"version":"0.42.0","default_for_roles":["ceo"]} |
Office workspaces persist in SQLite, but the canonical, reviewable representation is the .kandev/ folder. Export when you need to:
The export action is exposed as an HTTP endpoint that the office config service consumes. There is no dedicated agentctl kandev config export command yet — the round-trip happens through the UI's Settings → Config page, or you can invoke the underlying API:
$KANDEV_CLI kandev config export --workspace $KANDEV_WORKSPACE_ID
(Implementation pending: see office-config spec. Until shipped, prefer the Settings UI.)
workspaces/<slug>/kandev.yml — workspace settingsworkspaces/<slug>/agents/*.yml — agent profilesworkspaces/<slug>/projects/*.yml — projectsworkspaces/<slug>/routines/*.yml — routines + triggersworkspaces/<slug>/skills/* — user-imported skillsSystem skills (is_system: true) are not exported — they ship with the kandev binary and are re-installed on every kandev release.
Kandev release & versioning conventions — single SemVer across npm, Homebrew, GitHub release. Use when cutting a release, debugging release artifacts, or answering questions about version channels.
Review changed code for quality, security, and architecture compliance. Use after implementing features or before opening PRs.
Diagnose Kandev bugs, running-instance issues, UI/browser failures, and runtime behavior. Use when the user reports unexpected behavior, asks to investigate, asks to add logs/instrumentation, or when a fix needs root-cause evidence before implementing. Triage first, gather evidence safely, then hand off to /fix or /tdd for code changes.
Write and run web E2E tests (Playwright) using TDD — locations, patterns, commands, and debugging.
Ensures UI feature work ships with desktop and mobile parity, responsive behavior, and mobile Playwright E2E coverage. Use when implementing, planning, reviewing, or testing any new feature, page, component, workflow, form, dialog, sidebar, navigation, dashboard, or visual UI change; if work touches frontend or user-facing UI, this skill must run even when user mentions only desktop or says "new feature".
Create a committed implementation plan from a feature spec. Explores the codebase, designs the approach, and produces docs/plans/<feature>/plan.md plus individual task files. Use after writing a spec and before implementing.