@heyai-rules/pilo-masterkit 1.2.2 → 3.1.0

package/.agent/skills/manim-video/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: manim-video
+description: Build reusable Manim explainers for technical concepts, graphs, system diagrams, and product walkthroughs, then hand off to the wider ECC video stack if needed. Use when the user wants a clean animated explainer rather than a generic talking-head script.
+origin: ECC
+---
+
+# Manim Video
+
+Use Manim for technical explainers where motion, structure, and clarity matter more than photorealism.
+
+## When to Activate
+
+- the user wants a technical explainer animation
+- the concept is a graph, workflow, architecture, metric progression, or system diagram
+- the user wants a short product or launch explainer for X or a landing page
+- the visual should feel precise instead of generically cinematic
+
+## Tool Requirements
+
+- `manim` CLI for scene rendering
+- `ffmpeg` for post-processing if needed
+- `video-editing` for final assembly or polish
+- `remotion-video-creation` when the final package needs composited UI, captions, or additional motion layers
+
+## Default Output
+
+- short 16:9 MP4
+- one thumbnail or poster frame
+- storyboard plus scene plan
+
+## Workflow
+
+1. Define the core visual thesis in one sentence.
+2. Break the concept into 3 to 6 scenes.
+3. Decide what each scene proves.
+4. Write the scene outline before writing Manim code.
+5. Render the smallest working version first.
+6. Tighten typography, spacing, color, and pacing after the render works.
+7. Hand off to the wider video stack only if it adds value.
+
+## Scene Planning Rules
+
+- each scene should prove one thing
+- avoid overstuffed diagrams
+- prefer progressive reveal over full-screen clutter
+- use motion to explain state change, not just to keep the screen busy
+- title cards should be short and loaded with meaning
+
+## Network Graph Default
+
+For social-graph and network-optimization explainers:
+
+- show the current graph before showing the optimized graph
+- distinguish low-signal follow clutter from high-signal bridges
+- highlight warm-path nodes and target clusters
+- if useful, add a final scene showing the self-improvement lineage that informed the skill
+
+## Render Conventions
+
+- default to 16:9 landscape unless the user asks for vertical
+- start with a low-quality smoke test render
+- only push to higher quality after composition and timing are stable
+- export one clean thumbnail frame that reads at social size
+
+## Reusable Starter
+
+Use [assets/network_graph_scene.py](assets/network_graph_scene.py) as a starting point for network-graph explainers.
+
+Example smoke test:
+
+```bash
+manim -ql assets/network_graph_scene.py NetworkGraphExplainer
+```
+
+## Output Format
+
+Return:
+
+- core visual thesis
+- storyboard
+- scene outline
+- render plan
+- any follow-on polish recommendations
+
+## Related Skills
+
+- `video-editing` for final polish
+- `remotion-video-creation` for motion-heavy post-processing or compositing
+- `content-engine` when the animation is part of a broader launch

package/.agent/skills/manim-video/assets/network-graph-scene.py

@@ -0,0 +1,52 @@
+from manim import DOWN, LEFT, RIGHT, UP, Circle, Create, FadeIn, FadeOut, Scene, Text, VGroup, CurvedArrow
+
+
+class NetworkGraphExplainer(Scene):
+    def construct(self):
+        title = Text("Connections Optimizer", font_size=40).to_edge(UP)
+        subtitle = Text("Prune low-signal follows. Strengthen warm paths.", font_size=20).next_to(title, DOWN)
+
+        you = Circle(radius=0.45, color="#4F8EF7").shift(LEFT * 4 + DOWN * 0.5)
+        you_label = Text("You", font_size=22).move_to(you.get_center())
+
+        stale_a = Circle(radius=0.32, color="#7A7A7A").shift(LEFT * 1.6 + UP * 1.2)
+        stale_b = Circle(radius=0.32, color="#7A7A7A").shift(LEFT * 1.2 + DOWN * 1.4)
+        bridge = Circle(radius=0.38, color="#21A179").shift(RIGHT * 0.2 + UP * 0.2)
+        target = Circle(radius=0.42, color="#FF9F1C").shift(RIGHT * 3.2 + UP * 0.7)
+        new_target = Circle(radius=0.42, color="#FF9F1C").shift(RIGHT * 3.0 + DOWN * 1.4)
+
+        stale_a_label = Text("stale", font_size=18).move_to(stale_a.get_center())
+        stale_b_label = Text("noise", font_size=18).move_to(stale_b.get_center())
+        bridge_label = Text("bridge", font_size=18).move_to(bridge.get_center())
+        target_label = Text("target", font_size=18).move_to(target.get_center())
+        new_target_label = Text("add", font_size=18).move_to(new_target.get_center())
+
+        edge_stale_a = CurvedArrow(you.get_right(), stale_a.get_left(), angle=0.2, color="#7A7A7A")
+        edge_stale_b = CurvedArrow(you.get_right(), stale_b.get_left(), angle=-0.2, color="#7A7A7A")
+        edge_bridge = CurvedArrow(you.get_right(), bridge.get_left(), angle=0.0, color="#21A179")
+        edge_target = CurvedArrow(bridge.get_right(), target.get_left(), angle=0.1, color="#21A179")
+        edge_new_target = CurvedArrow(bridge.get_right(), new_target.get_left(), angle=-0.12, color="#21A179")
+
+        self.play(FadeIn(title), FadeIn(subtitle))
+        self.play(
+            Create(you),
+            FadeIn(you_label),
+            Create(stale_a),
+            Create(stale_b),
+            Create(bridge),
+            Create(target),
+            FadeIn(stale_a_label),
+            FadeIn(stale_b_label),
+            FadeIn(bridge_label),
+            FadeIn(target_label),
+        )
+        self.play(Create(edge_stale_a), Create(edge_stale_b), Create(edge_bridge), Create(edge_target))
+
+        optimize = Text("Optimize the graph", font_size=24).to_edge(DOWN)
+        self.play(FadeIn(optimize))
+        self.play(FadeOut(stale_a), FadeOut(stale_b), FadeOut(stale_a_label), FadeOut(stale_b_label), FadeOut(edge_stale_a), FadeOut(edge_stale_b))
+        self.play(Create(new_target), FadeIn(new_target_label), Create(edge_new_target))
+
+        final_group = VGroup(you, you_label, bridge, bridge_label, target, target_label, new_target, new_target_label)
+        self.play(final_group.animate.shift(UP * 0.1))
+        self.wait(1)

package/.agent/skills/market-research/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: market-research
+description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
+origin: ECC
+---
+
+# Market Research
+
+Produce research that supports decisions, not research theater.
+
+## When to Activate
+
+- researching a market, category, company, investor, or technology trend
+- building TAM/SAM/SOM estimates
+- comparing competitors or adjacent products
+- preparing investor dossiers before outreach
+- pressure-testing a thesis before building, funding, or entering a market
+
+## Research Standards
+
+1. Every important claim needs a source.
+2. Prefer recent data and call out stale data.
+3. Include contrarian evidence and downside cases.
+4. Translate findings into a decision, not just a summary.
+5. Separate fact, inference, and recommendation clearly.
+
+## Common Research Modes
+
+### Investor / Fund Diligence
+Collect:
+- fund size, stage, and typical check size
+- relevant portfolio companies
+- public thesis and recent activity
+- reasons the fund is or is not a fit
+- any obvious red flags or mismatches
+
+### Competitive Analysis
+Collect:
+- product reality, not marketing copy
+- funding and investor history if public
+- traction metrics if public
+- distribution and pricing clues
+- strengths, weaknesses, and positioning gaps
+
+### Market Sizing
+Use:
+- top-down estimates from reports or public datasets
+- bottom-up sanity checks from realistic customer acquisition assumptions
+- explicit assumptions for every leap in logic
+
+### Technology / Vendor Research
+Collect:
+- how it works
+- trade-offs and adoption signals
+- integration complexity
+- lock-in, security, compliance, and operational risk
+
+## Output Format
+
+Default structure:
+1. executive summary
+2. key findings
+3. implications
+4. risks and caveats
+5. recommendation
+6. sources
+
+## Quality Gate
+
+Before delivering:
+- all numbers are sourced or labeled as estimates
+- old data is flagged
+- the recommendation follows from the evidence
+- risks and counterarguments are included
+- the output makes a decision easier

package/.agent/skills/mcp-builder/SKILL.md

@@ -1,176 +1,236 @@
 ---
 name: mcp-builder
-description: MCP (Model Context Protocol) server building principles. Tool design, resource patterns, best practices.
-allowed-tools: Read, Write, Edit, Glob, Grep
+description: Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
+license: Complete terms in LICENSE.txt
 ---
 
-# MCP Builder
+# MCP Server Development Guide
 
-> Principles for building MCP servers.
+## Overview
+
+Create MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. The quality of an MCP server is measured by how well it enables LLMs to accomplish real-world tasks.
 
 ---
 
-## 1. MCP Overview
+# Process
 
-### What is MCP?
+## 🚀 High-Level Workflow
 
-Model Context Protocol - standard for connecting AI systems with external tools and data sources.
+Creating a high-quality MCP server involves four main phases:
 
-### Core Concepts
+### Phase 1: Deep Research and Planning
 
-| Concept | Purpose |
-|---------|---------|
-| **Tools** | Functions AI can call |
-| **Resources** | Data AI can read |
-| **Prompts** | Pre-defined prompt templates |
+#### 1.1 Understand Modern MCP Design
 
----
+**API Coverage vs. Workflow Tools:**
+Balance comprehensive API endpoint coverage with specialized workflow tools. Workflow tools can be more convenient for specific tasks, while comprehensive coverage gives agents flexibility to compose operations. Performance varies by client—some clients benefit from code execution that combines basic tools, while others work better with higher-level workflows. When uncertain, prioritize comprehensive API coverage.
 
-## 2. Server Architecture
+**Tool Naming and Discoverability:**
+Clear, descriptive tool names help agents find the right tools quickly. Use consistent prefixes (e.g., `github_create_issue`, `github_list_repos`) and action-oriented naming.
 
-### Project Structure
+**Context Management:**
+Agents benefit from concise tool descriptions and the ability to filter/paginate results. Design tools that return focused, relevant data. Some clients support code execution which can help agents filter and process data efficiently.
 
-```
-my-mcp-server/
-├── src/
-│   └── index.ts      # Main entry
-├── package.json
-└── tsconfig.json
-```
+**Actionable Error Messages:**
+Error messages should guide agents toward solutions with specific suggestions and next steps.
 
-### Transport Types
+#### 1.2 Study MCP Protocol Documentation
 
-| Type | Use |
-|------|-----|
-| **Stdio** | Local, CLI-based |
-| **SSE** | Web-based, streaming |
-| **WebSocket** | Real-time, bidirectional |
+**Navigate the MCP specification:**
 
----
+Start with the sitemap to find relevant pages: `https://modelcontextprotocol.io/sitemap.xml`
 
-## 3. Tool Design Principles
+Then fetch specific pages with `.md` suffix for markdown format (e.g., `https://modelcontextprotocol.io/specification/draft.md`).
 
-### Good Tool Design
+Key pages to review:
+- Specification overview and architecture
+- Transport mechanisms (streamable HTTP, stdio)
+- Tool, resource, and prompt definitions
 
-| Principle | Description |
-|-----------|-------------|
-| Clear name | Action-oriented (get_weather, create_user) |
-| Single purpose | One thing well |
-| Validated input | Schema with types and descriptions |
-| Structured output | Predictable response format |
+#### 1.3 Study Framework Documentation
 
-### Input Schema Design
+**Recommended stack:**
+- **Language**: TypeScript (high-quality SDK support and good compatibility in many execution environments e.g. MCPB. Plus AI models are good at generating TypeScript code, benefiting from its broad usage, static typing and good linting tools)
+- **Transport**: Streamable HTTP for remote servers, using stateless JSON (simpler to scale and maintain, as opposed to stateful sessions and streaming responses). stdio for local servers.
 
-| Field | Required? |
-|-------|-----------|
-| Type | Yes - object |
-| Properties | Define each param |
-| Required | List mandatory params |
-| Description | Human-readable |
+**Load framework documentation:**
 
----
+- **MCP Best Practices**: [📋 View Best Practices](./reference/mcp_best_practices.md) - Core guidelines
 
-## 4. Resource Patterns
+**For TypeScript (recommended):**
+- **TypeScript SDK**: Use WebFetch to load `https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.md`
+- [⚡ TypeScript Guide](./reference/node_mcp_server.md) - TypeScript patterns and examples
 
-### Resource Types
+**For Python:**
+- **Python SDK**: Use WebFetch to load `https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.md`
+- [🐍 Python Guide](./reference/python_mcp_server.md) - Python patterns and examples
 
-| Type | Use |
-|------|-----|
-| Static | Fixed data (config, docs) |
-| Dynamic | Generated on request |
-| Template | URI with parameters |
+#### 1.4 Plan Your Implementation
 
-### URI Patterns
+**Understand the API:**
+Review the service's API documentation to identify key endpoints, authentication requirements, and data models. Use web search and WebFetch as needed.
 
-| Pattern | Example |
-|---------|---------|
-| Fixed | `docs://readme` |
-| Parameterized | `users://{userId}` |
-| Collection | `files://project/*` |
+**Tool Selection:**
+Prioritize comprehensive API coverage. List endpoints to implement, starting with the most common operations.
 
 ---
 
-## 5. Error Handling
+### Phase 2: Implementation
 
-### Error Types
+#### 2.1 Set Up Project Structure
 
-| Situation | Response |
-|-----------|----------|
-| Invalid params | Validation error message |
-| Not found | Clear "not found" |
-| Server error | Generic error, log details |
+See language-specific guides for project setup:
+- [⚡ TypeScript Guide](./reference/node_mcp_server.md) - Project structure, package.json, tsconfig.json
+- [🐍 Python Guide](./reference/python_mcp_server.md) - Module organization, dependencies
 
-### Best Practices
+#### 2.2 Implement Core Infrastructure
 
-- Return structured errors
-- Don't expose internal details
-- Log for debugging
-- Provide actionable messages
+Create shared utilities:
+- API client with authentication
+- Error handling helpers
+- Response formatting (JSON/Markdown)
+- Pagination support
 
----
+#### 2.3 Implement Tools
+
+For each tool:
+
+**Input Schema:**
+- Use Zod (TypeScript) or Pydantic (Python)
+- Include constraints and clear descriptions
+- Add examples in field descriptions
 
-## 6. Multimodal Handling
+**Output Schema:**
+- Define `outputSchema` where possible for structured data
+- Use `structuredContent` in tool responses (TypeScript SDK feature)
+- Helps clients understand and process tool outputs
 
-### Supported Types
+**Tool Description:**
+- Concise summary of functionality
+- Parameter descriptions
+- Return type schema
 
-| Type | Encoding |
-|------|----------|
-| Text | Plain text |
-| Images | Base64 + MIME type |
-| Files | Base64 + MIME type |
+**Implementation:**
+- Async/await for I/O operations
+- Proper error handling with actionable messages
+- Support pagination where applicable
+- Return both text content and structured data when using modern SDKs
+
+**Annotations:**
+- `readOnlyHint`: true/false
+- `destructiveHint`: true/false
+- `idempotentHint`: true/false
+- `openWorldHint`: true/false
 
 ---
 
-## 7. Security Principles
+### Phase 3: Review and Test
+
+#### 3.1 Code Quality
+
+Review for:
+- No duplicated code (DRY principle)
+- Consistent error handling
+- Full type coverage
+- Clear tool descriptions
 
-### Input Validation
+#### 3.2 Build and Test
 
-- Validate all tool inputs
-- Sanitize user-provided data
-- Limit resource access
+**TypeScript:**
+- Run `npm run build` to verify compilation
+- Test with MCP Inspector: `npx @modelcontextprotocol/inspector`
 
-### API Keys
+**Python:**
+- Verify syntax: `python -m py_compile your_server.py`
+- Test with MCP Inspector
 
-- Use environment variables
-- Don't log secrets
-- Validate permissions
+See language-specific guides for detailed testing approaches and quality checklists.
 
 ---
 
-## 8. Configuration
+### Phase 4: Create Evaluations
 
-### Claude Desktop Config
+After implementing your MCP server, create comprehensive evaluations to test its effectiveness.
 
-| Field | Purpose |
-|-------|---------|
-| command | Executable to run |
-| args | Command arguments |
-| env | Environment variables |
+**Load [✅ Evaluation Guide](./reference/evaluation.md) for complete evaluation guidelines.**
 
----
+#### 4.1 Understand Evaluation Purpose
 
-## 9. Testing
+Use evaluations to test whether LLMs can effectively use your MCP server to answer realistic, complex questions.
 
-### Test Categories
+#### 4.2 Create 10 Evaluation Questions
 
-| Type | Focus |
-|------|-------|
-| Unit | Tool logic |
-| Integration | Full server |
-| Contract | Schema validation |
+To create effective evaluations, follow the process outlined in the evaluation guide:
 
----
+1. **Tool Inspection**: List available tools and understand their capabilities
+2. **Content Exploration**: Use READ-ONLY operations to explore available data
+3. **Question Generation**: Create 10 complex, realistic questions
+4. **Answer Verification**: Solve each question yourself to verify answers
 
-## 10. Best Practices Checklist
+#### 4.3 Evaluation Requirements
 
-- [ ] Clear, action-oriented tool names
-- [ ] Complete input schemas with descriptions
-- [ ] Structured JSON output
-- [ ] Error handling for all cases
-- [ ] Input validation
-- [ ] Environment-based configuration
-- [ ] Logging for debugging
+Ensure each question is:
+- **Independent**: Not dependent on other questions
+- **Read-only**: Only non-destructive operations required
+- **Complex**: Requiring multiple tool calls and deep exploration
+- **Realistic**: Based on real use cases humans would care about
+- **Verifiable**: Single, clear answer that can be verified by string comparison
+- **Stable**: Answer won't change over time
+
+#### 4.4 Output Format
+
+Create an XML file with this structure:
+
+```xml
+<evaluation>
+  <qa_pair>
+    <question>Find discussions about AI model launches with animal codenames. One model needed a specific safety designation that uses the format ASL-X. What number X was being determined for the model named after a spotted wild cat?</question>
+    <answer>3</answer>
+  </qa_pair>
+<!-- More qa_pairs... -->
+</evaluation>
+```
 
 ---
 
-> **Remember:** MCP tools should be simple, focused, and well-documented. The AI relies on descriptions to use them correctly.
+# Reference Files
+
+## 📚 Documentation Library
+
+Load these resources as needed during development:
+
+### Core MCP Documentation (Load First)
+- **MCP Protocol**: Start with sitemap at `https://modelcontextprotocol.io/sitemap.xml`, then fetch specific pages with `.md` suffix
+- [📋 MCP Best Practices](./reference/mcp_best_practices.md) - Universal MCP guidelines including:
+  - Server and tool naming conventions
+  - Response format guidelines (JSON vs Markdown)
+  - Pagination best practices
+  - Transport selection (streamable HTTP vs stdio)
+  - Security and error handling standards
+
+### SDK Documentation (Load During Phase 1/2)
+- **Python SDK**: Fetch from `https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.md`
+- **TypeScript SDK**: Fetch from `https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.md`
+
+### Language-Specific Implementation Guides (Load During Phase 2)
+- [🐍 Python Implementation Guide](./reference/python_mcp_server.md) - Complete Python/FastMCP guide with:
+  - Server initialization patterns
+  - Pydantic model examples
+  - Tool registration with `@mcp.tool`
+  - Complete working examples
+  - Quality checklist
+
+- [⚡ TypeScript Implementation Guide](./reference/node_mcp_server.md) - Complete TypeScript guide with:
+  - Project structure
+  - Zod schema patterns
+  - Tool registration with `server.registerTool`
+  - Complete working examples
+  - Quality checklist
+
+### Evaluation Guide (Load During Phase 4)
+- [✅ Evaluation Guide](./reference/evaluation.md) - Complete evaluation creation guide with:
+  - Question creation guidelines
+  - Answer verification strategies
+  - XML format specifications
+  - Example questions and answers
+  - Running an evaluation with the provided scripts