DEV Community: Guilherme Sousa

Introducing ccmd: Slash Command Manager for Claude Code

Guilherme Sousa — Thu, 17 Jul 2025 11:00:00 +0000

I've recently published ccmd, a command-line tool I built to help manage Claude Code commands (slash commands, like /migrate-db, /seed, /hello-world, etc.). If you're using Claude Code regularly and creating custom prompts, you’ve probably faced the same issue I did: managing and reusing these commands across different projects gets messy quickly.

The idea is to treat commands as versioned packages—similar to how you manage dependencies with tools like npm, pip, or go mod.

Why I Built It

I love using Claude Code, but I found myself copy-pasting .md files into each repo just to reuse a command. Worse, if I wanted to update one of them, I had no visibility on where else that command was being used. I wanted a way to:

Version control my prompts
Reuse the same command in multiple projects
Easily install/remove/update them
Keep project directories clean

So, I built this tool to do just that.

Installing

You can get started in three ways:

Option 1: via npm (Recommended)

Assuming you have Node.js installed:

npm install -g @gifflet/ccmd

This is the easiest and most portable method, as more users typically have Node.js available than Go.

Option 2: via Go

If you prefer or already use Go:

go install github.com/gifflet/ccmd/cmd/ccmd@latest

Option 3: via Release Page

If you don’t want to install via npm or Go, you can grab a precompiled binary:

👉 Head over to the Releases page and download the executable for your OS (Windows, macOS, Linux). Make sure it’s executable and available in your PATH.

Basic Usage

Inside any Claude-enabled project:

ccmd init                    # sets up a ccmd.yaml
ccmd install <git-url>       # installs a command
ccmd list                    # see what's installed
ccmd update <name>           # update a specific command
ccmd remove <name>           # remove a command

For example:

ccmd install gifflet/hello-world

That installs the command into .claude/commands/, where Claude Code can detect and run it as /hello-world.

Creating Your Own Commands

To publish your own slash command:

mkdir my-command && cd my-command
ccmd init
# Fill in the interactive prompts

Add your index.md (or other entrypoint), commit, and push to GitHub. Then others can install it via:

ccmd install https://github.com/your-user/my-command

Thoughts on Prompts as Code

One of my motivations here is to treat markdown command files as real software artifacts. They deserve:

Versioning
Reuse
Dependency management
Independent evolution from the main repo

This tool helps make that possible.

If you'd like to try it or contribute, the repo is here:
👉 https://github.com/gifflet/ccmd

Feedback, PRs, or ideas are always welcome!

Git Commit Conventions Using Cursor MCP: A Complete Guide

Guilherme Sousa — Thu, 03 Apr 2025 15:04:09 +0000

Ever struggled with maintaining consistent Git practices across your team? You're not alone! Let's dive into how Cursor's Model Context Protocol (MCP) can help enforce Git conventions and make your version control workflow smoother than ever.

🎯 Introduction

Git conventions are crucial for maintaining a clean and organized codebase, especially in team environments. While following these conventions manually can be challenging, Cursor's MCP Git integration makes it almost effortless. In this article, you'll learn how to leverage MCP Git to enforce conventions and streamline your workflow.

✨ Prerequisites

Cursor IDE installed
Basic understanding of Git concepts
A team project using Git

🛠️ Setting Up MCP Git in Cursor

1. Installation and Configuration

There are three ways to set up MCP Git in Cursor:

Using uvx (Recommended)

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "path/to/git/repo"]
    }
  }
}

Using Docker

{
  "mcpServers": {
    "git": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "--mount", "type=bind,src=/Users/username,dst=/Users/username",
        "mcp/git"
      ]
    }
  }
}

Using pip

# First, install the package
pip install mcp-server-git

{
  "mcpServers": {
    "git": {
      "command": "python",
      "args": ["-m", "mcp_server_git", "--repository", "path/to/git/repo"]
    }
  }
}

2. Adding Git MCP Rules

To ensure your project follows proper Git conventions, add the Git MCP rules file to your repository:

Download the git-conventions.mdc file
Create the .cursor/rules directory in your project root if it doesn't exist:

   mkdir -p .cursor/rules

Place the git-conventions.mdc file in the .cursor/rules directory
Open the git-conventions.mdc file in Cursor and verify that:
- The "Rule Type" at the top shows "Agent Requested"
- The "Description" shows "Git conventions and workflow guidelines using Conventional Commits" (If the description is not showing copy the description from the top of the .mdc file)

If the description is not showing correctly:

Copy the description from the top of the .mdc file: "Git conventions and workflow guidelines using Conventional Commits"
Paste it into the Description field in Cursor's rule header

🎁 Benefits of Git MCP with Conventions

Integrating Git MCP with the rules defined in git-conventions.mdc brings several benefits to your team:

1. 🔄 Automatic Standardization

Consistent commit message formatting
Standardized branch naming
Automatic convention validation

2. ⚡ Enhanced Productivity

Reduced time spent on code reviews
Fewer merge conflicts
Cleaner and more organized commit history

3. 📊 Better Traceability

More descriptive and meaningful commits
Easier changelog generation
Better understanding of code changes

📚 Resources and Further Learning

Cursor Like Pro Repository

Want to learn more about maximizing your Cursor IDE experience? Check out the Cursor Like Pro repository! This fantastic resource contains:

Comprehensive guides and tips
Best practices for Cursor
Additional MCP integration examples

💡 Take Action: Visit the repository now to supercharge your Cursor skills!

🎉 Conclusion

Enforcing Git conventions doesn't have to be a manual, time-consuming process. With Cursor's MCP Git integration, you can automate these practices and focus on what matters most - writing great code. Remember, consistent Git practices lead to better collaboration and more maintainable projects.

🚀 Next Steps

Set up your project's Git conventions using MCP
Create team-specific commit message templates
Schedule a team workshop on Git conventions
Visit the Cursor Like Pro repository for more advanced tips

Como Habilitar o Provedor Legado no OpenSSL 3.x

Guilherme Sousa — Fri, 13 Dec 2024 21:26:49 +0000

Com o OpenSSL 3.x, algoritmos antigos como RC2 foram movidos para o provedor legacy. Se você precisa usá-los (por questões de legado ou compatibilidade), é só seguir este passo a passo para habilitá-los.

1. Primeiro: confirme sua versão do OpenSSL

Antes de começar, veja se sua versão do OpenSSL é 3.x. Use o comando:

openssl version

Se a saída for algo como OpenSSL 3.0.9, estamos no caminho certo! Caso contrário, talvez seja necessário atualizar.

2. Ativando o provedor legacy

O segredo está no arquivo de configuração do OpenSSL, o openssl.cnf. Ele geralmente fica aqui:

Linux: /etc/ssl/openssl.cnf
MacOS: /usr/local/etc/openssl/openssl.cnf
Windows: %ProgramFiles%\Common Files\SSL\openssl.cnf

Se não encontrar o arquivo, pode criar um novo.

Adicione ou edite o seguinte trecho:

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

Isso configura o OpenSSL para carregar tanto o provedor padrão quanto o legacy.

3. Exportando a configuração

Agora, informe ao OpenSSL onde está o arquivo atualizado:

export OPENSSL_CONF=/etc/ssl/openssl.cnf

4. Testando os provedores carregados

Verifique se o provedor legacy está ativo:

openssl list -providers

Se tudo estiver correto, você verá algo como:

Providers:
  default
  legacy

Se o legacy não aparecer, revise o arquivo openssl.cnf e o comando de exportação.

5. Testando o uso de algoritmos legados

Agora que o provedor legacy está ativo, você pode usar algoritmos antigos. Vamos testar isso na prática. Crie um arquivo de entrada chamado input.txt (ou substitua pelo nome de um arquivo que você já tenha):

echo "Texto de teste para criptografia." > input.txt

Agora, execute o comando de criptografia usando RC2-40-CBC:

openssl enc -rc2-40-cbc -e -in input.txt -out output.enc -provider legacy

Este comando faz o seguinte:

Lê o arquivo input.txt (que você acabou de criar).
Cria um arquivo criptografado chamado output.enc.
Usa o algoritmo RC2-40-CBC, que depende do provedor legacy.

Para verificar que deu certo, você pode descriptografar o arquivo:

openssl enc -rc2-40-cbc -d -in output.enc -out decrypted.txt -provider legacy

Depois, confira o conteúdo do arquivo decrypted.txt:

cat decrypted.txt

Se tudo correu bem, o texto original deve aparecer.

Dica Extra: Migre para algoritmos modernos

RC2 e outros algoritmos legados são obsoletos e inseguros. Sempre que possível, substitua por algo mais confiável, como AES-256-CBC. Aqui está um exemplo de como usar:

openssl enc -aes-256-cbc -e -in input.txt -out output.enc -k "sua-senha-segura"

Conclusão

Agora você sabe como habilitar o provedor legacy no OpenSSL 3.x e usar algoritmos antigos. Só lembre-se: isso deve ser uma solução temporária. Para novos projetos, prefira algoritmos mais seguros para proteger seus dados!

Monitoring resources spec attributes with kubectl

Guilherme Sousa — Mon, 15 Jan 2024 21:27:15 +0000

When developing a controller for an operator in Kubernetes, it's always good to check if the attributes of the managed resource are being properly handled.

To do this, you can use kubectl in conjunction with jq to inspect the desired property of the resource.

In the command below, for example, you can obtain the configuration defined for the update strategy of each StatefulSet:

kubectl get statefulsets -o json -w | jq -r '.spec.updateStrategy.type'

Where 'spec.updateStrategy.type' is the json path to the property that will be printed to console.

QEMU VM with snapshot setup + samba file sharing

Guilherme Sousa — Wed, 10 Jan 2024 16:08:59 +0000

Requirements

telnet
qemu
samba

Command to install the requirements:

apt-get update && \
  apt-get install -y \
  qemu-system-x86 libvirt-clients \
  libvirt-daemon qemu-kvm samba telnet

Lets do it

Assuming that our terminal is open at /opt/vm create the folder that will be shared with the VM:

mkdir -p shared-resources

Considering that the VM is located in /opt/vm/system-image/windows-11 create the snapshot image /opt/vm/snapshot:

qemu-img create -b /opt/vm/system-image/windows-11 -f qcow2 -F qcow2 /opt/vm/snapshot

Now, run the VM using the previously created snapshot image file and enable the monitor via telnet:

qemu-system-x86_64 -enable-kvm \
    -machine q35 -m 4096 -smp 2 \
    -usb -device usb-kbd -device usb-tablet -rtc base=localtime \
    -device virtio-net-pci,netdev=net0 \
    -netdev user,id=net0,hostfwd=tcp::3000-:3389,hostfwd=tcp::2222-:22,smb=/opt/vm/shared-resources \
    -drive file=snapshot,media=disk,if=virtio \
    -monitor telnet:0.0.0.0:1234,server,nowait \
    -nographic -serial mon:stdio

To save the vm snapshot its recommended to wait for the desired system state before "taking a picture" of it.
Considering that the VM is in the expected state, let's save it:

telnet localhost 1234
savevm state

To close the telnet session press ctrl + [ and type q and ENTER.

With the snapshot saved, now it is possible to boot the VM and load our saved snapshot:

qemu-system-x86_64 -enable-kvm \
    -machine q35 -m 4096 -smp 2 \
    -usb -device usb-kbd -device usb-tablet -rtc base=localtime \
    -device virtio-net-pci,netdev=net0 \
    -netdev user,id=net0,hostfwd=tcp::3000-:3389,hostfwd=tcp::2222-:22,smb=/opt/vm/shared-resources \
    -drive file=/opt/vm/snapshot,media=disk,if=virtio \
    -loadvm state \
    -nographic -serial mon:stdio

Inside the VM (connected remotely with RDP) you can access the shared folder using the following address: 10.0.2.4/qemu

Adicionar um novo mapeamento de porta a um cluster K3D existente

Guilherme Sousa — Thu, 10 Aug 2023 15:05:27 +0000

Considerando que o seguinte serviço foi criado:

apiVersion: v1
kind: Service
metadata:
  name: postgres-outside-cluster
  namespace: default
spec:
  type: NodePort
  selector:
    app: postgres
    replicationRole: primary
  ports:
  - name: port-5432
    protocol: TCP
    port: 5432
    targetPort: 5432
    nodePort: 30543

Ao executar o comando abaixo será possível acessar, no host, o postgres via localhost:5432:

k3d cluster edit k3s-default --port-add 5432:30543@server:0

Onde k3s-default é o nome do cluster, 5432 é a porta do host e 30543 é a porta do node.

Configurando Swagger Springfox em um projeto Spring Boot

Guilherme Sousa — Tue, 28 Feb 2023 06:07:52 +0000

O Swagger é uma ferramenta de software que permite documentar APIs de maneira fácil e padronizada. O Springfox é uma biblioteca que pode ser integrada com o Spring Boot para gerar a documentação da API usando o Swagger.

Aqui estão os passos para configurar o Swagger Springfox em um projeto Spring Boot:

Adicione as dependências necessárias

O primeiro passo é adicionar as dependências necessárias ao arquivo pom.xml (no caso de projetos Maven) ou build.gradle (no caso de projetos Gradle). As dependências são:

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>2.9.2</version>
</dependency>
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger-ui</artifactId>
    <version>2.9.2</version>
</dependency>

Configure o Swagger

Em seguida, é necessário configurar o Swagger em sua aplicação Spring Boot. Isso pode ser feito criando uma classe de configuração com a anotação @EnableSwagger2:

@Configuration
@EnableSwagger2
public class SwaggerConfig {    
    @Bean
    public Docket api() { 
        return new Docket(DocumentationType.SWAGGER_2)  
          .select() 
          .apis(RequestHandlerSelectors.any())              
          .paths(PathSelectors.any())                          
          .build();                                           
    }
}

A classe Docket é usada para configurar as opções do Swagger, como as APIs e os endpoints a serem documentados.

Anote os controladores

Por fim, é necessário anotar os controladores da API com as anotações apropriadas do Swagger. Por exemplo:

@RestController
@RequestMapping("/api")
@Api(value = "API de exemplo", description = "Exemplo de API com Swagger")
public class ExemploController {
    @ApiOperation(value = "Exemplo de endpoint", response = String.class)
    @GetMapping("/exemplo")
    public String exemplo() {
        return "Exemplo de API com Swagger";
    }
}

A anotação @Api é usada para definir o valor e a descrição da API, enquanto a anotação @ApiOperation é usada para definir o valor e o tipo de resposta de um endpoint.

Com esses passos, o Swagger Springfox deve estar configurado e pronto para uso em sua aplicação Spring Boot. Para acessar a interface do usuário do Swagger, basta acessar a URL http://localhost:<porta>/swagger-ui.html, onde <porta> é a porta na qual sua aplicação Spring Boot está sendo executada.