DEV Community: classx

How I Use AI

classx — Thu, 16 Jul 2026 14:11:17 +0000

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:

Creation: I initialize a new document using rfc-cli new.
Drafting: I sketch out the architecture, goals, and planned changes.
Lifecycle: The document strictly follows a state machine: draft → review → accepted → implemented. Skipping stages is a no-go.
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):

No direct commits to main: Always work in a separate branch. Before creating a new branch, tag the main branch with a pre_ prefix.
Granular tasks: Each feature gets its own branch. Each sub-task gets a sub-branch (format: phase-N/X.Y-description).
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.
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.

The Ultra-Minimalist, Blazing-Fast Terminal Text Editor for Focused Note-Taking

classx — Thu, 16 Jul 2026 13:46:21 +0000

If you’re anything like me, you probably have a love-hate relationship with note-taking apps.

Rich text editors with endless formatting options often end up being a distraction. On the flip side, launching a heavy IDE just to jot down a quick thought feels like overkill. While Vim or Nano are great, they aren’t strictly optimized for simple, distraction-free note management.

That is where classx/be-cli comes in. It’s a focus-based, dead-simple terminal text editor built for capture. And yes, it's written in Rust!

Why `be-cli`?

The philosophy behind be-cli is simple: Zero friction. Max focus.

Here is what makes it stand out:

Built with Rust: Thanks to Rust, it compiles down to a single, lightweight binary. No heavy runtime dependencies, no garbage collection pauses—just pure performance and memory safety.
Keyboard-First Workflow: No mouse allowed. Keep your hands on the home row and let your thoughts flow seamlessly.
Zero Distractions: It strips away the clutter. No complex markdown rendering previews, sidebars, or cloud-sync progress bars in your face. Just you and your text.
Blazing Fast: It loads instantly in your terminal. Perfect for offloading your working memory before you lose that train of thought.

Quick Start 🚀

Since it's a Rust project, you can easily install it via Cargo or grab the binary directly:

git clone https://github.com/classx/be-cli.git
cd be-cli
make release && make install

Once installed, just run be in your terminal to start writing.

Who is this for?

If your terminal is your second home and you want a dedicated, lightweight space to jot down ideas without leaving your command-line environment, you should definitely give be-cli a spin.

Check out the repository on GitHub: classx/be-cli

What does your note-taking setup look like? Are you team Obsidian, team Vim, or do you prefer lightweight Rust CLI tools like this one? Let's discuss in the comments!

Dark Matter — Rust-based CLI vault for secure GPG-encrypted config files

classx — Mon, 14 Jul 2025 11:45:16 +0000

Hi everyone! I'm currently learning Rust, and as a hands-on project I built a small command-line utility for Linux called Dark Matter. It's a minimal yet functional vault tool that encrypts sensitive project files using GPG and tracks them in a local SQLite database.

Key Features:

Secure GPG encryption using gpgme
Add / update / remove / export encrypted files
GPG key verification and diagnostics
Local SQLite database for file metadata
100% command-line based — no external/cloud dependencies

Requirements: GPG installed and a valid keypair

Rust toolchain

libgpgme-dev (on Debian/Ubuntu)
sqlite-dev

Repo: https://github.com/classx/dark-matter

I'm still new to Rust, so I’d love feedback — bug reports, feature suggestions, or advice on improving the code. Any contributions or reviews are welcome!

How to copy commits from one Git repo to another?

classx — Mon, 05 Jun 2023 13:05:38 +0000

Clone basic repo

git clone https://github.com/user1/project1
cd project1

Add external repo

git remote add oldrepo https://github.com/user1/project2

Get the old repo commits

git remote update

examine the whole tree

git log --all --oneline --graph --decorate

Copy (cherry-pick) the commits from the old repo into your new local one

git cherry-pick sha-of-commit-one
git cherry-pick sha-of-commit-two
git cherry-pick sha-of-commit-three

check your local repo is correct

git log

send your new tree (repo state) to github

git push origin master

remove the now-unneeded reference to oldrepo

git remote remove oldrepo

DEB package and strange dkms dependencies on Debian 10.10

classx — Mon, 10 Apr 2023 20:18:29 +0000

Imagine that you have Debian 10, kernel version 5.10, and a self-made DEB package that compiles and installs a kernel module using the dkms subsystem. As expected, the package has a dependency on dkms. However, when you tried to install this package with the command

apt install -y ./my-dkms-package.deb

you found that the installer sees that dkms is missing from the system and started its installation. However, dkms also has its dependencies, one of which is linux-headers-common for kernel version 4.19!

Thus, despite having only the active kernel version 5.10 in your system, dependencies for kernel version 4.19 are being installed.
And here comes the strange part - during the package installation and module compilation, headers from kernel version 4.19 are being used!

After that, you see that an error occurs during compilation because (make.log)

/lib/module/linux-4.19 is not found

and the installation cannot be completed.

But as it turns out, there is a way to solve this problem!

If you install dkms separately with the command

apt install dkms

the installed dependencies from kernel version 4.19 will no longer interfere. And after that, you can install your package with the command

apt install -y ./my-dkms-package.deb

and all headers will be correct, i.e., for kernel version 5.10.

So if you encounter such a problem, don't despair! Just install dkms separately, and everything will be fine.

My original topic

Disable bash script output, but save to file log

classx — Wed, 21 Dec 2022 10:31:21 +0000

Option 1

#!/bin/bash
sudo apt install -y package_name | tee -a /tmp/app.log >/dev/null
sudo apt install -y package_name1 | tee -a /tmp/app.log >/dev/null
sudo apt install -y package_name2 | tee -a /tmp/app.log >/dev/null

Option 2

disable all output to tty but save to file

#!/bin/bash
exec 1> >(tee -a /tmp/app.log >/dev/null)
sudo apt install -y package_name
sudo apt install -y package_name1
sudo apt install -y package_name2

Option 3

enable all output to tty and save to file

#!/bin/bash
exec 2> >(tee -a /tmp/app.log >&2) > >(tee -a /tmp/app.log")
sudo apt install -y package_name
sudo apt install -y package_name1
sudo apt install -y package_name2

As function

function __application_log(){
    if [ "${__verbose_mode}" == "no"  ]; then
        exec 1> >(tee -a /tmp/app.log >/dev/null)
    else
        exec 2> >(tee -a /tmp/app.log >&2) > >(tee -a /tmp/app.log")
    fi
}

Jenkins - run shell command on the master

classx — Thu, 01 Dec 2022 06:25:05 +0000

Go to your jenkins instance

https://local-jenkins/script

paste and run it:

def proc = "ls -l".execute()
proc.waitFor()
def b = new StringBuffer()
proc.consumeProcessErrorStream(b)
println proc.exitValue() // print exit code
println proc.text // print output

DEB/RPM meta package

classx — Tue, 15 Mar 2022 06:34:08 +0000

One way to install few packages on the one time, create meta package.
It's easy! The ten line of script and enjoy.

For example, create file my-meta-package.cfg

Section: misc
Priority: optional
Standards-Version: 3.9.2

Package: my-meta-package
Version: 1.0.0-1
Maintainer: Your Name <yourname@example.com>
Depends: package-one, package-two, package-three
Description: My meta package
 The meta package

and run

equivs-build my-meta-package.cfg

Should be get my-meta-package-1.0.0-1.noarch.deb package.

Easy!
If packages in repo and allowed to download can do for install

sudo apt install -y my-meta-package-1.0.0-1.noarch.deb

add package-one, package-two, package-three will be installed as dependencies of my-meta-package.

But here has problem if need install (for example) package-one with specific version.

Doing simple change in the my-meta-package.cfg

Depends: package-one (= 0.1.0), package-two, package-three

and run

equivs-build my-meta-package.cfg

still get my-meta-package-1.0.0-1.noarch.deb package.

Try install it and if package-one (= 0.1.0) is latest version in the repo - enjoy. If not and in repo exist package-one version great that 0.1.0 - install meta package will be failed.

RPM package behaves terribly similar. Difference - yum/dnf do not failed but install latest version.

I don't know how fix this issue!!!

Somebody know?

Two problem DKMS on the Amazon Linux 2

classx — Wed, 23 Feb 2022 05:55:19 +0000

The best way to load the driver into the kernel is to use dkms.

Step 1

to unzip source code to /usr/src

Step 2

Step 3

to build the source against the current kernel
dkms build -m DRIVERNAME -v VERSION

Step 4

install driver
dkms install -m DRIVERNAME -v VERSION

Step 5

Load driver
modprobe DRIVERNAME

That all.

From here began problems.
I have checked step 4 on the Ubuntu 20, RedHat 8, CentOS 7, CentOS 8, and everywhere the driver does not load automatically on step 4 except for Amazon Linux.

Insmod: ERROR – Required key not available

classx — Sun, 11 Jul 2021 06:37:08 +0000

Problem:

insmod: ERROR: could not insert module MODULENAME.ko: Required key not available

Solution:

1) sudo yum install mokutil
2) sudo mokutil —disable-validation
3) When executed, the terminal will let you set up 8-16 digit password (after you do, do not forget Oh ~)
Next, restart the computer, a blue screen (do not be nervous, press any key to enter the selection interface :–)), options are as follows:
– Continue boot
– Change Secure Boot state
– Enroll key from disk
– Enroll hash from disk
to select –>Change Secure Boot state<– , next in line before you enter the password.
requiresEnter password character 7, Meaning that the password bit 7 (this point to note!).
4) enter –> Disable Secure Boot selection <– screen,
select yes (Do not simply press Enter, this would be lost, only to start all over again!).
5) returned to the next screen beginning interface, reboot selection, re-enter the system

Checkout git submodules by tag

classx — Sun, 03 Jan 2021 16:02:26 +0000

In the git documentation can read that the git submodule doesn't support update the submodule by tag.

This is a simple solution:

# update submodule
git submodule update --init
# set tag for boost submodules
DEFAULT_TAG="boost-1.70.0"
# update
git config -f .gitmodules --get-regexp '^submodule\..*\.url$' |
    while read -r KEY MODULE_PATH; do
        NAME="$(echo "${KEY}" | sed 's/^submodule\.\(.*\)\.url$/\1/')"
        if [[ $NAME =~ "boost" ]]; then
          pushd "${NAME}"
          git checkout -b new_branch_boost $DEFAULT_TAG                   
          popd
        fi
    done