agcel 1.0.1

package/skills/prompt-engineer/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: prompt-engineer
+description: "Transforms user prompts into optimized prompts using frameworks (RTF, RISEN, Chain of Thought, RODES, Chain of Density, RACE, RISE, STAR, SOAP, CLEAR, GROW)"
+version: 1.1.0
+author: Eric Andrade
+created: 2025-02-01
+updated: 2026-02-04
+platforms: [github-copilot-cli, claude-code, codex]
+category: automation
+tags: [prompt-engineering, optimization, frameworks, ai-enhancement]
+risk: safe
+---
+
+## Purpose
+
+This skill transforms raw, unstructured user prompts into highly optimized prompts using established prompting frameworks. It analyzes user intent, identifies task complexity, and intelligently selects the most appropriate framework(s) to maximize Claude/ChatGPT output quality.
+
+The skill operates in "magic mode" - it works silently behind the scenes, only interacting with users when clarification is critically needed. Users receive polished, ready-to-use prompts without technical explanations or framework jargon.
+
+This is a **universal skill** that works in any terminal context, not limited to Obsidian vaults or specific project structures.
+
+## When to Use
+
+Invoke this skill when:
+
+- User provides a vague or generic prompt (e.g., "help me code Python")
+- User has a complex idea but struggles to articulate it clearly
+- User's prompt lacks structure, context, or specific requirements
+- Task requires step-by-step reasoning (debugging, analysis, design)
+- User needs a prompt for a specific AI task but doesn't know prompting frameworks
+- User wants to improve an existing prompt's effectiveness
+- User asks variations of "how do I ask AI to..." or "create a prompt for..."
+
+## Workflow
+
+### Step 1: Analyze Intent
+
+**Objective:** Understand what the user truly wants to accomplish.
+
+**Actions:**
+1. Read the raw prompt provided by the user
+2. Detect task characteristics:
+   - **Type:** coding, writing, analysis, design, learning, planning, decision-making, creative, etc.
+   - **Complexity:** simple (one-step), moderate (multi-step), complex (requires reasoning/design)
+   - **Clarity:** clear intention vs. ambiguous/vague
+   - **Domain:** technical, business, creative, academic, personal, etc.
+3. Identify implicit requirements:
+   - Does user need examples?
+   - Is output format specified?
+   - Are there constraints (time, resources, scope)?
+   - Is this exploratory or execution-focused?
+
+**Detection Patterns:**
+- **Simple tasks:** Short prompts (<50 chars), single verb, no context
+- **Complex tasks:** Long prompts (>200 chars), multiple requirements, conditional logic
+- **Ambiguous tasks:** Generic verbs ("help", "improve"), missing object/context
+- **Structured tasks:** Mentions steps, phases, deliverables, stakeholders
+
+
+### Step 3: Select Framework(s)
+
+**Objective:** Map task characteristics to optimal prompting framework(s).
+
+**Framework Mapping Logic:**
+
+| Task Type | Recommended Framework(s) | Rationale |
+|-----------|-------------------------|-----------|
+| **Role-based tasks** (act as expert, consultant) | **RTF** (Role-Task-Format) | Clear role definition + task + output format |
+| **Step-by-step reasoning** (debugging, proof, logic) | **Chain of Thought** | Encourages explicit reasoning steps |
+| **Structured projects** (multi-phase, deliverables) | **RISEN** (Role, Instructions, Steps, End goal, Narrowing) | Comprehensive structure for complex work |
+| **Complex design/analysis** (systems, architecture) | **RODES** (Role, Objective, Details, Examples, Sense check) | Balances detail with validation |
+| **Summarization** (compress, synthesize) | **Chain of Density** | Iterative refinement to essential info |
+| **Communication** (reports, presentations, storytelling) | **RACE** (Role, Audience, Context, Expectation) | Audience-aware messaging |
+| **Investigation/analysis** (research, diagnosis) | **RISE** (Research, Investigate, Synthesize, Evaluate) | Systematic analytical approach |
+| **Contextual situations** (problem-solving with background) | **STAR** (Situation, Task, Action, Result) | Context-rich problem framing |
+| **Documentation** (medical, technical, records) | **SOAP** (Subjective, Objective, Assessment, Plan) | Structured information capture |
+| **Goal-setting** (OKRs, objectives, targets) | **CLEAR** (Collaborative, Limited, Emotional, Appreciable, Refinable) | Goal clarity and actionability |
+| **Coaching/development** (mentoring, growth) | **GROW** (Goal, Reality, Options, Will) | Developmental conversation structure |
+
+**Blending Strategy:**
+- **Combine 2-3 frameworks** when task spans multiple types
+- Example: Complex technical project → **RODES + Chain of Thought** (structure + reasoning)
+- Example: Leadership decision → **CLEAR + GROW** (goal clarity + development)
+
+**Selection Criteria:**
+- Primary framework = best match to core task type
+- Secondary framework(s) = address additional complexity dimensions
+- Avoid over-engineering: simple tasks get simple frameworks
+
+**Critical Rule:** This selection happens **silently** - do not explain framework choice to user.
+
+Role: You are a senior software architect. [RTF - Role]
+
+Objective: Design a microservices architecture for [system]. [RODES - Objective]
+
+Approach this step-by-step: [Chain of Thought]
+1. Analyze current monolithic constraints
+2. Identify service boundaries
+3. Design inter-service communication
+4. Plan data consistency strategy
+
+Details: [RODES - Details]
+- Expected traffic: [X]
+- Data volume: [Y]
+- Team size: [Z]
+
+Output Format: [RTF - Format]
+Provide architecture diagram description, service definitions, and migration roadmap.
+
+Sense Check: [RODES - Sense check]
+Validate that services are loosely coupled, independently deployable, and aligned with business domains.
+```
+
+**4.5. Language Adaptation**
+- If original prompt is in Portuguese, generate prompt in Portuguese
+- If original prompt is in English, generate prompt in English
+- If mixed, default to English (more universal for AI models)
+
+**4.6. Quality Checks**
+Before finalizing, verify:
+- [ ] Prompt is self-contained (no external context needed)
+- [ ] Task is specific and measurable
+- [ ] Output format is clear
+- [ ] No ambiguous language
+- [ ] Appropriate level of detail for task complexity
+
+
+## Critical Rules
+
+### **NEVER:**
+
+- ❌ Assume information that wasn't provided - ALWAYS ask if critical details are missing
+- ❌ Explain which framework was selected or why (magic mode - keep it invisible)
+- ❌ Generate generic, one-size-fits-all prompts - always customize to context
+- ❌ Use technical jargon in the final prompt (unless user's domain is technical)
+- ❌ Ask more than 3 clarifying questions (avoid user fatigue)
+- ❌ Include meta-commentary in the output ("This prompt uses...", "Note that...")
+- ❌ Present output without code block formatting
+- ❌ Mix languages inconsistently (if user writes in PT, respond in PT)
+
+### **ALWAYS:**
+
+- ✅ Analyze intent before generating (Step 1 is mandatory)
+- ✅ Ask clarifying questions if critical information is ambiguous (Step 2 conditional)
+- ✅ Select framework(s) based on task type and complexity (Step 3 mapping)
+- ✅ Blend multiple frameworks when it improves prompt quality
+- ✅ Adapt prompt length to original input complexity (simple → short, complex → detailed)
+- ✅ Include output format specification in generated prompts
+- ✅ Present final prompt in clean Markdown code block
+- ✅ Make prompts self-contained (no dependency on external context)
+- ✅ Use examples in complex prompts to illustrate expected output
+- ✅ Validate prompt completeness before presenting (quality checks in Step 4.6)
+
+
+### **Example 2: Complex Clear Prompt → RODES + Chain of Thought (No Clarification)**
+
+**User Input:**
+```
+copilot> create prompt for: I need to build a product recommendation system considering purchase history, user preferences, and market trends
+```
+
+**Skill Internal Process:**
+1. **Analyze:** Clear intent, complex task (ML system design), technical domain
+2. **Clarify:** Skip (sufficient information)
+3. **Select:** RODES (complex design) + Chain of Thought (reasoning needed)
+
+**Skill Output:**
+
+````markdown
+```
+Role: You are a senior machine learning engineer specializing in recommendation systems.
+
+Objective: Design a product recommendation system that combines user purchase history, preferences, and market trends.
+
+Details:
+- Input data sources: user transaction logs, preference surveys, market trend APIs
+- Algorithm considerations: collaborative filtering, content-based filtering, hybrid approaches
+- Performance metrics: precision, recall, diversity, novelty
+- Scalability: system must handle 100k+ users
+- Real-time constraints: recommendations updated within 500ms
+
+Approach step-by-step:
+1. Analyze the three data sources and their relationships
+2. Propose 2-3 algorithm approaches with trade-offs analysis
+3. Design data pipeline architecture (ingestion, processing, serving)
+4. Define evaluation metrics and A/B testing strategy
+5. Outline implementation roadmap with phases
+
+Examples:
+- Show pseudocode for core recommendation logic
+- Illustrate data flow diagram
+- Provide sample API response structure
+
+Sense Check: Validate that the proposed solution balances personalization with discovery, scales to production load, and incorporates real-time market trends effectively.
+
+Output format: Technical design document with architecture diagrams, algorithm justification, and implementation roadmap.
+```
+````
+
+
+### **Example 4: Code Debugging → Chain of Thought**
+
+**User Input:**
+```
+copilot> optimize prompt: my Python code isn't working, needs debugging
+```
+
+**Skill Internal Process:**
+1. **Analyze:** Debugging task, needs step-by-step reasoning
+2. **Clarify:** Skip (user will provide code context later)
+3. **Select:** Chain of Thought
+
+**Skill Output:**
+
+````markdown
+```
+You are an expert Python debugger.
+
+Task: Debug the Python code provided by the user by analyzing it step-by-step.
+
+Debugging approach:
+1. Read and understand the code's intended purpose
+2. Identify the error or unexpected behavior
+3. Trace variable states at each execution step
+4. Locate the root cause of the issue
+5. Propose fix with explanation
+6. Suggest preventive measures to avoid similar bugs
+
+For each step, show your reasoning:
+- What you're checking
+- What you found
+- Why it matters
+
+Output format:
+- **Issue identified:** [Describe the bug]
+- **Root cause:** [Why it's happening]
+- **Fix:** [Corrected code with comments]
+- **Prevention:** [Best practices to avoid this in the future]
+
+Include a working example to verify the fix.
+```
+````
+
+
+## Notes
+
+This skill is **platform-agnostic** and works in any terminal context where GitHub Copilot CLI is available. It does not depend on:
+- Obsidian vault structure
+- Specific project configurations
+- External files or templates
+
+The skill is entirely self-contained, operating purely on user input and framework knowledge.
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.

package/skills/python-patterns/SKILL.md

@@ -0,0 +1,445 @@
+---
+name: python-patterns
+description: Python development principles and decision-making. Framework selection, async patterns, type hints, project structure. Teaches thinking, not copying.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# Python Patterns
+
+> Python development principles and decision-making for 2025.
+> **Learn to THINK, not memorize patterns.**
+
+---
+
+## ⚠️ How to Use This Skill
+
+This skill teaches **decision-making principles**, not fixed code to copy.
+
+- ASK user for framework preference when unclear
+- Choose async vs sync based on CONTEXT
+- Don't default to same framework every time
+
+---
+
+## 1. Framework Selection (2025)
+
+### Decision Tree
+
+```
+What are you building?
+│
+├── API-first / Microservices
+│   └── FastAPI (async, modern, fast)
+│
+├── Full-stack web / CMS / Admin
+│   └── Django (batteries-included)
+│
+├── Simple / Script / Learning
+│   └── Flask (minimal, flexible)
+│
+├── AI/ML API serving
+│   └── FastAPI (Pydantic, async, uvicorn)
+│
+└── Background workers
+    └── Celery + any framework
+```
+
+### Comparison Principles
+
+| Factor | FastAPI | Django | Flask |
+|--------|---------|--------|-------|
+| **Best for** | APIs, microservices | Full-stack, CMS | Simple, learning |
+| **Async** | Native | Django 5.0+ | Via extensions |
+| **Admin** | Manual | Built-in | Via extensions |
+| **ORM** | Choose your own | Django ORM | Choose your own |
+| **Learning curve** | Low | Medium | Low |
+
+### Selection Questions to Ask:
+1. Is this API-only or full-stack?
+2. Need admin interface?
+3. Team familiar with async?
+4. Existing infrastructure?
+
+---
+
+## 2. Async vs Sync Decision
+
+### When to Use Async
+
+```
+async def is better when:
+├── I/O-bound operations (database, HTTP, file)
+├── Many concurrent connections
+├── Real-time features
+├── Microservices communication
+└── FastAPI/Starlette/Django ASGI
+
+def (sync) is better when:
+├── CPU-bound operations
+├── Simple scripts
+├── Legacy codebase
+├── Team unfamiliar with async
+└── Blocking libraries (no async version)
+```
+
+### The Golden Rule
+
+```
+I/O-bound → async (waiting for external)
+CPU-bound → sync + multiprocessing (computing)
+
+Don't:
+├── Mix sync and async carelessly
+├── Use sync libraries in async code
+└── Force async for CPU work
+```
+
+### Async Library Selection
+
+| Need | Async Library |
+|------|---------------|
+| HTTP client | httpx |
+| PostgreSQL | asyncpg |
+| Redis | aioredis / redis-py async |
+| File I/O | aiofiles |
+| Database ORM | SQLAlchemy 2.0 async, Tortoise |
+
+---
+
+## 3. Type Hints Strategy
+
+### When to Type
+
+```
+Always type:
+├── Function parameters
+├── Return types
+├── Class attributes
+├── Public APIs
+
+Can skip:
+├── Local variables (let inference work)
+├── One-off scripts
+├── Tests (usually)
+```
+
+### Common Type Patterns
+
+```python
+# These are patterns, understand them:
+
+# Optional → might be None
+from typing import Optional
+def find_user(id: int) -> Optional[User]: ...
+
+# Union → one of multiple types
+def process(data: str | dict) -> None: ...
+
+# Generic collections
+def get_items() -> list[Item]: ...
+def get_mapping() -> dict[str, int]: ...
+
+# Callable
+from typing import Callable
+def apply(fn: Callable[[int], str]) -> str: ...
+```
+
+### Pydantic for Validation
+
+```
+When to use Pydantic:
+├── API request/response models
+├── Configuration/settings
+├── Data validation
+├── Serialization
+
+Benefits:
+├── Runtime validation
+├── Auto-generated JSON schema
+├── Works with FastAPI natively
+└── Clear error messages
+```
+
+---
+
+## 4. Project Structure Principles
+
+### Structure Selection
+
+```
+Small project / Script:
+├── main.py
+├── utils.py
+└── requirements.txt
+
+Medium API:
+├── app/
+│   ├── __init__.py
+│   ├── main.py
+│   ├── models/
+│   ├── routes/
+│   ├── services/
+│   └── schemas/
+├── tests/
+└── pyproject.toml
+
+Large application:
+├── src/
+│   └── myapp/
+│       ├── core/
+│       ├── api/
+│       ├── services/
+│       ├── models/
+│       └── ...
+├── tests/
+└── pyproject.toml
+```
+
+### FastAPI Structure Principles
+
+```
+Organize by feature or layer:
+
+By layer:
+├── routes/ (API endpoints)
+├── services/ (business logic)
+├── models/ (database models)
+├── schemas/ (Pydantic models)
+└── dependencies/ (shared deps)
+
+By feature:
+├── users/
+│   ├── routes.py
+│   ├── service.py
+│   └── schemas.py
+└── products/
+    └── ...
+```
+
+---
+
+## 5. Django Principles (2025)
+
+### Django Async (Django 5.0+)
+
+```
+Django supports async:
+├── Async views
+├── Async middleware
+├── Async ORM (limited)
+└── ASGI deployment
+
+When to use async in Django:
+├── External API calls
+├── WebSocket (Channels)
+├── High-concurrency views
+└── Background task triggering
+```
+
+### Django Best Practices
+
+```
+Model design:
+├── Fat models, thin views
+├── Use managers for common queries
+├── Abstract base classes for shared fields
+
+Views:
+├── Class-based for complex CRUD
+├── Function-based for simple endpoints
+├── Use viewsets with DRF
+
+Queries:
+├── select_related() for FKs
+├── prefetch_related() for M2M
+├── Avoid N+1 queries
+└── Use .only() for specific fields
+```
+
+---
+
+## 6. FastAPI Principles
+
+### async def vs def in FastAPI
+
+```
+Use async def when:
+├── Using async database drivers
+├── Making async HTTP calls
+├── I/O-bound operations
+└── Want to handle concurrency
+
+Use def when:
+├── Blocking operations
+├── Sync database drivers
+├── CPU-bound work
+└── FastAPI runs in threadpool automatically
+```
+
+### Dependency Injection
+
+```
+Use dependencies for:
+├── Database sessions
+├── Current user / Auth
+├── Configuration
+├── Shared resources
+
+Benefits:
+├── Testability (mock dependencies)
+├── Clean separation
+├── Automatic cleanup (yield)
+```
+
+### Pydantic v2 Integration
+
+```python
+# FastAPI + Pydantic are tightly integrated:
+
+# Request validation
+@app.post("/users")
+async def create(user: UserCreate) -> UserResponse:
+    # user is already validated
+    ...
+
+# Response serialization
+# Return type becomes response schema
+```
+
+---
+
+## 7. Background Tasks
+
+### Selection Guide
+
+| Solution | Best For |
+|----------|----------|
+| **BackgroundTasks** | Simple, in-process tasks |
+| **Celery** | Distributed, complex workflows |
+| **ARQ** | Async, Redis-based |
+| **RQ** | Simple Redis queue |
+| **Dramatiq** | Actor-based, simpler than Celery |
+
+### When to Use Each
+
+```
+FastAPI BackgroundTasks:
+├── Quick operations
+├── No persistence needed
+├── Fire-and-forget
+└── Same process
+
+Celery/ARQ:
+├── Long-running tasks
+├── Need retry logic
+├── Distributed workers
+├── Persistent queue
+└── Complex workflows
+```
+
+---
+
+## 8. Error Handling Principles
+
+### Exception Strategy
+
+```
+In FastAPI:
+├── Create custom exception classes
+├── Register exception handlers
+├── Return consistent error format
+└── Log without exposing internals
+
+Pattern:
+├── Raise domain exceptions in services
+├── Catch and transform in handlers
+└── Client gets clean error response
+```
+
+### Error Response Philosophy
+
+```
+Include:
+├── Error code (programmatic)
+├── Message (human readable)
+├── Details (field-level when applicable)
+└── NOT stack traces (security)
+```
+
+---
+
+## 9. Testing Principles
+
+### Testing Strategy
+
+| Type | Purpose | Tools |
+|------|---------|-------|
+| **Unit** | Business logic | pytest |
+| **Integration** | API endpoints | pytest + httpx/TestClient |
+| **E2E** | Full workflows | pytest + DB |
+
+### Async Testing
+
+```python
+# Use pytest-asyncio for async tests
+
+import pytest
+from httpx import AsyncClient
+
+@pytest.mark.asyncio
+async def test_endpoint():
+    async with AsyncClient(app=app, base_url="http://test") as client:
+        response = await client.get("/users")
+        assert response.status_code == 200
+```
+
+### Fixtures Strategy
+
+```
+Common fixtures:
+├── db_session → Database connection
+├── client → Test client
+├── authenticated_user → User with token
+└── sample_data → Test data setup
+```
+
+---
+
+## 10. Decision Checklist
+
+Before implementing:
+
+- [ ] **Asked user about framework preference?**
+- [ ] **Chosen framework for THIS context?** (not just default)
+- [ ] **Decided async vs sync?**
+- [ ] **Planned type hint strategy?**
+- [ ] **Defined project structure?**
+- [ ] **Planned error handling?**
+- [ ] **Considered background tasks?**
+
+---
+
+## 11. Anti-Patterns to Avoid
+
+### ❌ DON'T:
+- Default to Django for simple APIs (FastAPI may be better)
+- Use sync libraries in async code
+- Skip type hints for public APIs
+- Put business logic in routes/views
+- Ignore N+1 queries
+- Mix async and sync carelessly
+
+### ✅ DO:
+- Choose framework based on context
+- Ask about async requirements
+- Use Pydantic for validation
+- Separate concerns (routes → services → repos)
+- Test critical paths
+
+---
+
+> **Remember**: Python patterns are about decision-making for YOUR specific context. Don't copy code—think about what serves your application best.
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.