DEV Community: Rohit Madas

I built an open source context layer for AI coding tools — here's how it works

Rohit Madas — Sun, 15 Mar 2026 04:55:06 +0000

## The problem

Every AI coding session starts blank.

You open Cursor or Claude Code and before you can ask anything
useful, you spend five minutes re-explaining your project. Same
stack. Same goals. Same conventions. Every time.

I built ctxpilot to fix this permanently.

What it is

ctxpilot is a CLI tool and MCP server that:

Scans your codebase with AI and builds a Living Context Document
Injects that document into Cursor, Claude Code, Codex, and Windsurf via MCP
Auto-updates the document after every git commit via a background daemon

The demo that convinced me

Fresh Codex session. Private React Native project. Zero context pasted.

Asked: "What is this project and what am I working on?"

Codex answered with exact file paths, line numbers, and identified
a specific bug in the cart validation logic — minimum quantity
hardcoded in multiple places, silently coerced with
Math.max(quantity, 6) in cart.ts#L40.

That answer came from the LCD. Not from Codex exploring files.

Three commands

\`bash
npm install -g @ctxpilot/ctxpilot

ctx init # scan codebase, generate LCD
ctx setup # configure all AI clients
ctx watch # start auto-update daemon
`\

How the auto-update works

ctx watch starts a background daemon that watches
.git/refs/heads/ via Chokidar. When a new commit is detected,
it waits 30 seconds then runs ctx update.

ctx update:

Reads git diff since last update
Extracts signals (decisions, completed work, new patterns)
Calls Claude to rewrite the LCD incorporating new signals
Archives any removed content
Writes the updated LCD

The result: every session starts with fresh context. Zero manual work.

How ctx setup works

Running ctx setup inside a project:

Writes MCP server config to ~/.claude/claude_desktop_config.json
Writes MCP server config to ~/.codex/config.toml
Writes MCP server config to ~/.cursor/mcp.json
Writes MCP server config to ~/.windsurf/mcp.json
Creates CLAUDE.md with "read LCD first" instructions
Creates .cursor/rules/ctxpilot.mdc with alwaysApply: true
Creates .windsurf/rules/ctxpilot.md
Creates .agents/skills/ctxpilot/SKILL.md for Codex

All upsert-safe — existing configs are never overwritten, only
the ctxpilot entry is added or updated.

The LCD structure

\`markdown

Living Context Document

Project Identity

GiftExpress - React Native mobile e-commerce app...

Active Goal

Cart validation refactoring...

Technology Stack

React Native 0.80.0 with TypeScript 5.0.4
Zustand 5.0.6 for state management ...

Architecture Patterns

...

In Progress

Cart validation constants extraction

Recently Completed

Secure session management ...

Code Conventions

Strict TypeScript
Named exports ... `\

Technical stack

TypeScript, Node.js 20, ESM
Commander.js for CLI
Chokidar for file watching
simple-git for git integration
@modelcontextprotocol/sdk for MCP server
Anthropic SDK + OpenAI SDK (user's choice of provider)
@iarna/toml for safe TOML merging

Try it

\bash npm install -g @ctxpilot/ctxpilot \\

GitHub: github.com/fewknowme/ctxpilot
Website: fewknowme.github.io/ctxpilot

Open source, MIT license. Issues and PRs welcome.

Versioning! and Versioning?

Rohit Madas — Mon, 10 Nov 2025 14:49:18 +0000

Look, versioning isn't just some administrative checkbox. It's actually how you keep your sanity when building software. Whether you're working with React, React Native, or juggling multiple services, good versioning is what saves you from the "wait, what changed?" moments at 2 AM.

Git: Your Project's Memory

Think of Git as your project's diary. Every commit tells a story about what you were trying to do and why. When you connect it properly with JIRA (or whatever you use), suddenly your code history becomes readable.

Here's what a solid workflow looks like:

JIRA Ticket → WEB-214 | Add password validation
Branch → feature/WEB-214-password-validation
Commit → feat(WEB-214): added dynamic error handling for password
Pull Request → references the ticket and explains what you did
Merge + Tag → marks the release

Why bother? Because:

You can actually trace why that line of code exists
QA knows exactly what to test
When something breaks, you can find the culprit fast
Code reviews stay focused instead of turning into archaeology expeditions

Without this structure, your repo becomes a mystery novel where nobody knows the plot.

npm Versioning: Making Releases Meaningful

Running npm version isn't just bumping numbers. It's you saying "this is a real release, and here's what it means."

When you run it, npm:

Updates your package.json and package-lock.json
Creates a Git commit and tag (like v1.4.2)
Can trigger your CI/CD to actually deploy it

Use Semantic Versioning (SemVer) so people know what to expect:

MAJOR (2.0.0) – "Heads up, things will break"
MINOR (1.3.0) – "New stuff, but your code still works"
PATCH (1.3.4) – "Bug fixes, nothing scary"

For React and React Native projects:

Libraries: This version is what people see on npm
Apps: Keep this in sync with what you deploy, so your versions actually mean something

Tools like standard-version, changesets, or release-please can automate this once your team gets bigger.

App Versioning: What Users Actually See
Code versioning is for engineers. App versioning is for humans using your app.

For React Native:

iOS:

CFBundleShortVersionString is what users see (like 1.5.2)
CFBundleVersion is your internal build number

Android:

versionName is the public version
versionCode increments with every release
Before each production release:
Bump your version numbers
Update the changelog
Tag it in Git so everything lines up

Automating this in CI/CD means you won't forget to do it when you're rushing to ship.

Changelogs: The Unsung Hero

A changelog is basically your "what we did" log. It's not busywork—it's how you prove things got done.

A good changelog helps:

Engineers remember what was in each release
QA know what actually needs testing
Product managers track what shipped when
New team members understand the project's journey

Simple rule: If it's not in the changelog, you can't prove it happened.

You can auto-generate it from commits or write it manually-just be consistent.

Connecting the Dots

The magic happens when everything links together:

JIRA Ticket → Git Branch → Commit → npm Version → App Version → Changelog

Real example:

JIRA: WEB-312 | Optimize image loading
Branch: feature/WEB-312-image-optimization
Commit: perf(WEB-312): improved lazy loading for carousel
npm version: minor → v1.6.0
App Version: 1.6.0 (build 90)
Changelog: "Improved performance for image-heavy pages."

Now you have a complete trail. Anyone can understand what changed, why, and when.

Why This Actually Matters

Good versioning discipline gives you:
Predictable releases instead of chaos
Fast rollbacks when things go wrong
Automation you can trust
Clear audit trails

It makes handovers smoother, reduces confusion between teams, and lets dev, staging, and production environments make sense.

Versioning isn't a side quest. It's the bridge between the code you write and the product people use.

Final Thoughts

Teams that take versioning seriously ship more reliably and with way less drama.

Your version history isn't just metadata—it's the story of your product. Treat it like it matters, because it does.

Sanity V3: Display an Array of References as a Checklist

Rohit Madas — Mon, 11 Aug 2025 14:29:30 +0000

Sanity IO ( Co-author credits to - RD Pennell for v2 Version as base )

If you're building a Sanity Studio and want to display an array of reference fields as a multi-select checklist, here's a full working solution tailored for Sanity V3.
You’ll define:

A custom input component ReferenceSelect

A schema using this component via the components.input override

// Schema.js
{
 name: "ReferenceMultiSelect",
 description: "Select categories",
 title: "Category Type",
 type: "array",
 of: [
 {
 type: "reference",
 to: { type: "categories" },
 },
 ],
 components: {
 input: ReferenceSelect,
 },
 },

// ReferenceSelect.jsx
import React, { useEffect, useState } from "react";
import { Card, Flex, Checkbox, Box, Text } from "@sanity/ui";
import client from "./client";
import { useId } from "@reach/auto-id";
import { FormField, PatchEvent, set } from "sanity";

const ReferenceSelect = React.forwardRef((props, ref) => {
 const [categories, setCategories] = useState([]);

 useEffect(() => {
 const fetchCountries = async () => {
 await client
 .fetch(
 `*[_type == 'categories']{
 ...,
 _id,
 category
 }`
 )
 .then(setCategories);
 };
 fetchCountries();
 }, []);

 const {
 type, // Schema information
 value, // Current field value
 readOnly, // Boolean if field is not editable
 markers, // Markers including validation rules
 presence, // Presence information for collaborative avatars
 compareValue, // Value to check for "edited" functionality
 onFocus, // Method to handle focus state
 onBlur, // Method to handle blur state
 onChange, // Method to handle patch events,
 } = props;

 const handleClick = React.useCallback(
 (e) => {
 const inputValue = {
 _key: e.target.value.slice(0, 10),
 _type: "reference",
 _ref: e.target.value,
 };

 if (value) {
 if (value.some((country) => country._ref === inputValue._ref)) {
 onChange(
 PatchEvent.from(
 set(value.filter((item) => item._ref != inputValue._ref))
 )
 );
 } else {
 onChange(PatchEvent.from(set([...value, inputValue])));
 }
 } else {
 onChange(PatchEvent.from(set([inputValue])));
 }
 },
 [value]
 );

 const inputId = useId();

 return (
 <FormField
 description={type?.schemaType.description} // Creates description from schema
 title={type?.schemaType.title} // Creates label from schema title
 __unstable_markers={markers} // Handles all markers including validation
 __unstable_presence={presence} // Handles presence avatars
 compareValue={compareValue} // Handles "edited" status
 inputId={inputId} // Allows the label to connect to the input field
 readOnly={readOnly}
 >
 {categories.map((cat, index) => (
 <Card key={index} padding={2}>
 <Flex align="center">
 <Checkbox
 id={cat._id}
 style={{ display: "block" }}
 onClick={handleClick}
 onChange={() => console.log("changed")}
 value={cat._id}
 checked={
 value ? value.some((item) => item._ref === cat._id) : false
 }
 />
 <Box flex={1} paddingLeft={3}>
 <Text>
 <label htmlFor={cat._id}>{cat.category}</label>
 </Text>
 </Box>
 </Flex>
 </Card>
 ))}
 </FormField>
 );
});

export default ReferenceSelect;

🧩 Notes for Integration
🔁 _key is derived from the _ref value to keep the array diff-friendly for Sanity.
⚠️ onClick is used instead of onChange to maintain toggle behavior due to Sanity’s event handling.
💾 This assumes you have a working Sanity V3 setup and a categories document type defined.
Link to my original article on Sanity.