@ruyfranca/myskills 1.0.5 → 1.0.7

package/.agent/workflows/cto-advisor.md

@@ -0,0 +1,11 @@
+---
+description: Technical leadership guidance for engineering teams and architecture
+---
+
+Ao usar este comando, o Antigravity assume o papel de CTO Advisor.
+
+1. Leia o arquivo [SKILL.md](file:///Users/ruy/Code/mySkills/docs/cto-advisor/SKILL.md).
+2. Forneça orientações estratégicas sobre arquitetura, dívida técnica e escalonamento de times.
+3. Utilize os scripts em `docs/cto-advisor/scripts/` para analisar dívida técnica ou planejar o crescimento do time.
+4. Utilize os templates de ADR em `docs/cto-advisor/references/` para registrar decisões importantes.
+5. Foque em métricas DORA e excelência operacional.

package/.agent/workflows/lead-research.md

@@ -0,0 +1,11 @@
+---
+description: Identify and qualify high-quality leads for sales and business development
+---
+
+Ao usar este comando, o Antigravity assume o papel de Lead Research Assistant.
+
+1. Leia o arquivo [SKILL.md](file:///Users/ruy/Code/mySkills/docs/lead-research-assistant/SKILL.md).
+2. Analise o projeto atual para entender o produto e o perfil de cliente ideal (ICP).
+3. Pesquise empresas que correspondam aos critérios em termos de indústria, tamanho e necessidades tecnológicas.
+4. Gere um relatório priorizado com scores de fit (1-10) e estratégias de abordagem personalizadas.
+5. Ofereça exportar os resultados para CSV ou rascunhar mensagens de outreach.

package/README.md

@@ -133,6 +133,18 @@ Planejamento detalhado de implementação:
 - **Precisão**: Documentação exata de arquivos, comandos e snippets para execução direta.
 - **Análise**: Ferramentas de análise de cobertura e métricas de qualidade.
 
+### [Lead Research Assistant](file:///Users/ruy/Code/mySkills/docs/lead-research-assistant/SKILL.md)
+Inteligência comercial e qualificação de leads:
+- **Prospecção**: Busca ativa de empresas que se encaixam no Perfil de Cliente Ideal (ICP).
+- **Qualificação**: Atribuição de scores de prioridade (1-10) baseados em sinais reais de mercado.
+- **Estratégia**: Criação de pontos de contato personalizados e identificação de tomadores de decisão.
+
+### [CTO Advisor](file:///Users/ruy/Code/mySkills/docs/cto-advisor/SKILL.md)
+Liderança técnica estratégica e governança de arquitetura:
+- **Estratégia**: Roadmaps de longo prazo, inovação e alinhamento de negócios.
+- **Arquitetura**: Gestão de ADRs e revisões sistemáticas de infraestrutura.
+- **Execução**: Escalonamento de times e métricas de excelência (DORA).
+
 ### [Senior DevOps](file:///Users/ruy/Code/mySkills/docs/senior-devops/SKILL.md)
 Automação de infraestrutura e delivery:
 - **IaC**: Scaffolding para Terraform e configurações multi-cloud.
@@ -230,6 +242,8 @@ Você pode acessar as skills diretamente via comandos de barra no chat:
 - `/mobile-design`: Ativa o especialista em design e desenvolvimento mobile de alta performance.
 - `/senior-qa`: Ativa o especialista em garantia de qualidade e automação de testes.
 - `/writing-plans`: Ativa o arquiteto para criação de planos de implementação detalhados e TDD.
+- `/lead-research`: Ativa o especialista em pesquisa e qualificação de leads para vendas e parcerias.
+- `/cto-advisor`: Ativa o conselheiro estratégico para liderança técnica e arquitetura.
 
 ## 📁 Estrutura do Projeto
 

package/docs/cto-advisor/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: CTO Advisor
+description: Strategic technical leadership, architecture governance, team scaling, and engineering excellence.
+---
+
+# CTO Advisor Skill
+
+You are a strategic Chief Technology Officer (CTO). Your goal is to provide high-level leadership, align technology with business goals, scale engineering teams, and ensure technical excellence.
+
+## Core Pillars
+1. **Technology Strategy**: Vision, roadmaps, and innovation management.
+2. **Team Leadership**: Scaling engineering organizations, hiring plans, and performance management.
+3. **Architecture Governance**: ADR (Architecture Decision Records) management and system design reviews.
+4. **Engineering Excellence**: DORA metrics, quality standards, and technical debt management.
+5. **Vendor Management**: Technology evaluation and cost optimization.
+
+## Automation & Tools
+- **Tech Debt Analyzer**: `python scripts/tech_debt_analyzer.py` - Assess and prioritize debt reduction.
+- **Team Scaling Calculator**: `python scripts/team_scaling_calculator.py` - Plan hiring and team structure.
+
+## Reference Documentation
+- `references/architecture_decision_records.md`: ADR templates and decision-making frameworks.
+- `references/engineering_metrics.md`: DORA, Quality, and Team Health KPIs.
+- `references/technology_evaluation_framework.md`: Methods for vendor and tool selection.
+
+## Incident & Crisis Management
+Structured protocols for response, resolution, and post-mortems for major outages or security breaches.
+
+---
+*Liderando a evolução tecnológica para o sucesso dos negócios.*

package/docs/cto-advisor/references/architecture_decision_records.md

@@ -0,0 +1,294 @@
+# Architecture Decision Records (ADR) Framework
+
+## What is an ADR?
+
+Architecture Decision Records capture important architectural decisions made along with their context and consequences. They help maintain institutional knowledge and explain why systems are built the way they are.
+
+## ADR Template
+
+### ADR-[NUMBER]: [TITLE]
+
+**Date**: YYYY-MM-DD  
+**Status**: [Proposed | Accepted | Deprecated | Superseded]  
+**Deciders**: [List of people involved in decision]  
+**Technical Story**: [Ticket/Issue reference]
+
+#### Context and Problem Statement
+
+[Describe the context and problem that needs to be solved. What are we trying to achieve?]
+
+#### Decision Drivers
+
+- [Driver 1: e.g., Performance requirements]
+- [Driver 2: e.g., Time to market]
+- [Driver 3: e.g., Team expertise]
+- [Driver 4: e.g., Cost constraints]
+
+#### Considered Options
+
+1. **Option 1: [Name]**
+2. **Option 2: [Name]**
+3. **Option 3: [Name]**
+
+#### Decision Outcome
+
+**Chosen option**: "[Option Name]", because [justification]
+
+##### Positive Consequences
+- [Consequence 1]
+- [Consequence 2]
+
+##### Negative Consequences
+- [Risk 1 and mitigation]
+- [Risk 2 and mitigation]
+
+#### Pros and Cons of Options
+
+##### Option 1: [Name]
+- **Pros**:
+  - [Advantage 1]
+  - [Advantage 2]
+- **Cons**:
+  - [Disadvantage 1]
+  - [Disadvantage 2]
+
+##### Option 2: [Name]
+[Repeat structure]
+
+#### Links
+- [Related ADRs]
+- [Documentation]
+- [Research/PoCs]
+
+---
+
+## Example ADRs
+
+### ADR-001: Microservices Architecture
+
+**Date**: 2024-01-15  
+**Status**: Accepted  
+**Deciders**: CTO, VP Engineering, Tech Leads  
+**Technical Story**: ARCH-001
+
+#### Context and Problem Statement
+
+Our monolithic application is becoming difficult to scale and deploy. Different teams are stepping on each other's toes, and deployment cycles are getting longer. We need to decide on our architectural approach for the next 3-5 years.
+
+#### Decision Drivers
+
+- Need for independent team deployment
+- Requirement to scale different components independently
+- Different components have different performance characteristics
+- Team size growing from 25 to 75+ engineers
+- Need to support multiple technology stacks
+
+#### Considered Options
+
+1. **Keep Monolith**: Continue with current architecture
+2. **Modular Monolith**: Break into modules but single deployment
+3. **Microservices**: Full service-oriented architecture
+4. **Serverless**: Function-as-a-Service approach
+
+#### Decision Outcome
+
+**Chosen option**: "Microservices", because it best supports our team autonomy needs and scaling requirements, despite added complexity.
+
+##### Positive Consequences
+- Teams can deploy independently
+- Services can scale based on individual needs
+- Technology diversity is possible
+- Fault isolation improved
+
+##### Negative Consequences
+- Increased operational complexity - Mitigated by investing in DevOps
+- Network latency between services - Mitigated by careful service boundaries
+- Data consistency challenges - Mitigated by event sourcing patterns
+
+---
+
+### ADR-002: Container Orchestration Platform
+
+**Date**: 2024-02-01  
+**Status**: Accepted  
+**Deciders**: CTO, DevOps Lead, Platform Team  
+**Technical Story**: INFRA-045
+
+#### Context and Problem Statement
+
+With the move to microservices (ADR-001), we need a container orchestration platform to manage deployment, scaling, and operations of application containers.
+
+#### Decision Drivers
+
+- Need for automated deployment and scaling
+- High availability requirements (99.9% SLA)
+- Multi-cloud strategy (avoid vendor lock-in)
+- Team familiarity and ecosystem maturity
+- Cost considerations
+
+#### Considered Options
+
+1. **Kubernetes**: Industry standard, self-managed
+2. **Amazon ECS**: AWS-native solution
+3. **Docker Swarm**: Simpler alternative
+4. **Nomad**: HashiCorp solution
+
+#### Decision Outcome
+
+**Chosen option**: "Kubernetes", because of its maturity, ecosystem, and multi-cloud support.
+
+##### Positive Consequences
+- Industry standard with huge ecosystem
+- Multi-cloud compatible
+- Strong community support
+- Extensive tooling available
+
+##### Negative Consequences
+- Steep learning curve - Mitigated by training and hiring
+- Operational complexity - Mitigated by managed Kubernetes (EKS/GKE)
+
+---
+
+### ADR-003: API Gateway Strategy
+
+**Date**: 2024-03-15  
+**Status**: Accepted  
+**Deciders**: CTO, Security Lead, API Team  
+**Technical Story**: API-101
+
+#### Context and Problem Statement
+
+With multiple microservices, we need a unified entry point for external clients that handles cross-cutting concerns like authentication, rate limiting, and monitoring.
+
+#### Decision Drivers
+
+- Security requirements (OAuth2, API keys)
+- Need for rate limiting and throttling
+- Monitoring and analytics requirements
+- Developer experience for API consumers
+- Performance (sub-100ms overhead)
+
+#### Considered Options
+
+1. **Kong**: Open-source, plugin ecosystem
+2. **AWS API Gateway**: Managed service
+3. **Istio/Envoy**: Service mesh approach
+4. **Build Custom**: In-house solution
+
+#### Decision Outcome
+
+**Chosen option**: "Kong", because of its flexibility and plugin ecosystem while avoiding vendor lock-in.
+
+---
+
+## Common Architecture Decisions
+
+### 1. Frontend Architecture
+- **Single Page Application (SPA)** vs **Server-Side Rendering (SSR)** vs **Static Site Generation (SSG)**
+- **React** vs **Vue** vs **Angular** vs **Svelte**
+- **Monorepo** vs **Polyrepo**
+- **Micro-frontends** vs **Monolithic frontend**
+
+### 2. Backend Architecture
+- **Monolith** vs **Microservices** vs **Serverless**
+- **REST** vs **GraphQL** vs **gRPC**
+- **Synchronous** vs **Asynchronous** communication
+- **Event-driven** vs **Request-response**
+
+### 3. Data Architecture
+- **SQL** vs **NoSQL** vs **NewSQL**
+- **Single database** vs **Database per service**
+- **CQRS** vs **Traditional CRUD**
+- **Event Sourcing** vs **State-based storage**
+
+### 4. Infrastructure Decisions
+- **Cloud provider**: AWS vs Azure vs GCP vs Multi-cloud
+- **Containers** vs **VMs** vs **Serverless**
+- **Kubernetes** vs **ECS** vs **Cloud Run**
+- **Self-hosted** vs **Managed services**
+
+### 5. Development Practices
+- **Continuous Deployment** vs **Continuous Delivery**
+- **Feature flags** vs **Branch-based deployment**
+- **Blue-green** vs **Canary** vs **Rolling deployment**
+- **GitFlow** vs **GitHub Flow** vs **GitLab Flow**
+
+## ADR Best Practices
+
+### Writing Good ADRs
+
+1. **Keep them short**: 1-2 pages maximum
+2. **Be specific**: Include concrete examples
+3. **Document why, not what**: Focus on reasoning
+4. **Include all options**: Even obviously bad ones
+5. **Be honest about drawbacks**: Every decision has trade-offs
+
+### When to Write ADRs
+
+Write an ADR when:
+- The decision has significant impact
+- Multiple options were seriously considered
+- The decision is hard to reverse
+- You find yourself explaining the same decision repeatedly
+- There's disagreement about the approach
+
+### ADR Lifecycle
+
+1. **Proposed**: Under discussion
+2. **Accepted**: Decision made and being implemented
+3. **Deprecated**: No longer relevant but kept for history
+4. **Superseded**: Replaced by another ADR
+
+### Storage and Discovery
+
+- Store ADRs in your main repository under `docs/architecture/decisions/`
+- Use consistent numbering (ADR-001, ADR-002, etc.)
+- Create an index file linking all ADRs
+- Reference ADRs in code comments where relevant
+- Review ADRs regularly (quarterly) for relevance
+
+## Decision Evaluation Framework
+
+### Technical Factors (40%)
+- Performance impact
+- Scalability potential
+- Security implications
+- Maintainability
+- Technical debt
+
+### Business Factors (30%)
+- Time to market
+- Cost (initial and ongoing)
+- Revenue impact
+- Competitive advantage
+- Regulatory compliance
+
+### Team Factors (30%)
+- Current expertise
+- Learning curve
+- Hiring availability
+- Team preference
+- Training requirements
+
+## Anti-patterns to Avoid
+
+1. **Decision by Committee**: Too many stakeholders leading to compromise solutions
+2. **Analysis Paralysis**: Over-analyzing instead of deciding
+3. **Resume-Driven Development**: Choosing tech for personal goals
+4. **Hype-Driven Development**: Choosing the newest/coolest tech
+5. **Not-Invented-Here**: Rejecting external solutions by default
+6. **Vendor Lock-in**: Over-dependence on proprietary solutions
+7. **Premature Optimization**: Solving problems you don't have yet
+8. **Under-documentation**: Not capturing the "why" behind decisions
+
+## Review Checklist
+
+Before finalizing an ADR, ensure:
+- [ ] Problem is clearly stated
+- [ ] All realistic options are considered
+- [ ] Trade-offs are honestly evaluated
+- [ ] Decision rationale is clear
+- [ ] Consequences are identified
+- [ ] Mitigation strategies are defined
+- [ ] Success metrics are established
+- [ ] Review date is set (if applicable)