Installation

macOS / Linux

Terminal
# Project-level (recommended)
$ npx codebase-context-skill init

# With bun / pnpm
$ bunx codebase-context-skill init
$ pnpm dlx codebase-context-skill init

# Global install
$ npm install -g codebase-context-skill && ccs init

# One-liner (no npm needed)
$ curl -fsSL https://contextcode.thinqmesh.com/install.sh | bash

Windows

PowerShell / CMD / Git Bash
> npx codebase-context-skill init
> bunx codebase-context-skill init
> npm install -g codebase-context-skill && ccs init

# One-liner (no npm needed)
> irm https://contextcode.thinqmesh.com/install.ps1 | iex

Manual (any OS)

Terminal
$ git clone https://github.com/AnitChaudhry/codebase-context-skill.git
$ cp -r codebase-context-skill/skills/ .claude/skills/ccs/

Quick Start

  1. Install the skill in your project (see above)
  2. Run /ccs:init to index your codebase
  3. Choose your refresh preference (on-demand, incremental, or session-based)
  4. Start using any command — context is now available
Example Session
$ /ccs:init
# Indexes codebase, generates .ccs/ files

$ /ccs:plan "add user authentication"
# Plans the task with dependency-aware context

$ /ccs:build "implement auth from plan"
# Builds with tracked context

$ /ccs:test --fix
# Runs tests, auto-fixes failures

$ /ccs:review staged
# Reviews staged changes

$ /ccs:deploy
# Pre-deployment checklist

Context Files

All generated context lives in .ccs/ at your project root. Add it to .gitignore.

  • project-map.md — File tree + dependency graph showing which files import which
  • architecture.md — Tech stack, patterns (MVC, hooks, etc.), entry points, data flow
  • file-index.md — Every file ranked S/A/B/C/D by importance (import count)
  • conventions.md — Detected coding style, naming patterns, test patterns, import style
  • task.md — Session task log with git-commit-style entries
  • preferences.json — Your refresh mode and settings

Preferences

On first /ccs:init, you'll be asked to choose a refresh mode. This is saved in .ccs/preferences.json.

  • On-demand — Index is only refreshed when you run /ccs:refresh
  • Incremental — Auto-detects changed files and re-indexes only those per query
  • Session-based — Fresh index at the start of each Claude Code session

/ccs:init

Opus 4.6

Deep-research your entire codebase and generate context files in .ccs/. This is the foundation — run it once per project.

  • Scans all source files (JS, TS, Python, Go, Rust, Java, etc.)
  • Extracts imports/exports from file headers (first 50 lines)
  • Builds a dependency graph and ranks files by centrality
  • Detects architecture pattern, naming conventions, test framework
  • Generates project-map, architecture, file-index, and conventions docs

/ccs:status

Haiku 4.5

Shows index health: what's indexed, staleness, file counts per rank, and estimated token savings.

/ccs:refresh

Haiku 4.5

Rebuilds the index. Supports three modes:

  • /ccs:refresh full — Complete rebuild from scratch
  • /ccs:refresh incremental — Only re-index changed files
  • /ccs:refresh session — Incremental + archive old task.md

/ccs:query

Haiku 4.5

Preview which files would be selected for a query without executing anything. Shows file rankings, selection reasons, dependency chains, and estimated token cost.

  • /ccs:query "add dark mode toggle"
  • /ccs:query "fix login redirect bug"

/ccs:plan

Opus 4.6

Creates a full implementation plan before writing any code. Identifies files to read, modify, create, and delete. Includes dependency chains, test strategy, and risk assessment.

  • /ccs:plan "add user authentication with JWT"
  • /ccs:plan "migrate from REST to GraphQL"

/ccs:build

Sonnet 4.6

Implements a feature with full context tracking. Uses the plan (if available), reads only relevant files, follows project conventions, and logs every change in task.md.

  • /ccs:build "implement JWT auth from plan"
  • /ccs:build "add search component with debouncing"

/ccs:refactor

Opus 4.6

Analyzes the full blast radius of a refactor. Maps every file that imports, references, or depends on the target code. Creates an ordered execution plan.

  • /ccs:refactor "rename UserService to AuthService"
  • /ccs:refactor "extract shared validation logic"

/ccs:fix

Sonnet 4.6

Diagnoses and fixes bugs by tracing from symptom to root cause. Uses web search for library-specific errors. Verifies the fix with tests.

  • /ccs:fix "Cannot read properties of undefined (reading 'map')"
  • /ccs:fix "login redirect loops infinitely"

/ccs:test

Sonnet 4.6

Runs tests, diagnoses every failure, suggests fixes, and optionally auto-fixes. Can also write new tests for untested code.

  • /ccs:test — Run all tests
  • /ccs:test src/auth/ — Test specific directory
  • /ccs:test --fix — Run and auto-fix failures
  • /ccs:test --write src/utils.ts — Generate tests for a file
  • /ccs:test --coverage — Run with coverage report

/ccs:audit

Opus 4.6

Systematic code audit across multiple dimensions. Produces severity-ranked findings with actionable fixes.

  • /ccs:audit — Full audit (all dimensions)
  • /ccs:audit security — Security vulnerabilities only
  • /ccs:audit performance — Performance anti-patterns
  • /ccs:audit patterns — Code consistency issues
  • /ccs:audit a11y — Accessibility (UI codebases)
  • /ccs:audit dead-code — Unused exports, unreachable code
  • /ccs:audit deps — Dependency health, vulnerabilities, outdated packages

/ccs:review

Opus 4.6

Code review with full codebase context. Checks correctness, security, performance, convention adherence, maintainability, and test coverage.

  • /ccs:review src/auth/login.ts — Review specific file
  • /ccs:review staged — Review git staged changes
  • /ccs:review changes — Review all uncommitted changes
  • /ccs:review session — Review all files modified this session

/ccs:research

Opus 4.6

Web-powered research engine. Searches official docs, resolves errors, checks dependency compatibility, finds best practices. Results cached in task.md.

  • /ccs:research "CORS policy blocked" — Error research
  • /ccs:research react-query — Library docs lookup
  • /ccs:research deps — Full dependency health check
  • /ccs:research best-practices "error boundaries" — Best practices
  • /ccs:research breaking-changes next.js — Migration guide

/ccs:deploy

Opus 4.6

Pre-deployment checklist verifying: tests pass, build succeeds, linting clean, types check, env vars documented, dependencies secure, no breaking changes, git clean.

/ccs:track

Haiku 4.5

View and manage the session task log.

  • /ccs:track — Summary view (task counts, files touched, test results)
  • /ccs:track detail — Full task log with all entries
  • /ccs:track files — List only files touched this session
  • /ccs:track stats — Session statistics
  • /ccs:track export — Export session as standalone markdown
  • /ccs:track clear — Archive and start fresh

/ccs:connect

Sonnet 4.6

Sets up the MCP server connection for your project. Creates or updates .mcp.json with the CCS remote tools endpoint. Merges safely with any existing MCP servers you already have configured.

  • /ccs:connect — Auto-detect, create/merge config, verify connection

This gives Claude Code access to 6 tools: skill info, command docs, install commands, model strategy, and context file details. Alternatively, use the CLI:

Terminal
$ claude mcp add --transport http ccs https://contextcode.thinqmesh.com/api/mcp

Model Strategy

Each command uses the optimal model for its task:

ModelUsed ForCommands
Haiku 4.5 Lightweight scanning, lookups, status status, refresh, query, track
Sonnet 4.6 Standard coding execution build, fix, test
Opus 4.6 Deep reasoning, architecture, analysis init, plan, refactor, audit, review, research, deploy

MCP Endpoint

The CCS remote MCP server runs on Vercel and exposes 6 tools to Claude Code. No local server needed.

Endpoint

URL
https://contextcode.thinqmesh.com/api/mcp

Available Tools

ToolDescription
ccs-infoSkill overview, features, all install methods
ccs-commandsAll 15 slash commands with descriptions and model assignments
ccs-command-helpDetailed usage for any specific command
ccs-installOS-specific install command for any package manager
ccs-modelsModel strategy — which Claude model handles which task
ccs-context-filesInfo about generated .ccs/ context files

MCP Configuration

The plugin ships with a .mcp.json that configures the MCP server automatically. This file lives at your project root and is committed to git.

Project-level config (.mcp.json)

.mcp.json
{
  "mcpServers": {
    "ccs": {
      "type": "http",
      "url": "https://contextcode.thinqmesh.com/api/mcp"
    }
  }
}

If you already have a .mcp.json with other MCP servers, /ccs:connect merges the ccs entry safely — your existing servers are never overwritten.

Config file locations

FileScopeUse
.mcp.jsonProject-levelShared with team via git (recommended)
~/.claude/settings.jsonGlobalApplies to all projects for this user
.claude/settings.local.jsonProject, user-specificPermissions only — never commit

Verify connection

Terminal
# Health check
$ curl https://contextcode.thinqmesh.com/api/mcp

# List MCP tools (inside Claude Code)
$ claude mcp list
$ claude mcp get ccs

Developed by Thinqmesh Technologies