The home for CoPilot enthusiasts

eooo-io/skillr

Write AI instructions once, sync to every tool. One canonical format (.skillr/) compiles to CLAUDE.md, .cursor/rules, Copilot, Windsurf, Cline, and OpenAI configs.

Stars: 2 Language: PHP

Source: https://github.com/eooo-io/skillr

nesjett/agent-config-manager

A CLI tool for transferring AI agent configurations (skills, tools, rules, instructions) between different platforms like GitHub Copilot, Cursor, Claude, and Windsurf.

Stars: 1 Language: TypeScript

Source: https://github.com/nesjett/agent-config-manager

mateusz-pietras/ai-sync

o CLI that keeps a canonical .ai source of rules, skills, agents, prompts, and MCP config, then generates synchronized hard-copy setups for Cursor, GitHub Copilot, and Claude Code (including dynamic instructions/docs and template-driven automation) across repositories.

Stars: 1 Language: Go

Source: https://github.com/mateusz-pietras/ai-sync

August FRAB12 Control - AI Agent Instructions

Project Architecture

This is a dual-layer robotics control system:

HIGH-LEVEL (ROS2_PACKAGE/): ROS2 Python package bocchi providing web-based keyboard control

• Publisher Node: Flask web server + WebSocket server for real-time keyboard input
• Subscriber Node: Processes movement commands and servo controls
• Cross-platform: Runs in Docker with VNC desktop support

LOW-LEVEL (LOW_LEVEL/): PlatformIO C++ firmware for Raspberry Pi Pico

• micro-ROS: Bridges Arduino framework with ROS2 ecosystem
• Hardware Control: 4x DC motors with encoders, servo motor, LED status
• Real-time: Subscribes to /cmd_vel and /servo_position topics

Development Workflow

Docker-First Development

Always use Docker scripts - never run ROS2 commands directly:

# Start development environment
./docker.sh run                    # or ./docker.sh run --desktop for GUI tools
./ros2-docker.sh build            # Build ROS2 workspace
./ros2-docker.sh run bocchi publisher    # Run nodes

# Development cycle
./ros2-docker.sh shell             # Interactive development
./ros2-docker.sh test              # Run all tests
./ros2-docker.sh monitor-topics    # Debug communication

PlatformIO Workflow

LOW_LEVEL/ uses PlatformIO with custom Raspberry Pi Pico platform:

• Board: pico with earlephilhower core
• Framework: Arduino with micro-ROS integration
• Libraries: Custom motor/encoder/servo classes in lib/

Code Patterns & Conventions

ROS2 Python Patterns

• Dependency Injection: Pass hardware interfaces to node constructors
• WebSocket + Flask: Real-time keyboard control via publisher.py (2100+ lines)
• Async Communication: WebSocket for low-latency, REST API fallback
• Testing: Comprehensive WebSocket test suite in test/test_websocket*.py

C++ Embedded Patterns

• RAII Hardware: DCMotor, ServoMotor, IncrementalMotorEncoder classes
• Node Composition: Separate publisher/subscriber nodes in src/nodes/
• Error Handling: RCCHECK/RCSOFTCHECK macros for micro-ROS operations

File Organization

ROS2_PACKAGE/bocchi/
├── publisher.py          # Main web server + ROS2 publisher (Flask + WebSocket)
├── subscriber.py         # Command processor
├── templates/           # Mako templates for web UI
└── static/             # CSS/JS for keyboard interface

LOW_LEVEL/src/
├── main.cpp            # micro-ROS setup + hardware initialization  
├── nodes/              # ROS2 node implementations
└── lib/                # Custom hardware abstraction classes

Key Integration Points

Topic Communication

• /cmd_vel (geometry_msgs/Twist): WASD keyboard → motor control (20Hz)
• /servo_position (std_msgs/Int32): F key → servo toggle (0°/180°)
• /encoder_data: Feedback from hardware to ROS2 system

WebSocket Protocol

Real-time keyboard events via ws://localhost:8765:

{"type": "key_down", "key": "W", "timestamp": 1640995200000}

Docker Network Bridge

• SSH: ssh root@localhost -p 2222 (password: password)
• Web UI: http://localhost:5000
• WebSocket: ws://localhost:8765

Testing Strategy

Run comprehensive test suite covering WebSocket functionality, ROS2 integration, and security:

./ros2-docker.sh test                    # All tests
python3 test_websocket_comprehensive.py # WebSocket-specific

Tests validate: real-time communication, fallback mechanisms, concurrent connections, and message ordering.

Debugging Commands

# Container status and health
./ros2-docker.sh status

# ROS2 system inspection  
./ros2-docker.sh exec "ros2 node list"
./ros2-docker.sh exec "ros2 topic list"
./ros2-docker.sh exec "ros2 topic echo /cmd_vel"

# WebSocket debugging
python3 test/debug_websocket_responses.py

Cross-Platform Notes

• Use --platform linux/amd64 flag for Apple Silicon compatibility
• Desktop image requires --security-opt seccomp=unconfined for Ubuntu Jammy
• WebSocket server binds to 0.0.0.0 for Docker networking

When editing this codebase:

1. Use ./ros2-docker.sh wrapper for all ROS2 operations
2. Test both WebSocket and REST API fallback paths
3. Validate hardware integration with micro-ROS subscriber nodes
4. Follow existing patterns: dependency injection, comprehensive testing, Docker-first development

GitHub Copilot Instructions

Project Overview

Copilot Chat - A modern AI chat application featuring:

• Frontend: Angular 19 with TypeScript, Tailwind CSS, standalone components
• Backend: Node.js/Express API proxy for X.AI's Copilot-4-fast-reasoning model
• Key Features: Real-time chat, A/B testing, response evaluation, conversation management

Architecture

Frontend (copilot-chat/)

• Framework: Angular 19 with standalone components (no modules)
• Styling: Tailwind CSS + SCSS with glass morphism effects
• State Management: Component-based with services
• API Communication: HttpClient service for backend integration

Backend (backend/)

• Framework: Express.js
• Purpose: API proxy to X.AI Copilot API
• Endpoints: /api/chat, /api/evaluate, /api/health
• Security: CORS enabled, API key in environment variables

Coding Standards

TypeScript/Angular (Frontend)

• Use standalone components (no NgModules)
• Follow Angular style guide for component structure
• Use signals for reactive state when appropriate
• Type everything - leverage TypeScript's type safety
• Component naming: *.component.ts → app.ts (simplified)
• Use dependency injection for services
• Keep components focused - extract complex logic to services

Node.js/Express (Backend)

• Use async/await for asynchronous operations
• Implement proper error handling with try-catch
• Return appropriate HTTP status codes
• Validate incoming requests
• Keep routes simple - extract business logic to separate functions
• Use environment variables for configuration

Code Style

• Indentation: 2 spaces
• Quotes: Single quotes for TypeScript/JavaScript
• Semicolons: Required
• Naming Conventions:
  • Variables/functions: camelCase
  • Classes/Interfaces: PascalCase
  • Constants: UPPER_SNAKE_CASE
  • Files: kebab-case

Copilot API Integration

Important Notes

• Model: Always use copilot-4-fast-reasoning
• Temperature Range: 0-2 (not 0-1 like some models)
• System Prompts: Always include as first message
• API Endpoint: https://api.x.ai/v1/chat/completions
• Authentication: Bearer token via XAI_API_KEY

Temperature Guidelines

• 0.3: Focused, deterministic responses
• 0.7: Balanced creativity and consistency (default)
• 1.0: More creative and varied
• 1.5+: Highly creative, experimental

Feature Implementation Guidelines

When Adding New Features

1. Update both frontend service and backend endpoint
2. Add proper TypeScript interfaces for new data structures
3. Implement error handling on both layers
4. Update UI to reflect new functionality
5. Consider responsive design for mobile
6. Add user feedback (loading states, error messages)

UI/UX Standards

• Maintain glass morphism aesthetic (backdrop-blur, gradients)
• Use emoji consistently in UI labels
• Smooth animations (150-300ms transitions)
• Purple/pink/blue color scheme
• Mobile-first responsive design
• Accessibility: proper ARIA labels, keyboard navigation

Error Handling

Frontend

// Always handle HTTP errors gracefully
this.chatService.sendMessage(messages, systemPrompt, temperature)
  .subscribe({
    next: (response) => { /* handle success */ },
    error: (error) => {
      console.error('Error:', error);
      // Show user-friendly message
      this.errorMessage = 'Failed to send message. Please try again.';
    }
  });

Backend

// Always wrap API calls in try-catch
try {
  const response = await axios.post(GROK_API_URL, data, config);
  res.json(response.data);
} catch (error) {
  console.error('Error:', error.response?.data || error.message);
  res.status(error.response?.status || 500).json({ 
    error: error.response?.data?.error?.message || 'Friendly error message' 
  });
}

Testing

• Write unit tests for services and utility functions
• Test API endpoints with various inputs
• Test error scenarios
• Ensure responsive design works on different screen sizes
• Test with different Copilot API responses

Security Considerations

• Never commit API keys or secrets
• Use environment variables for sensitive data
• Validate and sanitize user inputs
• Implement rate limiting for production
• Configure CORS properly for production (don't use *)
• Add request size limits

Deployment

Pre-Deployment Checklist

• Update API URLs from localhost to production
• Configure environment variables
• Build frontend for production (ng build --configuration production)
• Test in production-like environment
• Set up proper CORS policies
• Enable HTTPS
• Set up monitoring/logging

Recommended Platforms

• Frontend: Vercel, Netlify, GitHub Pages
• Backend: Vercel, Railway, Render, Heroku
• Full Stack: Docker + any cloud provider

Environment Variables

Backend Required

XAI_API_KEY=your_api_key_here
PORT=3000
NODE_ENV=production
ALLOWED_ORIGINS=https://your-frontend-url.com

Frontend (environment files)

export const environment = {
  production: true,
  apiUrl: 'https://your-backend-url.com/api'
};

Dependencies Management

• Keep Angular and dependencies up to date
• Review security advisories regularly (npm audit)
• Pin major versions in package.json
• Test thoroughly after dependency updates
• Document any breaking changes

Git Workflow

• Branches: Feature branches from main
• Commits: Clear, descriptive messages with emoji prefixes
  • ✨ New feature
  • 🐛 Bug fix
  • 📝 Documentation
  • 🎨 UI/styling
  • ♻️ Refactoring
  • 🚀 Deployment/performance
• PRs: Required for main branch, include description and testing notes

Additional Notes

• This is a showcase project demonstrating Copilot API integration
• Prioritize user experience and visual polish
• Performance matters - optimize bundle size and API calls
• Keep the UI fun and engaging with emojis and animations
• Document any new features in the README

TFX50 Coding Standards

🎯 Objetivo Principal

Estas regras não são sugestões, são diretrizes mandatórias. O objetivo é produzir código C# (.NET 8+) que seja, em ordem de prioridade:

1. Seguro: Inexpugnável contra ataques comuns.
2. Correto: Livre de bugs e lógica falha.
3. Performático: Rápido e com alocação de memória mínima (Zero-Allocation sempre que possível).
4. Claro: Legível e autoexplicativo, sem necessidade de comentários.
5. Consistente: Uniforme em todo o codebase.
6. Elegante: Esteticamente agradável e fácil de navegar.
7. Manutenível: Fácil de modificar e estender sem introduzir complexidade desnecessária.
8. Testável: Facilmente coberto por testes automatizados.
9. Escalável: Projetado para crescer com o sistema.
10. Sustentável: Baixo custo de manutenção a longo prazo.
11. Profissional: Reflete as melhores práticas da indústria.
12. Alinhado com o Negócio: Suporta os objetivos e requisitos do CrediSIS.
13. Documentado: Uso adequado de XML-Doc para APIs públicas.
14. Auditável: Facilita a rastreabilidade e conformidade.
15. Moderno: Aproveita os recursos mais recentes do C# e .NET 8+.
16. Eficiente: Minimiza o uso de recursos do sistema.
17. Testes Automatizados: Facilita a criação e manutenção de testes unitários e de integração.
18. Testes Unitários: Código deve ser facilmente testável com frameworks como xUnit, NUnit ou MSTest.
19. Testes de Integração: Facilita a criação de testes que verificam a interação entre componentes.
20. Teste Profundos: Código deve ser projetado para permitir testes profundos, incluindo mocks e stubs.
21. Cobertura de Testes: Código deve ser escrito de forma a maximizar a cobertura de testes automatizados.
22. Testabilidade: Código deve ser modular e desacoplado para facilitar a testabilidade.
23. Mockabilidade: Dependências devem ser injetadas para permitir o uso de mocks em testes.
24. Validações Finais: Sempre realize build e validação final do código antes de mesclar em branches principais.
25. Execução de Teste: Execute todos os testes automatizados antes de qualquer commit final.

Padrões para orientar a escrita de código C# (.NET9 / C#13) e TypeScript neste repositório. O foco é legibilidade, performance e consistência.

Convenções de Nomenclatura

• Classes (C# e TS): inglês, prefixo X, PascalCase.
• Ex.: XUserService, XOrderProcessor.
• Interfaces (C# e TS): inglês, prefixo XI, PascalCase.
• Ex.: XIRepository, XIUserStore.
• Métodos e propriedades: PascalCase.
• Ex.: GetById, SaveChanges, LastAccessAt.
• Campos (field) no corpo da classe: prefixo _ seguido de PascalCase.
• Ex.: _Cache, _Repository, _MaxSize.
• Parâmetros de métodos: p + PascalCase.
• Ex.: pUserID, pOptions, pToken.
• Variáveis locais: mnemônicas, abreviadas, tudo em minúsculo.
• Ex.: lstua (lista de usuários ativos), frsrt (first read table).
• Quando o nome original é abreviado, comp CEP, CPF, ID, URL, HTTP, JSON, XML, SQL, DB, UI, UX, deve manter caixa alta
• Ex.: pUserID, GetByURL, LoadFromDB.
• Nomes sempre em inglês para tipos, membros e arquivos. Esta é uma ampliação das suas instruções, focada em C# (.NET 8+), para que o Copilot (e qualquer desenvolvedor) siga padrões extremamente rigorosos de qualidade, performance, segurança, coerência e elegância.

As novas seções estão marcadas e o conteúdo existente foi integrado e reforçado.

1. Convenções de Nomenclatura (C#)

Aderência estrita a estas regras é fundamental para a legibilidade.

• Classes, Structs, Enums, Records: PascalCase.
  • Ex.: UserService, OrderProcessor, CustomerStatus.
• Interfaces: Prefixo I obrigatório, seguido de PascalCase.
  • Ex.: IRepository, IUserStore, IUnitOfWork.
• Métodos e Propriedades: PascalCase.
  • Ex.: GetByIdAsync, SaveChanges, LastAccessAt, IsValid.
• Campos (Fields) Privados: Prefixo _ obrigatório, seguido de PascalCase.
  • Ex.: _Cache, _Repository, _MaxSize.
• Campos (Fields) Estáticos Privados: Prefixo s_ (para estático) seguido de PascalCase.
• Campos (Fields) de Thread-Static: Prefixo t_ (para thread) seguido de PascalCase.
• Variáveis Locais: camelCase (minúsculas). Devem ser curtas e mnemônicas.
• Parâmetros de Métodos: p (de "parâmetro") seguido de PascalCase (como nos exemplos) ou camelCase simples. Seja consistente. O exemplo original usa pPascalCase.
  • Ex.: GetById(Guid pId), UpdateUser(User pUser).

2. Estilo de Código e Elegância

O código deve ser limpo, vertical e com o mínimo de ruído visual.

• Um Tipo por Arquivo: Mandatório. O nome do arquivo (.cs) deve ser idêntico ao do tipo principal (classe, interface, struct) que ele contém.
• Sem Chaves em Blocos de Linha Única: if, else, foreach, while ou for que contenham apenas uma instrução não devem usar chaves ({}).
  • Ex.: if (pUser == null) return false;
• Retornos Antecipados (Early Returns): Mandatório. Use o padrão guard clause para validar condições no início do método e retornar imediatamente. Isso reduz o aninhamento e a carga cognitiva.
• Sem Comentários: O código deve ser autoexplicativo. A necessidade de um comentário (// ou /* */) indica que o código precisa ser refatorado para maior clareza (ex: extrair método, renomear variável).
  • Exceção Única: XML-Doc (<summary>) para APIs públicas e membros de interfaces é permitido, mas deve descrever o "quê" e não o "como".
• Evitar Métodos Anônimos e Lambdas: Regra Crítica. Evite Func<>, Action<> e expressões lambda (=>) em caminhos de execução.
  • Sempre prefira métodos nomeados (estáticos ou de instância). Isso melhora a legibilidade, facilita o debugging (profiling) e reduz alocações de delegate e closure.
  • Exceção: Configuração de startup (ex: Program.cs) onde a legibilidade é o único foco e a performance não é crítica.

3. Qualidade e Design (SOLID e Imutabilidade)

• SOLID: Os princípios SOLID não são opcionais.
  • S (Single Responsibility): Classes devem ter uma, e apenas uma, razão para mudar.
  • O (Open/Closed): Aberto para extensão (herança, implementação), fechado para modificação.
  • L (Liskov Substitution): Tipos derivados devem ser substituíveis por seus tipos base sem alterar a corretude.
  • I (Interface Segregation): Crie interfaces pequenas e focadas (IUserReader, IUserWriter) em vez de interfaces monolíticas (IUserService).
  • D (Dependency Inversion): Dependa de abstrações (IRepository), não de implementações (SqlRepository). Use Injeção de Dependência (DI) exaustivamente.
• Imutabilidade é o Padrão: Prefira imutabilidade.
  • Use record para Data Transfer Objects (DTOs) e tipos de valor.
  • Use readonly em campos privados sempre que não forem modificados após o construtor.
  • Exponha coleções como IReadOnlyCollection<T> ou IEnumerable<T>, nunca List<T>.

4. Performance Extrema (Zero-Allocation Mindset)

Seja obsessivo com alocações de memória, especialmente em caminhos críticos (hot paths).

• Não Use LINQ em Hot Paths: Evite LINQ (.Where(), .Select(), .ToList(), etc.) em código que é executado com frequência (ex: dentro de loops, processamento de requests).
  • Justificativa: LINQ aloca enumeradores, delegates e coleções intermediárias.
  • Ação: Prefira loops explícitos (for, foreach) para controle manual e zero alocação.
• Async/Await Rigoroso:
  • Use async/await para todo I/O (rede, disco, banco de dados).
  • Nunca use async void, exceto para event handlers de UI.
  • Em código de biblioteca (projetos de serviço, domínio, infra), sempre use ConfigureAwait(false) para evitar deadlocks de contexto de sincronização.
  • Use ValueTask<T> em vez de Task<T> para métodos async que podem, com frequência, completar sincronicamente (ex: retorno de cache).
• Acesso a Dados (EF Core / Dapper):
  • Projeções Sempre: Use Select (projeções) para buscar apenas os campos necessários. Nunca faça SELECT * (context.Users.ToList()).
  • Previna N+1: Sempre que carregar entidades e suas relações, use Include(), ThenInclude() ou projeções explícitas para evitar o problema N+1.
  • Não Materialize Cedo: Não chame .ToList() ou .ToArray() até o último momento necessário.
• Use Tipos de Valor (Structs): Para objetos pequenos e imutáveis que são criados em grande quantidade, prefira readonly struct para evitar pressão no Garbage Collector (GC).
• Strings e Texto:
  • Nunca concatene strings em loops usando +. Use StringBuilder.
  • Em processamento de texto de alta performance (parsing, manipulação de bytes), use Span<T> e ReadOnlySpan<T> para evitar alocações de string e cópias de buffer.
• Classes sealed: Se uma classe não foi desenhada para herança (a maioria não é), marque-a como sealed. Isso ajuda o JIT a otimizar (devirtualização).
• Parâmetros in: Use o modificador in para passar structs grandes (que não sejam readonly) por referência sem permitir modificação, evitando custos de cópia.

5. Segurança Mandatória

Código inseguro invalida todos os outros requisitos.

• Validação de Entrada: Nunca confie na entrada do usuário. Valide toda entrada (de APIs, formulários, query strings) na fronteira do sistema (Controllers, API Endpoints). Use FluentValidation ou validação de modelo.
• SQL Injection: Tolerância Zero.
  • Sempre use queries parametrizadas.
  • Com EF Core, isso é o padrão.
  • Com Dapper ou ADO.NET, use new { Id = pId } ou SqlParameter.
  • Nunca, sob nenhuma circunstância, concatene strings de entrada do usuário para formar uma query SQL.
• Gerenciamento de Segredos:
  • Não hardcodar strings de conexão, chaves de API, senhas ou tokens no código-fonte.
  • Use IConfiguration (lendo de appsettings.json, variáveis de ambiente) ou um cofre de segredos (Azure Key Vault, HashiCorp Vault).
• Autorização e Autenticação:
  • Aplique [Authorize] (ou verificação de permissão equivalente) em todos os endpoints que não sejam publicamente anônimos.
  • Não confie que o front-end fará a verificação de segurança. A API deve ser segura por si só.
• Cross-Site Scripting (XSS): Ao retornar dados que serão renderizados em HTML/JS, garanta que eles sejam devidamente encodados (Razor faz isso por padrão; APIs de frontend precisam de cuidado).
• Criptografia: Use as APIs modernas do .NET (ex: System.Security.Cryptography) para hashing de senhas (com salt) e criptografia de dados sensíveis.

6. Tratamento de Erros e Resiliência

• Não Use Exceções para Controle de Fluxo: Exceções são para casos excepcionais.
  • Para fluxos esperados (ex: "usuário não encontrado"), use o padrão Try* (ex: bool TryGetUser(Guid pId, out User pUser)) ou retorne null / *OrDefault.
• Lance Exceções Específicas: Não lance new Exception("Erro"). Lance exceções de domínio específicas (ex: new InvalidUserStateException("Usuário já está inativo.")) ou tipos padrão (ArgumentNullException, InvalidOperationException).
• Não Suprima Erros: Evite catch (Exception e) {} ou blocos catch que apenas logam o erro e continuam. Capture exceções apenas se você puder tratá-las ou adicionar contexto valioso antes de relançá-las.
• Recursos IDisposable: Use using declarations para garantir a liberação de recursos (ex: DbContext, Stream, HttpClient).
  • using var context = _factory.CreateDbContext(); (Prefira isto ao bloco using {} para reduzir aninhamento).

Resumo (Checklist de Rigor)

1. Nomenclatura: PascalCase, IInterface, _PrivadoPascal, pParametroPascal.
2. Estilo: Um tipo por arquivo. Sem chaves em linha única. Retornos antecipados.
3. Sem "Ruído": Sem comentários. Sem lambdas/anônimos em hot paths.
4. Design: SOLID, DI, Imutabilidade (record, readonly).
5. Performance: sealed, Span<T>, StringBuilder, ConfigureAwait(false).
6. SQL/EF: Sem N+1, use Select (projeção), não materialize cedo.
7. Segurança: Valide toda entrada. Use parâmetros SQL. Não hardcode segredos.

---

Fim das instruções ampliadas.