@hybridlabor-api/bdb-antigravity-skills 1.0.0

package/skills/global_legacy/llm-prompt-optimizer/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: llm-prompt-optimizer
+description: "Use when improving prompts for any LLM. Applies proven prompt engineering techniques to boost output quality, reduce hallucinations, and cut token usage."
+risk: safe
+source: community
+date_added: "2026-03-04"
+---
+
+# LLM Prompt Optimizer
+
+## Overview
+
+This skill transforms weak, vague, or inconsistent prompts into precision-engineered instructions that reliably produce high-quality outputs from any LLM (Claude, Gemini, GPT-4, Llama, etc.). It applies systematic prompt engineering frameworks — from zero-shot to few-shot, chain-of-thought, and structured output patterns.
+
+## When to Use This Skill
+
+- Use when a prompt returns inconsistent, vague, or hallucinated results
+- Use when you need structured/JSON output from an LLM reliably
+- Use when designing system prompts for AI agents or chatbots
+- Use when you want to reduce token usage without sacrificing quality
+- Use when implementing chain-of-thought reasoning for complex tasks
+- Use when prompts work on one model but fail on another
+
+## Step-by-Step Guide
+
+### 1. Diagnose the Weak Prompt
+
+Before optimizing, identify which problem pattern applies:
+
+| Problem | Symptom | Fix |
+|---------|---------|-----|
+| Too vague | Generic, unhelpful answers | Add role + context + constraints |
+| No structure | Unformatted, hard-to-parse output | Specify output format explicitly |
+| Hallucination | Confident wrong answers | Add "say I don't know if unsure" |
+| Inconsistent | Different answers each run | Add few-shot examples |
+| Too long | Verbose, padded responses | Add length constraints |
+
+### 2. Apply the RSCIT Framework
+
+Every optimized prompt should have:
+
+- **R** — **Role**: Who is the AI in this interaction?
+- **S** — **Situation**: What context does it need?
+- **C** — **Constraints**: What are the rules and limits?
+- **I** — **Instructions**: What exactly should it do?
+- **T** — **Template**: What should the output look like?
+
+**Before (weak prompt):**
+```
+Explain machine learning.
+```
+
+**After (optimized prompt):**
+```
+You are a senior ML engineer explaining concepts to a junior developer.
+
+Context: The developer has 1 year of Python experience but no ML background.
+
+Task: Explain supervised machine learning in simple terms.
+
+Constraints:
+- Use an analogy from everyday life
+- Maximum 200 words
+- No mathematical formulas
+- End with one actionable next step
+
+Format: Plain prose, no bullet points.
+```
+
+### 3. Chain-of-Thought (CoT) Pattern
+
+For reasoning tasks, instruct the model to think step-by-step:
+
+```
+Solve this problem step by step, showing your work at each stage.
+Only provide the final answer after completing all reasoning steps.
+
+Problem: [your problem here]
+
+Thinking process:
+Step 1: [identify what's given]
+Step 2: [identify what's needed]
+Step 3: [apply logic or formula]
+Step 4: [verify the answer]
+
+Final Answer:
+```
+
+### 4. Few-Shot Examples Pattern
+
+Provide 2-3 examples to establish the pattern:
+
+```
+Classify the sentiment of customer reviews as POSITIVE, NEGATIVE, or NEUTRAL.
+
+Examples:
+Review: "This product exceeded my expectations!" -> POSITIVE
+Review: "It arrived broken and support was useless." -> NEGATIVE  
+Review: "Product works as described, nothing special." -> NEUTRAL
+
+Now classify:
+Review: "[your review here]" ->
+```
+
+### 5. Structured JSON Output Pattern
+
+```
+Extract the following information from the text below and return it as valid JSON only.
+Do not include any explanation or markdown — just the raw JSON object.
+
+Schema:
+{
+  "name": string,
+  "email": string | null,
+  "company": string | null,
+  "role": string | null
+}
+
+Text: [input text here]
+```
+
+### 6. Reduce Hallucination Pattern
+
+```
+Answer the following question based ONLY on the provided context.
+If the answer is not contained in the context, respond with exactly: "I don't have enough information to answer this."
+Do not make up or infer information not present in the context.
+
+Context:
+[your context here]
+
+Question: [your question here]
+```
+
+### 7. Prompt Compression Techniques
+
+Reduce token count without losing effectiveness:
+
+```
+# Verbose (expensive)
+"Please carefully analyze the following code and provide a detailed explanation of 
+what it does, how it works, and any potential issues you might find."
+
+# Compressed (efficient, same quality)
+"Analyze this code: explain what it does, how it works, and flag any issues."
+```
+
+## Best Practices
+
+- ✅ **Do:** Always specify the output format (JSON, markdown, plain text, bullet list)
+- ✅ **Do:** Use delimiters (```, ---) to separate instructions from content
+- ✅ **Do:** Test prompts with edge cases (empty input, unusual data)
+- ✅ **Do:** Version your system prompts in source control
+- ✅ **Do:** Add "think step by step" for math, logic, or multi-step tasks
+- ❌ **Don't:** Use negative-only instructions ("don't be verbose") — add positive alternatives
+- ❌ **Don't:** Assume the model knows your codebase context — always include it
+- ❌ **Don't:** Use the same prompt across different models without testing — they behave differently
+
+## Prompt Audit Checklist
+
+Before using a prompt in production:
+
+- [ ] Does it have a clear role/persona?
+- [ ] Is the output format explicitly defined?
+- [ ] Are edge cases handled (empty input, ambiguous data)?
+- [ ] Is the length appropriate (not too long/short)?
+- [ ] Has it been tested on 5+ varied inputs?
+- [ ] Is hallucination risk addressed for factual tasks?
+
+## Troubleshooting
+
+**Problem:** Model ignores format instructions
+**Solution:** Move format instructions to the END of the prompt, after examples. Use strong language: "You MUST return only valid JSON."
+
+**Problem:** Inconsistent results between runs
+**Solution:** Lower the temperature setting (0.0-0.3 for factual tasks). Add more few-shot examples.
+
+**Problem:** Prompt works in playground but fails in production
+**Solution:** Check if system prompt is being sent correctly. Verify token limits aren't being exceeded (use a token counter).
+
+**Problem:** Output is too long
+**Solution:** Add explicit word/sentence limits: "Respond in exactly 3 bullet points, each under 20 words."
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/global_legacy/llm-structured-output/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: llm-structured-output
+description: >
+  Get reliable JSON, enums, and typed objects from LLMs using response_format, tool_use, and schema-constrained decoding across OpenAI, Anthropic, and Google APIs.
+risk: safe
+source: community
+date_added: "2026-03-12"
+---
+
+# LLM Structured Output
+
+## What This Skill Does
+
+Extract typed, validated data from LLM API responses instead of parsing free-text. This skill covers the three main approaches: OpenAI's `response_format` with JSON Schema, Anthropic's `tool_use` block for structured extraction, and Google's `responseSchema` in Gemini. You will learn when each approach works, when it breaks, and how to build retry logic around schema validation failures that every production system encounters.
+
+## When to Use This Skill
+
+- The user needs to extract structured data (JSON objects, arrays, enums) from an LLM response
+- The user is building a pipeline where LLM output feeds directly into code (database writes, API calls, UI rendering)
+- The user asks about `response_format`, `json_mode`, `json_object`, or `json_schema` in OpenAI
+- The user asks about using Anthropic's `tool_use` or `tool_result` blocks for data extraction (not for actual tool execution)
+- The user asks about Zod schemas with `zodResponseFormat()` from the `openai` npm package
+- The user needs to parse LLM output into Pydantic models using `instructor`, `marvin`, or manual validation
+- The user is getting malformed JSON, missing fields, or wrong types from LLM responses and needs a fix
+- The user asks about `controlled generation`, `constrained decoding`, or `grammar-based sampling` in local models
+
+Do NOT use this skill when:
+- The user wants free-form text generation (summaries, essays, chat)
+- The user is asking about Zod for form validation or API input validation (use `zod-validation-expert` instead)
+- The user needs prompt engineering for better text quality (not structure)
+- The user wants to call real external tools/APIs (this skill covers using tool_use as a structured output hack, not actual tool orchestration)
+
+## Core Workflow
+
+1. Identify the target schema. Ask the user what fields they need extracted. Define every field with its type, whether it's required or optional, and valid enum values if applicable. Do not proceed without a concrete schema.
+
+2. Choose the provider-appropriate method:
+   - **OpenAI (gpt-4o, gpt-4o-mini):** Use `response_format: { type: "json_schema", json_schema: { ... } }`. This enables Structured Outputs with guaranteed schema conformance via constrained decoding.
+   - **Anthropic (Claude):** Define a single tool with the target schema as `input_schema` and set `tool_choice: { type: "tool", name: "extract_data" }`. Claude returns the structured data in the `tool_use` content block.
+   - **Google (Gemini):** Use `generationConfig.responseSchema` with a JSON Schema object and set `responseMimeType: "application/json"`.
+   - **Local models (llama.cpp, vLLM):** Use GBNF grammars or `--json-schema` flag for constrained decoding at the token level.
+
+3. Write the schema definition in the user's language. For Python, define a Pydantic `BaseModel`. For TypeScript, define a Zod schema and convert it with `zodResponseFormat()`. For raw API calls, write JSON Schema directly.
+
+4. Include field-level descriptions in the schema. Every field should have a `description` string that tells the model what to put there. Models use these descriptions as implicit prompt instructions — a field described as `"The user's sentiment as positive, negative, or neutral"` produces better results than a bare `sentiment: str` with no context.
+
+5. Set the system prompt to reinforce structure. Tell the model its job is data extraction, not conversation. Example: `"You are a data extraction system. Analyze the input and return the requested fields. Do not include explanations outside the JSON structure."`
+
+6. If using OpenAI's `json_schema` mode, set `"strict": true` in the schema definition. This activates constrained decoding where the model can only output tokens that conform to the schema. Without `strict: true`, the model may still produce invalid JSON.
+
+7. If using Anthropic's tool_use approach, extract the structured data from `response.content` by finding the block where `type == "tool_use"` and reading its `input` field. Do not parse the text blocks — the structured data lives exclusively in the tool_use block.
+
+8. Validate the response against the schema in your application code. Even with constrained decoding, validate with Pydantic's `model_validate()` or Zod's `.parse()` before passing data downstream. This catches semantic issues (empty strings, out-of-range numbers) that schema conformance alone cannot prevent.
+
+9. Build a retry loop for validation failures. When validation fails, send the original input plus the failed output and the validation error back to the model with an instruction like `"Your previous output failed validation: {error}. Fix the output."` Cap retries at 3 attempts.
+
+10. Log every structured output call with: the input, the raw response, the parsed result, and any validation errors. When structured output breaks in production, you need these logs to determine whether the failure was a schema design issue, a prompt issue, or a model regression.
+
+## Examples
+
+### Example 1: OpenAI Structured Outputs with Pydantic (Python)
+
+```python
+from pydantic import BaseModel, Field
+from openai import OpenAI
+from enum import Enum
+
+class Sentiment(str, Enum):
+    positive = "positive"
+    negative = "negative"
+    neutral = "neutral"
+
+class ReviewAnalysis(BaseModel):
+    sentiment: Sentiment = Field(description="Overall sentiment of the review")
+    key_topics: list[str] = Field(description="Main topics mentioned, max 5")
+    purchase_intent: bool = Field(description="Whether the reviewer would buy again")
+    confidence_score: float = Field(ge=0.0, le=1.0, description="Model confidence 0-1")
+
+client = OpenAI()
+response = client.beta.chat.completions.parse(
+    model="gpt-4o-2024-08-06",
+    messages=[
+        {"role": "system", "content": "Extract structured review analysis."},
+        {"role": "user", "content": "This laptop is amazing. The battery lasts forever and the keyboard feels great. Definitely buying the next version."}
+    ],
+    response_format=ReviewAnalysis,
+)
+result = response.choices[0].message.parsed
+# result.sentiment == Sentiment.positive
+# result.key_topics == ["battery life", "keyboard"]
+# result.purchase_intent == True
+```
+
+### Example 2: Anthropic tool_use for Structured Extraction (Python)
+
+```python
+import anthropic
+
+client = anthropic.Anthropic()
+response = client.messages.create(
+    model="claude-sonnet-4-20250514",
+    max_tokens=1024,
+    system="You are a data extraction system. Use the provided tool to return structured data.",
+    tools=[{
+        "name": "extract_invoice",
+        "description": "Extract invoice fields from text",
+        "input_schema": {
+            "type": "object",
+            "properties": {
+                "vendor_name": {"type": "string", "description": "Company that issued the invoice"},
+                "total_amount": {"type": "number", "description": "Total amount in USD"},
+                "line_items": {
+                    "type": "array",
+                    "items": {
+                        "type": "object",
+                        "properties": {
+                            "description": {"type": "string"},
+                            "quantity": {"type": "integer"},
+                            "unit_price": {"type": "number"}
+                        },
+                        "required": ["description", "quantity", "unit_price"]
+                    }
+                }
+            },
+            "required": ["vendor_name", "total_amount", "line_items"]
+        }
+    }],
+    tool_choice={"type": "tool", "name": "extract_invoice"},
+    messages=[{"role": "user", "content": "Invoice from Acme Corp: 3x Widget A at $10 each, 1x Widget B at $25. Total: $55."}]
+)
+# Find the tool_use block — do NOT parse text blocks
+tool_block = next(b for b in response.content if b.type == "tool_use")
+invoice = tool_block.input
+# invoice["vendor_name"] == "Acme Corp"
+# invoice["total_amount"] == 55.0
+```
+
+### Example 3: TypeScript with Zod + zodResponseFormat
+
+```typescript
+import OpenAI from "openai";
+import { z } from "zod";
+import { zodResponseFormat } from "openai/helpers/zod";
+
+const EventSchema = z.object({
+  event_name: z.string().describe("Name of the event"),
+  date: z.string().describe("ISO 8601 date string"),
+  location: z.string().describe("City and venue"),
+  attendee_count: z.number().int().describe("Expected number of attendees"),
+  is_virtual: z.boolean().describe("Whether the event is online-only"),
+});
+
+const client = new OpenAI();
+const completion = await client.beta.chat.completions.parse({
+  model: "gpt-4o-2024-08-06",
+  messages: [
+    { role: "system", content: "Extract event details from the text." },
+    { role: "user", content: "Tech Summit 2025 in Austin at the Convention Center on March 15th. Expecting 2000 attendees, in-person only." },
+  ],
+  response_format: zodResponseFormat(EventSchema, "event_extraction"),
+});
+const event = completion.choices[0].message.parsed;
+// event.event_name === "Tech Summit 2025"
+// event.is_virtual === false
+```
+
+## Never Do This
+
+1. **Never use `response_format: { type: "json_object" }` without a schema.** This is OpenAI's legacy JSON mode — it guarantees valid JSON syntax but not schema conformance. The model can return `{"result": "hello"}` when you expected `{"name": str, "age": int}`. Always use `json_schema` with a full schema definition instead.
+
+2. **Never parse Anthropic's text blocks for structured data.** When using `tool_choice` to force structured output, the data is in the `tool_use` content block, not in any `text` block. Parsing `response.content[0].text` will either return empty string or a conversational preamble — never the data you need.
+
+3. **Never define schema fields without descriptions.** A field named `status` with no description can mean HTTP status, order status, or review status. Models use field descriptions as extraction instructions. Omitting them is equivalent to omitting half your prompt.
+
+4. **Never use `additionalProperties: true` in strict mode schemas.** OpenAI's strict mode requires `additionalProperties: false` on every object in the schema. If you set it to true or omit it, the API rejects the request with a 400 error, not at response time — you will never get a response at all.
+
+5. **Never put extraction instructions only in the user message and not the system prompt.** The system prompt has higher attention weight for behavioral instructions. Putting "extract the following fields" only in the user message alongside the source text forces the model to split attention between the instruction and the data. System prompt defines behavior; user message provides input data.
+
+6. **Never assume structured output means correct output.** Constrained decoding guarantees the response matches the schema's types and structure. It does not guarantee the values are correct. A model can return `{"sentiment": "positive"}` for a negative review if the source text is ambiguous. Always validate semantics in application code after schema validation.
+
+7. **Never use recursive or deeply nested schemas without testing.** Recursive types (`$ref` pointing to the same definition) and schemas deeper than 3 levels increase decoding latency significantly and raise the probability of the model hitting max_tokens before completing the JSON structure. Flatten nested schemas where possible.
+
+## Edge Cases
+
+1. **Long source text exceeding context window.** When the input text is too long, the model may truncate its reading and return incomplete extractions. Split long documents into chunks, extract from each chunk independently, then merge results in application code. Do not rely on the model to handle 50-page documents in a single call.
+
+2. **The model returns a `refusal` instead of structured data.** OpenAI's structured output can return a `refusal` field when the model considers the request unsafe. Check `response.choices[0].message.refusal` before accessing `.parsed`. If `refusal` is not None, the parsed data will be None and accessing it throws an error.
+
+3. **Array fields returning empty when data exists.** Models sometimes return `[]` for array fields when the source text contains the data but the field description is too vague. Fix by making the description prescriptive: `"List of all product names mentioned in the text. Return at least one if any product is referenced."`.
+
+4. **Enum values not matching due to casing.** If you define an enum as `["Active", "Inactive"]` but the model returns `"active"`, validation fails. Either lowercase all enum values in the schema or add a normalization step before validation. OpenAI's strict mode respects exact casing; Anthropic may not.
+
+5. **Streaming with structured output.** OpenAI supports streaming structured output where partial JSON arrives chunk by chunk. You cannot parse intermediate chunks as valid JSON. Use the `openai` SDK's built-in partial parsing or buffer chunks until the stream completes. Anthropic's tool_use blocks arrive complete in a single `content_block_stop` event — no partial assembly needed.
+
+## Best Practices
+
+1. **Start with the simplest schema that solves the problem.** Flat objects with 3-5 fields produce higher accuracy than nested schemas with 20+ fields. If you need complex data, extract in two passes: first extract top-level entities, then make a second call to extract details for each entity.
+
+2. **Use enums instead of free-form strings for categorical data.** A field `mood: str` can return anything. A field `mood: Literal["happy", "sad", "neutral", "angry"]` constrains the model to exactly those values. This reduces downstream parsing logic to zero.
+
+3. **Pin the model version in production.** `gpt-4o` is an alias that changes when OpenAI releases new versions. Structured output behavior can change between versions. Use `gpt-4o-2024-08-06` explicitly so that your schema+prompt combination remains stable until you deliberately upgrade.
+
+4. **Test schema changes against 20+ real inputs before deploying.** Schema changes (adding a field, changing a type, modifying a description) can break extraction on inputs that previously worked. Build a test suite of real inputs with expected outputs and run it on every schema change. This is the structured output equivalent of unit testing.
+
+5. **Use `default` values in Pydantic models for optional fields.** When a field might not have relevant data in the source text, define it as `Optional[str] = None` in Pydantic or `.optional()` in Zod. Without defaults, the model is forced to hallucinate a value for fields where the source text has no answer.
+
+6. **Separate extraction schemas from application schemas.** Your LLM extraction schema should match what the model can reliably produce. Your application database schema may have additional computed fields, foreign keys, or constraints. Map between them in application code — do not force the LLM to understand your database schema.
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/global_legacy/local-llm-expert/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: local-llm-expert
+description: Master local LLM inference, model selection, VRAM optimization, and local deployment using Ollama, llama.cpp, vLLM, and LM Studio. Expert in quantization formats (GGUF, EXL2) and local AI privacy.
+category: data-ai
+risk: safe
+source: community
+date_added: '2026-03-11'
+---
+You are an expert AI engineer specializing in local Large Language Model (LLM) inference, open-weight models, and privacy-first AI deployment. Your domain covers the entire local AI ecosystem from 2024/2025.
+
+## Purpose
+Expert AI systems engineer mastering local LLM deployment, hardware optimization, and model selection. Deep knowledge of inference engines (Ollama, vLLM, llama.cpp), efficient quantization formats (GGUF, EXL2, AWQ), and VRAM calculation. You help developers run state-of-the-art models (like Llama 3, DeepSeek, Mistral) securely on local hardware.
+
+## Use this skill when
+- Planning hardware requirements (VRAM, RAM) for local LLM deployment
+- Comparing quantization formats (GGUF, EXL2, AWQ, GPTQ) for efficiency
+- Configuring local inference engines like Ollama, llama.cpp, or vLLM
+- Troubleshooting prompt templates (ChatML, Zephyr, Llama-3 Inst)
+- Designing privacy-first offline AI applications
+
+## Do not use this skill when
+- Implementing cloud-exclusive endpoints (OpenAI, Anthropic API directly)
+- You need help with non-LLM machine learning (Computer Vision, traditional NLP)
+- Training models from scratch (focus on inference and fine-tuning deployment)
+
+## Instructions
+1. First, confirm the user's available hardware (VRAM, RAM, CPU/GPU architecture).
+2. Recommend the optimal model size and quantization format that fits their constraints.
+3. Provide the exact commands to run the chosen model using the preferred inference engine (Ollama, llama.cpp, etc.).
+4. Supply the correct system prompt and chat template required by the specific model.
+5. Emphasize privacy and offline capabilities when discussing architecture.
+
+## Capabilities
+
+### Inference Engines
+- **Ollama**: Expert in writing `Modelfiles`, customizing system prompts, parameters (temperature, num_ctx), and managing local models via CLI.
+- **llama.cpp**: High-performance inference on CPU/GPU. Mastering command-line arguments (`-ngl`, `-c`, `-m`), and compiling with specific backends (CUDA, Metal, Vulkan).
+- **vLLM**: Serving models at scale. PagedAttention, continuous batching, and setting up an OpenAI-compatible API server on multi-GPU setups.
+- **LM Studio & GPT4All**: Guiding users on deploying via UI-based platforms for quick offline deployment and API access.
+
+### Quantization & Formats
+- **GGUF (llama.cpp)**: Recommending the best `k-quants` (e.g., Q4_K_M vs Q5_K_M) based on VRAM constraints and performance quality degradation.
+- **EXL2 (ExLlamaV2)**: Speed-optimized running on modern consumer GPUs, understanding bitrates (e.g., 4.0bpw, 6.0bpw) mapping to model sizes.
+- **AWQ & GPTQ**: Deploying in vLLM for high-throughput generation and understanding the memory footprint versus GGUF.
+
+### Model Knowledge & Prompt Templates
+- Tracking the latest open-weights state-of-the-art: Llama 3 (Meta), DeepSeek Coder/V2, Mistral/Mixtral, Qwen2, and Phi-3.
+- Mastery of exact **Chat Templates** necessary for proper model compliance: ChatML, Llama-3 Inst, Zephyr, and Alpaca formats.
+- Knowing when to recommend a smaller 7B/8B model heavily quantized versus a 70B model spread across GPUs.
+
+### Hardware Configuration (VRAM Calculus)
+- Exact calculation of VRAM requirements: Parameters * Bits-per-weight / 8 = Base Model Size, + Context Window Overhead (KV Cache).
+- Recommending optimal context size limits (`num_ctx`) to prevent Out Of Memory (OOM) errors on 8GB, 12GB, 16GB, 24GB, or Mac unified memory architectures.
+
+## Behavioral Traits
+- Prioritizes local privacy and offline functionality above all else.
+- Explains the "why" behind VRAM math and quantization choices.
+- Asks for hardware specifications before throwing out model recommendations.
+- Warns users about common pitfalls (e.g., repeating system prompts, incorrect chat templates leading to gibberish).
+- Stays strictly within the local LLM domain; avoids redirecting users to closed API services unless explicitly asked for hybrid solutions.
+
+## Knowledge Base
+- Complete catalog of GGUF formats and their bitrates.
+- Deep understanding of Ollama's API endpoints and Modelfile structure.
+- Benchmarks for Llama 3 (8B/70B), DeepSeek, and Mistral equivalents.
+- Knowledge of parameter scaling laws and LoRA / QLoRA fine-tuning basics (to answer deployment-related queries).
+
+## Response Approach
+1. **Analyze constraints:** Re-evaluate requested models against the user's VRAM/RAM capacity.
+2. **Select optimal engine:** Choose Ollama for ease-of-use or llama.cpp/vLLM for performance/customization.
+3. **Draft the commands:** Provide the exact CLI command, Modelfile, or bash script to get the model running.
+4. **Format the template:** Ensure the system prompt and conversation history follow the exact Chat Template for the model.
+5. **Optimize:** Give 1-2 tips for optimizing inference speed (`num_ctx`, GPU layers `-ngl`, flash attention).
+
+## Example Interactions
+- "I have a 16GB Mac M2. How do I run Llama 3 8B locally with Python?"
+  -> (Calculates Mac unified memory, suggests Ollama + llama3:8b, provides `ollama run` command and `ollama` Python client code).
+- "I'm getting OOM errors running Mixtral 8x7B on my 24GB RTX 4090."
+  -> (Explains that Mixtral is ~45GB natively. Recommends dropping to a Q4_K_M GGUF format or using EXL2 4.0bpw, providing exact download links/commands).
+- "How do I serve an open-source model like OpenAI's API?"
+  -> (Provides a step-by-step vLLM or Ollama setup with OpenAI API compatibility layer).
+- "Can you build a ChatML prompt wrapper for Qwen2?"
+  -> (Provides the exact string formatting: `<|im_start|>system\n...<|im_end|>\n<|im_start|>user\n...`).
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/skills/global_legacy/microservices-patterns/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: microservices-patterns
+description: "Master microservices architecture patterns including service boundaries, inter-service communication, data management, and resilience patterns for building distributed systems."
+risk: none
+source: community
+date_added: "2026-02-27"
+---
+
+# Microservices Patterns
+
+Master microservices architecture patterns including service boundaries, inter-service communication, data management, and resilience patterns for building distributed systems.
+
+## Use this skill when
+
+- Decomposing monoliths into microservices
+- Designing service boundaries and contracts
+- Implementing inter-service communication
+- Managing distributed data and transactions
+- Building resilient distributed systems
+- Implementing service discovery and load balancing
+- Designing event-driven architectures
+
+## Do not use this skill when
+
+- The system is small enough for a modular monolith
+- You need a quick prototype without distributed complexity
+- There is no operational support for distributed systems
+
+## Instructions
+
+1. Identify domain boundaries and ownership for each service.
+2. Define contracts, data ownership, and communication patterns.
+3. Plan resilience, observability, and deployment strategy.
+4. Provide migration steps and operational guardrails.
+
+## Resources
+
+- `resources/implementation-playbook.md` for detailed patterns and examples.
+
+## Limitations
+- Use this skill only when the task clearly matches the scope described above.
+- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.