Introduction

Think vim, but for AI. CeCe is a modal coding assistant for Claude Code, available as a CLI wrapper or plugin.

The Core Idea

CeCe has a chat mode for open-ended collaboration and command modes for focused, autonomous work. This isn't new—Cline has Plan/Act modes, Roo Code has five role-based modes, Cursor has layout modes. But CeCe's modes are different: they're workflow phases, not task types.

In chat mode, you're in control. CeCe discusses, suggests, and implements alongside you. In command modes, CeCe takes the lead on a specific task—scoping an issue, designing an approach, planning PRs, or executing work—while you retain the ability to interrupt at any time.

Why Modes?

Structured workflows help with complex tasks. CeCe's modal design is about enacting these workflows with simple slash commands. This brings:

  • Clear boundaries: You always know which mode you're in. Chat mode shows a 🐱 indicator; command modes show their own indicators.
  • Explicit transitions: You enter command modes deliberately with slash commands like /cece:plan. You exit by completing the task or typing stop.
  • Predictable behavior: Each command mode has defined permissions and constraints. You know what CeCe can and cannot do.

What CeCe Explores

CeCe isn't trying to be the most capable coding assistant. Instead, it explores a few ideas that may be worth considering:

  • Modal behavior: Separating open collaboration from focused execution
  • Agent identity: CeCe has its own git identity and accounts, making agent-authored work transparent
  • Fork-first workflow: CeCe pushes to its own fork, keeping your branches clean until you merge

These ideas aren't unique to CeCe, but the combination creates a particular workflow worth trying.

Getting Started

This guide walks you through installing CeCe and running your first commands.

Installation

CeCe can be installed in two ways: with the CLI wrapper (recommended) or as a plugin only.

The cece CLI wrapper provides the full CeCe experience:

  • Automatically installs the CeCe plugin on first run
  • Injects CeCe's system prompt (modal behavior, identity, git rules)
  • Loads your project configuration from .cece/config.md

Install with Go:

go install github.com/lthms/cece/cmd/cece@latest

Then use cece instead of claude:

cece

Plugin Only

If you only want CeCe's commands without the system prompt (no identity management, git rules, or modal behavior), install the plugin directly in Claude Code:

/plugin marketplace add lthms/cece
/plugin install cece

Note: With plugin-only installation, you get the slash commands but not the full CeCe experience. The CLI wrapper is recommended for the intended workflow.

Configuration

When using the CLI wrapper, CeCe reads project configuration from .cece/config.md in your project root. This file defines:

  • Identity: Name and email for commits
  • Git: Branch naming, commit style, upstream repository
  • Git Strategy: How CeCe pushes changes (fork, remote, or custom)
  • Project Management: Issue tracker location
  • Provisioned Accounts: Platform accounts CeCe can use

On first run without a config file, CeCe will guide you through setup in chat mode. You can also create the file manually:

# Project Configuration

## Identity

Name: CeCe
Email: cece@example.com

## Git

Branch naming: cece/<issue-id>-<description>
Commit style: Imperative mood
Upstream: owner/repo

## Git Strategy

Strategy: fork
Fork account: cece-username
Fork remote name: cece

## Project Management

Issue tracker: github:owner/repo

## Provisioned Accounts

GitHub: cece-username

First Commands

After setup, try these commands to see CeCe in action:

Chat Mode

By default, CeCe operates in chat mode (indicated by 🐱). Ask questions, request code reviews, or discuss implementation approaches. CeCe assists while you drive.

Working on Issues

CeCe uses a multi-phase workflow for issue-driven development:

1. Scope — Create or refine an issue:

/cece:scope #42

CeCe enters scope mode (indicated by ✨) and helps you define what needs to be done, producing a clear Definition of Done.

2. Design — Make architectural decisions:

/cece:design #42

CeCe enters design mode (indicated by 🧠) and works through technical approach, architectural decisions, and open questions.

3. Plan — Break work into PRs:

/cece:plan #42

CeCe enters planning mode (indicated by 📋) and creates a concrete plan with test strategy and PR breakdown.

4. Progress — Execute the plan:

/cece:progress #42

CeCe enters progress mode (indicated by 🔥) and executes autonomously, creating branches, writing code, running tests, and opening PRs. Type stop at any time to interrupt.

Interrupting Commands

In any command mode, type stop to halt CeCe's work. CeCe saves progress and returns to chat mode, telling you what was saved and how to resume.

Concepts

This chapter explains CeCe's modal behavior in detail.

Modes

CeCe operates in exactly one mode at a time. There are two types: chat mode and command modes.

Chat Mode

Chat mode is the default. CeCe starts here and returns here when command modes exit.

Indicator: 🐱

Every response in chat mode begins with 🐱, so you always know when you're in open collaboration.

Behavior:

  • Discuss, analyze, suggest, and implement alongside you
  • Ask questions freely
  • You drive; CeCe assists

In chat mode, CeCe behaves like a typical AI assistant. You ask questions, CeCe answers. You request changes, CeCe makes them. The interaction is open-ended and exploratory.

Command Modes

Command modes are for focused, autonomous work. Each command has a specific purpose: planning an issue, executing a test plan, researching a topic.

Entering a command mode:

/cece:<mode-name> [arguments]

For example, /cece:plan #42 enters planning mode for issue #42.

Indicators: Each command mode has its own indicator:

  • /cece:plan → 📋
  • /cece:progress → 🔥
  • /cece:research → 🔬

The indicator appears at the start of every response, so you always know which mode you're in.

Behavior:

  • CeCe drives; you observe and can interrupt
  • Work is bounded by the command's scope
  • Progress is saved to a defined location (issue comments, files, etc.), making commands idempotent and resumable
  • Permissions are explicit—the command prompt defines what CeCe can and cannot do

Transitions

Entering Command Modes

You enter command modes explicitly with slash commands. CeCe never enters a command mode on its own.

If you're already in a command mode and try to enter another, CeCe will ask you to type stop first. Only one command mode can be active at a time.

Exiting Command Modes

Command modes exit in two ways:

  1. Task completion: CeCe finishes the work and returns to chat mode
  2. Interruption: You type stop to halt the work

When a command mode exits, CeCe returns to chat mode (🐱).

Interruption

Type stop (case-insensitive) to interrupt any command mode.

When CeCe receives stop:

  1. Halts current work
  2. Saves progress to the mode's designated storage
  3. Returns to chat mode
  4. Confirms what was saved and how to resume

Interruption is always available. You never lose control, even during autonomous execution.

Resuming Work

Most command modes support resumption. After interrupting or if context is lost, re-invoke the command with the same arguments:

/cece:progress #42

CeCe reads the saved state (from issue comments, files, or other storage) and continues where it left off.

Comparison

CeCe isn't the only AI coding assistant, and it's not trying to be the best at everything. This chapter explains the ideas CeCe explores and how they differ from other approaches.

What CeCe Explores

CeCe focuses on three ideas that may be worth considering:

Most AI coding assistants operate in a single mode. You chat, ask questions, and request changes in an open-ended conversation. This works well for exploration but can be chaotic for complex, multi-step work.

CeCe separates open collaboration (chat mode) from focused execution (command modes). When you enter a command mode, CeCe takes the lead on a bounded task with explicit permissions and clear exit conditions. You can interrupt at any time with stop.

This isn't better or worse—it's a different tradeoff. Some developers prefer staying in control at all times. Others appreciate handing off well-defined work while retaining the ability to interrupt.

Agent Identity

When an AI assistant creates commits, opens PRs, or posts comments, whose identity appears? Usually yours, because the assistant uses your credentials.

CeCe maintains its own identity:

  • Its own git author (name and email)
  • Its own GitHub/GitLab account
  • Clear indication when work comes from an agent

This makes agent-authored work transparent. When you see a commit from CeCe, you know it wasn't written by a human. When reviewers see a PR from CeCe's account, they know they're reviewing agent work.

This transparency has tradeoffs. Some teams prefer attribution to go to the developer who directed the work. CeCe's approach prioritizes visibility over convenience.

Fork-First Workflow

Many AI assistants push directly to your branches. This is convenient but can clutter your branch history with agent commits that later need rebasing or squashing.

CeCe pushes to its own fork by default. Your branches stay clean until you explicitly merge CeCe's work. You review the PR, and only then do the changes enter your branch.

This adds a step—you must merge the PR—but keeps your local work separate from agent-generated changes. If you prefer direct pushes, CeCe supports that too.

What CeCe Doesn't Do

CeCe isn't optimized for:

  • Minimal setup: CeCe requires a configuration file (.cece/config.md) before full functionality. The CLI wrapper guides you through setup on first run, but assistants that work out of the box have lower friction.
  • Invisible assistance: CeCe's identity is always visible. If you want agent work to appear as your own, CeCe isn't the right fit.

Should You Give It a Try?

CeCe is an experiment. The ideas it explores—modal behavior, agent identity, fork-first workflow—aren't new, but their combination creates a particular workflow that some developers may find useful.

If you value clear boundaries between collaboration and execution, transparent attribution, and clean branch history, CeCe's approach might work for you. If you prefer seamless, invisible assistance, other tools are better suited.

Try it and see.