cl-init

Setup & helpers

What it does

/cl-dev:cl-init prepares a repository for CodeLantern workflows. It's a one-time setup you run in a repo the first time you want to use cl-dev there.

Once it finishes, the repository knows how to work with CodeLantern: which project your work lives in and the local scaffolding the skills expect. From that point on, the rest of the workflow (/cl-dev:spec, /cl-dev:claim-issue, and everything after) can run against the repo.

When to use it

Run /cl-dev:cl-init the first time you bring CodeLantern to a repository, before any other skill. It comes before the workflow proper begins:

cl-init → discover → extract → spec → claim-issue → create-impl-plan → implement → review → merge

discover and extract fill the knowledge base that cl-init creates. They're recommended rather than required, and a new repository with little code can run extract first. See Prepare the knowledge base.

You only need it once per repository. If a repo is already set up (for example, a teammate ran it earlier and .codelantern/config.json is committed), you don't run cl-init again, except to turn on an optional automation you skipped. Use /cl-dev:set-context to load the state of existing work and pick up where things left off.

How to invoke it

From your coding agent, in the root of the repository you want to set up:

/cl-dev:cl-init

Before you run it, make sure:

• The cl-dev plugin is installed in your coding agent. If it isn't, follow Developer Setup first.
• Your repository is configured in CodeLantern, with its project-management and source-control providers connected and its project selected. Your personal provider accounts must also be connected. See Integrations and Repositories. If the repository isn't configured, cl-init stops and points you to the portal.
• You're in a clone of the repository, so cl-init can read its git remote.

What it creates

• .codelantern/config.json: the repository and its project-management and source-control providers.
• A knowledge base scaffold in .codelantern/knowledge-base/: project.md, conventions.md, recipes.md, learnings.md, glossary.md, and an adr/ folder. They start almost empty.
• .codelantern/work-items/: where skills keep each issue's plans, session logs, and decisions.
• AGENTS.md: instructions that tell any coding agent how the project uses CodeLantern.
• Workflow labels: the cl-* labels the workflow uses to track each issue's stage.
• A knowledge base sync workflow (.github/workflows/cl-kb-sync.yml). It's added for every repository and used only on GitHub; Azure Repos syncs without it. See Knowledge base sync.

What it asks you

cl-init confirms each choice before writing anything:

• The repository, detected from your git remote. Confirm it or correct it.
• A CLAUDE.md bridge (optional): a one-line file so Claude Code reads AGENTS.md. Codex and Copilot CLI read AGENTS.md directly.
• Board automation (optional), for GitHub Projects. See Project board automation.
• The cloud agent (optional), for GitHub repositories. See Cloud agent.

How you know it worked

cl-init ends with a summary of the repository, providers, config file, knowledge base, labels, and any board mappings you confirmed. The new files are in your working tree. cl-init doesn't commit, push, or run any workflow, so review the changes, commit them, and merge them into your default branch. To check the setup later, run /cl-dev:doctor.

How it creates the workflow files

For GitHub repositories, cl-init creates the workflow files for the options you choose.

• No additional tools required. The plugin includes what it needs to create these files.
• Your existing files are safe. It never overwrites a workflow or script you already have. Each file is reported as created, skipped when it already matches, or a conflict when it differs so you can review it.
• It fails loudly. If a prerequisite is missing or a file cannot be written, cl-init stops with a clear message rather than reporting success.

Repository automation

cl-init sets up the files for knowledge base sync on GitHub and, if you choose them, board automation and the cloud agent. It doesn't run a sync or start a run. What each automation needs, what you do after cl-init, and how to turn one on later are covered in Repository Automation.