DEV Community

classx
classx

Posted on

How I Use AI

#githubcopilot #ai #mcp #cli

AI assistants have become a core part of our daily coding routines. However, the biggest challenge when working with them is context loss and the LLM's tendency to "hallucinate," rewriting half the codebase just to implement one minor feature.

Over my time working with Copilot-cli, I’ve developed a rock-solid workflow that solves these exact problems. In this article, I’ll share two essential tools that dramatically improve generation quality, along with a set of strict rules (a system prompt) that keep Copilot on a short leash.

Step 1. Plan First, Code Later: rfc-cli

The most common mistake is asking Copilot to write code right away. Without a clear plan, the AI quickly loses track of the big picture. That’s why the very first thing I do before opening a chat and writing a prompt is creating an RFC (Request for Comments).

To manage this, I use rfc-cli — an excellent CLI tool designed to manage architecture design records and RFCs directly inside the repository.

My RFC Workflow:

  1. Creation: I initialize a new document using rfc-cli new.
  2. Drafting: I sketch out the architecture, goals, and planned changes.
  3. Lifecycle: The document strictly follows a state machine: draft → review → accepted → implemented. Skipping stages is a no-go.
  4. Validation: After any changes, I validate the document structure with rfc-cli check NNNN.

Moreover, all RFCs are stored directly inside the project repository. This is a massive win for project history: the team (and my future self six months from now) can always look back and understand exactly how and why each technical decision was made.

When Copilot joins the task, it already has an accepted RFC to refer to. This completely eliminates any guesswork or arguments about how a feature should be built.

Step 2. Beating AI Amnesia: mem-cli

Copilot-cli is great, but its context window is not infinite. As soon as you start a new session, it forgets what you decided three hours ago, the quirks of your database schema, or your team's local coding conventions.

To preserve state between sessions, I use mem-cli. This is a simple yet incredibly effective MCP (Model Context Protocol) server that acts as a long-term memory layer.

Whenever a critical detail pops up during development (e.g., "always use port 8080" or "do not touch component X, it is currently undergoing a rewrite"), I simply save this fact to mem-cli. Copilot queries this memory dynamically and stays up to date with the actual state of the project.

Step 3. The Copilot Rulebook (System Prompt)

Last but certainly not least: the rules of the game. I feed Copilot a strict set of instructions that it is forbidden to violate. My system prompt is divided into three main blocks:

🛠 Code

The biggest issue with LLMs is over-engineering. To keep Copilot from getting "too creative," I set strict boundaries:

  • Minimalism: Any change must be the absolute minimum required to solve the task. No side-effect modifications in unrelated files.
  • No Initiative: Do not change the architecture, do not duplicate existing components (reuse them!), and do not add new libraries or dependencies without an explicit, well-justified reason.
  • Quality: Avoid code duplication at all costs.

🌿 Git Workflow

Everything here is automated to the limit. Copilot knows exactly how I manage branches and releases (set up for a Rust-based project):

  1. No direct commits to main: Always work in a separate branch. Before creating a new branch, tag the main branch with a pre_ prefix.
  2. Granular tasks: Each feature gets its own branch. Each sub-task gets a sub-branch (format: phase-N/X.Y-description).
  3. Quality Gates: Run tests before every single git commit. Before merging into main, run the full suite: build + test + lint. The main/master branch must always remain green and deployable.
  4. Releasing: Merge using --no-ff. Before merging into the main branch, bump the version in Cargo.toml and write a detailed changelog entry in CHANGELOG.md (in English). After the merge, tag the commit as vX.Y.Z.

🧠 Working Style

  • Autonomy: I don't want Copilot asking for permission at every step (e.g., "May I create this file?"). It must work autonomously until the task is complete.
  • Awareness: Before starting any work, it must read the RFC and the PLAN (if they exist).
  • Order: Always write detailed, clear commit messages.

Conclusion

Combining rfc-cli for upfront planning, mem-cli for long-term memory, and a strict system prompt transforms Copilot-cli from a fancy autocomplete tool into a highly reliable, predictable, and disciplined junior developer that writes code exactly the way I want it.

Top comments (0)