DEV Community: XYG-LUNA

SKILL.md: A Standard Format for Distributable AI Agent Skills

XYG-LUNA — Sat, 25 Jul 2026 08:53:13 +0000

When we talk about "AI skills", most people think of prompts. But prompts are not distributable, versionable, or discoverable. SKILL.md solves this.

What is SKILL.md?

SKILL.md is a structured markdown format that allows AI agents to discover, load, and execute skills dynamically. Think of it as a universal package format for AI capabilities—similar to how npm packages work for JavaScript or PyPI packages for Python, but designed from the ground up for agent-to-agent consumption.

Each SKILL.md file contains everything an agent needs:

Metadata: name, version, description, tags
System Prompt: the behavioral instructions
Input Schema: what parameters the skill accepts
Output Schema: what the skill returns
Examples: real-world usage patterns

Format Anatomy: Inside a SKILL.md File

A typical SKILL.md follows this structure:

# Skill Name

**Version**: 1.0.0
**Tags**: category, use-case
**Description**: What this skill does and why an agent might need it.

## System Prompt

Your role is to [primary function]. When handling tasks:
- Consider [important constraint 1]
- Always [important behavior 1]
- Return [output format]

## Input Schema

json
{
"type": "object",
"properties": {
"param_name": {
"type": "string",
"description": "What this parameter does"
}
},
"required": ["param_name"]
}


## Output Schema

json
{
"type": "object",
"properties": {
"result": {
"type": "string",
"description": "The skill's output"
}
}
}


## Examples

### Example 1: Basic Usage
**Input**: `{"param": "value"}`
**Output**: `{"result": "expected output"}`

### Example 2: Complex Case
**Input**: `{"param": "another value"}`
**Output**: `{"result": "complex output"}`

plaintext

Why Markdown Over JSON/YAML?

We chose markdown because:

Human-Readable: Non-technical stakeholders can understand the skill's purpose by reading the first few lines. No need to parse JSON.
Git-Friendly: Diffs are meaningful. You can see exactly what changed in a skill update without needing specialized tools.
Easy to Edit: Markdown files work in any text editor. GitHub's web interface renders them beautifully. There's no syntax barrier.
Agents Already Understand Markdown: Most LLMs have seen millions of markdown files during training. They parse it naturally.
Extensible: You can add custom sections without breaking existing parsers. JSON/YAML schemas don't degrade gracefully.

Three Real Examples at Different Complexity Levels

Example 1: Simple Naming Skill

This skill generates product names based on target audience and category.

Input: audience ("tech professionals" or "parents"), category ("software" or "toy")
Output: A list of 5 creative product names

Use Case: Startups naming their first product; marketing teams brainstorming.

Example 2: Copywriting Diagnosis Skill

This skill analyzes marketing copy and identifies engagement weaknesses—passive voice, weak verbs, missing urgency signals.

Input: Marketing copy (any length), target audience
Output: JSON object with findings:

Passive voice: 3 instances (lines 2, 5, 8)
Weak verbs: 2 instances
Missing urgency: yes/no
Recommended improvements: [list]

Use Case: Copywriters iterating on email campaigns; content teams scaling their output.

Example 3: Ziwei Astrology Chart Skill

This skill generates personalized astrology readings based on birth date, time, and location—applying classical Ziwei principles.

Input: Birth datetime (ISO format), location (coordinates), reading type ("personality" or "career")
Output: Detailed astrology report with palace interpretations, strength indices, key life themes.

Use Case: Astrology platforms, personalized content engines, wellness apps.

How Agents Discover and Load Skills

Agents locate skills through directory conventions:

/skills
  /naming
    SKILL.md          ← Agent reads this file
  /copywriting
    SKILL.md
  /ziwei-astrology
    SKILL.md

Discovery patterns include:

Directory Scanning: Agents scan known skill repositories
Registry Lookup: Central registries maintain skill metadata (like npm)
URL-Based Loading: Direct SKILL.md files by URL

When an agent needs a capability, it:

Searches for matching skills (by tags, keywords)
Loads the SKILL.md file
Parses metadata and schemas
Invokes the skill with validated inputs

Production-Ready: 50 Free Open-Source Skills

We've packaged 50 production-ready skills covering common tasks:

Content Creation: copywriting, naming, outline generation
Data Processing: CSV parsing, JSON transformation, filtering
Analysis: sentiment analysis, text summarization, code review
Automation: file organization, batch processing, scheduling

Repository: https://github.com/tancoai/lianzhu-skill

Browse the code, fork it, contribute improvements. All skills are open-source and MIT-licensed.

The SKILL.md Platform: 284 Skills (50 Free + Paid)

Beyond the open-source collection, the full SKILL.md marketplace hosts 284 verified skills:

Platform: https://tancoai.com

Access includes:

Free tier: 50 skills + community contributions
Paid tiers: Premium skills for specialized domains (finance, healthcare, creative services)
API access: Integrate skills into your own applications
Version control: Each skill is versioned and can be rolled back

Next Steps: How You Can Contribute

Star the Repository: Show support by starring https://github.com/tancoai/lianzhu-skill
Create Your Own Skill: Fork the repo, write your own SKILL.md file following the format, and submit a pull request.
Share Your Use Cases: Have an idea for a skill? Open an issue and describe it.
Integrate with Your Tools: Use skills in your AI agents, chatbots, or internal automation.

The SKILL.md standard is young, but it's solving real problems: how to make AI capabilities modular, shareable, and agent-discoverable. We'd love to have you contribute.

Questions? Check the repository README or join our community discussions on GitHub.

Building a Multi-Skill MCP Server: Lessons from Serving 284 AI Tools

XYG-LUNA — Sat, 25 Jul 2026 04:34:09 +0000

When you're serving 284 different AI tools through a single MCP (Model Context Protocol) server, the architecture challenges are... not what you'd expect.

I've been running CHROMATIC-MCP for about a year now. Here's what I've learned about building a multi-skill AI platform that actually works in production.

The Context Window Problem

The first thing that breaks when you have 284 tools: the tools/list response. Most AI clients have a context window limit. If you dump all 284 tool descriptions at once, you've burned through 40% of the available context before the user even asks a question.

Our solution: Two-layer directory

{
  "tools": [
    {"name": "discover_skills", "description": "Search available skills by category or keyword"},
    {"name": "lianzhu_ziwei", "description": "Purple Star Astrology chart analysis"},
    // ... 9 more curated "featured" tools
  ]
}

The client sees ~10 tools initially. When it needs something specific, it calls discover_skills to search the full catalog. This dropped our context overhead from 12K tokens to under 2K.

Description Engineering > Prompt Engineering

Here's the counterintuitive lesson: the tool descriptions matter more than the prompts inside the tools.

AI models decide whether to call your tool based solely on the description. Bad description = invisible tool.

What didn't work:

"description": "Analyzes personality"

What works:

"description": "MBTI personality coaching - Given a user's MBTI type (e.g. INFJ, ENTP), provides targeted career advice, relationship insights, and personal growth strategies. Input: {type: string, question: string}. Returns structured coaching response."

Key elements that improved our call rate:

Start with what it IS (noun phrase)
Explain the input format explicitly
Describe what the output looks like
Include 2-3 example use cases in the description itself

We A/B tested descriptions across 50 skills. Good descriptions increased call rates by 3-4x.

The Execute-Locally Pattern

Not every skill needs server-side LLM execution. For our 50 free skills, we use an "execute-locally" pattern:

Client calls tools/call with the skill name
Server returns... a SKILL.md document (not an LLM response)
The client's own LLM uses that document as instructions
Execution happens entirely on the client side

This means:

Zero server-side compute cost for free skills
Users can run them with any local model (Ollama, ChatGLM, etc.)
No API key required for the free tier
Complete privacy - nothing leaves the user's device

Billing: Per-Task, Not Per-Token

We deliberately chose per-task billing over per-token:

Task succeeds → charge (¥1.29-6.99 depending on complexity)
Task fails, times out, or produces garbage → no charge

The implementation uses a "completion certificate" pattern:

Request → Processing → Validation Gate → Certificate Issued → Billing Triggered
                         ↓
                    Failure → No Certificate → No Charge

This aligns incentives: we want tasks to succeed (that's how we get paid), and users don't fear experimenting (failures are free).

Monitoring in Production

With 284 skills, you need observability. Our setup:

JSONL structured logs per skill invocation
Key metrics: call_count, success_rate, p95_latency, certificate_issued
Weekly Pareto analysis: top 20 skills account for 80% of traffic

Current numbers (honest):

~500 daily requests
85% task success rate
P95 latency: <2s
Most traffic from US (working on domestic CN growth)

What I'd Do Differently

Start with fewer skills. 284 is maintenance hell. Start with 20, nail those, then expand.
Invest in description testing early. We wasted 3 months with poor descriptions before realizing this was the bottleneck.
Build the billing system before launch. Retrofitting billing into a running system is painful.

Try It

50 free skills (local execution): github.com/tancoai/lianzhu-skill
Full platform (284 skills): tancoai.com (5 free tasks for new users)
MCP endpoint: https://mcp.tancoai.com/mcp

Questions welcome. Happy to dive deeper into any of these topics.

50+ Free AI Agent Skills That Run Locally (No API Keys, No Cloud, No Limits)

XYG-LUNA — Fri, 24 Jul 2026 20:03:13 +0000

Tancoai launched its free tier this week—50 local skills, zero API keys required. Your tasks run locally on your machine using your own agent and model. Your task content never leaves your system.

This privacy-first approach is compelling. But there's a critical prerequisite that determines how much value you'll actually get: your LLM's capability level.

In this guide, I'll categorize these 50 skills by model requirements so you can make an informed decision about which ones to install now, and which to wait on.

The Ground Rules

Free skills come as standard SKILL.md packages. The flow is: download ZIP → validate → place in your local skill directory per your agent's documentation → refresh → copy the task instruction and run it with your agent.

No API keys needed. Your platform never sees your task content. But the quality of results depends entirely on your model. That same skill will produce polished output with GPT-4o or Claude Sonnet, and a basic template with a weaker model.

Skills for Weaker Models (~15)

These 15 skills focus on structured information rearrangement rather than deep understanding. Even basic models can follow fixed rules effectively:

Meeting Summary: Extract agenda items, conclusions, action items, owners, deadlines, and open questions from meeting notes
Weekly Report: Convert chat logs and TODOs into completed tasks, impact, blockers, and next week's priorities
Expense Categorization: Sort transactions into categories with amounts and flagged anomalies
Calendar Conflict Detection: Find overlapping time slots and hidden scheduling friction (commute time, prep buffer)
Travel Checklist: Generate destination-aware packing lists accounting for weather, duration, and activities
Group Expense Split: Preserve payer, participants, currency, and calculate minimal transfers to settle
Used Item Listing: Organize condition, defects, accessories, and listing terms
Relocation Plan: Sequence pre-move, moving day, and post-move tasks
Personal Introduction: Select relevant experiences for the occasion and time constraints
Email Drafting: Adjust tone based on recipient relationship and communication goal
Commit Message: Normalize code changes to Conventional Commits format
Flashcard Generation: Convert material into active recall cards with fixed structure
Task Prioritization: Rank TODOs by impact, deadline, dependencies, and effort
Birth Month Flowers: Look up and generate month-specific flower meanings
Color Palette: Convert color names into harmonized palette cards

These work because they're formula-driven, not generation-heavy.

Skills for Mid-Tier Models (~15)

These require genuine understanding but work well with GPT-4o or Claude Sonnet:

Project Handoff: Generate transfer packages with checklists, checksums, quality gates, and relay chains
Change Risk Analysis: Define affected files, track versions, detect boundary violations, run regression checks
8-Type Personality Test: Role-play 8 personas evaluating your skill or idea
Concept Naming: Draw from 8 sources and apply era and aesthetic filters to suggest names
Knowledge Decomposition: Find prerequisites and break topics into achievable sub-goals
Pricing Breakdown: Separate costs, margins, tax, refund rate into detailed line items
Reading Notes: Parse highlights into assertions, evidence, questions, and action items
Presentation Structure: Confirm audience decision, then outline page-by-page narrative
Xiaohongshu Copy: Write post drafts based on verified product facts (no fabrication)
Spaced Repetition: Build a study schedule accounting for subject and weak areas
Resume Review: Diagnose resume gaps and suggest edits against job requirements
Argument Outline: State thesis, then recursively decompose
Error Analysis: Categorize mistakes by knowledge gap, reading error, computation, or strategy
Interview Prep: Deep-dive follow-up questions on real past projects
Year in Review: Reflect on the year through key milestones and connections

These are solid with modern mid-tier models. Lighter models will produce vaguer results.

Skills for Strong Models (~8)

These demand high language sophistication, reasoning depth, or domain understanding:

Five-Dimension Review: Check for AI tone, marketing voice, persona consistency, technical depth, and authenticity—while avoiding duplication with past posts
API Contract Review: Map resource names, method semantics, status codes, error structures, auth, pagination, idempotency, and versioning
16 Personality Types Coach: Generate observation questions, counterexamples, and week-long micro-experiments per type
Nine Behavior Mirrors: Score 18 scenario questions across 9 behavioral dimensions
Parent-Child Game Generator: Produce genuinely playable games within safety and age-appropriateness bounds

Strong models (Claude Opus/Sonnet, GPT-4) unlock the real value here. Weaker models will feel surface-level.

Free Tier Boundaries

The free tier handles local, lightweight tasks. If you need fact-checking, source verification, or provable claims—the paid tier (辩真, 灼见, 连珠) handles those. Those tools can verify against external sources and are built for precision.

New users get 5 free premium tasks to test. Use them on something you genuinely need verification for, not routine free skill testing.

How to Get Started

Free skills: Download ZIP → place in skill directory → refresh agent → copy instruction and submit

Paid skills: Add MCP config: https://mcp.tancoai.com/mcp, then run discover_skills to confirm

Links:

GitHub: https://github.com/tancoai/lianzhu-skill
Platform: tancoai.com

The Bottom Line

Free skills don't take your API keys or task content. But they do depend on your model. Start by fixing your LLM layer. Once you have a capable model, the skill library multiplies its value.

Skill strength isn't about platforms—it's about the human asking the questions and the model answering them.

Completing the CI/CD Pipeline for AI Agents: How 3 New Skills Filled Critical Gaps

XYG-LUNA — Fri, 24 Jul 2026 17:47:04 +0000

Completing the CI/CD Pipeline for AI Agents: How 3 New Skills Filled Critical Gaps

The Problem: A Broken Pipeline

In our previous articles, we discussed Lianzhu's five-stage CI/CD framework for AI agents. But there was a gap. Three critical positions in the pipeline were empty.

The Five Stages: Before and After

Stage	Skill	Previous Status	Current Status
Route Definition	QuanYan·Source Seeking	Live	Live
Acceptance Criteria	SunMao·Acceptance Building	Missing	Now Live
Quality Assurance	CuiLu·Skill Forging	Live	Live
Multi-Role Testing	ShaLuang·Multi-Role Trial	Missing	Now Live
Signal Feedback	DuoSheng·Public Signal Indexing	Missing	Now Live

The pipeline was broken at the acceptance criteria, testing, and feedback stages. When running an AI agent task with Lianzhu, you could define requirements, perform QA checks—but then you had no formal way to validate acceptance criteria, test with different user perspectives, or collect real-world signal feedback.

SunMao: Define Acceptance Before Execution

The gap it fills: Acceptance criteria is always added after the fact.

You've probably experienced this scenario: An agent completes a task. You glance at it and think "good enough"—then it ships. Later, problems emerge. You ask: "What were the acceptance criteria?" The answer: none.

SunMao changes this workflow:

Define acceptance conditions first, converting requirements into executable checks
Lock down success and failure paths before execution begins
Include file manifests and hashes to verify deliverables haven't been silently modified mid-execution

The hash verification is particularly important. Since AI agents can modify their own work during execution, SunMao ensures that acceptance validation catches unauthorized changes before sign-off.

ShaLuang: Stress-Test Before Launch

The gap it fills: Internal testing can't substitute for real user perspectives.

The Lianzhu pipeline previously terminated at the QA stage. The three QA gates catch logical errors—but they don't catch "seems fine to me but users hate it" scenarios.

ShaLuang introduces multi-perspective testing:

Pre-defined seven user archetypes (varying experience levels, different use cases)
Each archetype surfaces different blind spots:
- New users get stuck on terminology
- Power users hit edge cases in defaults
- Task-focused users skip optional-but-useful steps
Clear separation between simulated feedback and real user data

This distinction is critical. Many agent testing frameworks conflate simulation results with actual user feedback, leading to decisions built on false data. ShaLuang maintains this boundary: simulation exposes obvious issues; real user feedback requires separate collection.

DuoSheng: Listen to Public Signals, Not Internal Hype

The gap it fills: No systematic way to collect post-launch feedback.

The first four Lianzhu stages complete entirely internally. But what happens after launch? Your Skill goes live, users interact with it, discussions happen online—how do you systematically collect these signals and feed them back into development?

DuoSheng addresses this:

Convert ShaLuang testing questions into public search queries
Log each discovery with source, timestamp, and credibility score
Feed validated signals back to the development origin point
Policy: Listen only to external echoes, not internal celebration

No internal testing data. Only public sources. Every signal logged with provenance, not accepted wholesale.

This has practical value. Ship a Skill or feature, then wonder what users think. A full manual search cycle takes hours. DuoSheng standardizes this workflow.

The Complete Pipeline Now

With all three Skills live, the Lianzhu pipeline is now complete:

QuanYan (Define Route)
  → SunMao (Define Acceptance)
    → CuiLu (Execute Quality Checks)
      → ShaLuang (Multi-Role Testing)
        → DuoSheng (Public Signal Feedback)

This mirrors CI/CD best practices: each stage has clear inputs and outputs. When something fails, you know exactly which stage to debug.

How to Use

All three new Skills are available through MCP. Add https://mcp.tancoai.com/mcp to your MCP configuration and call discover_skills to see the full toolkit.

Use individually: Call each Skill by name for specific needs.

Use as a chain: Call Lianzhu, which orchestrates all five stages in sequence automatically.

New users get 5 free complete-task credits—perfect for experiencing the full five-stage pipeline with a real task.

Explore the complete Lianzhu toolkit:

GitHub: https://github.com/tancoai/lianzhu-skill
Platform: https://tancoai.com

The pipeline is complete. Your AI agent workflow just got more predictable.

How to Evaluate MCP Servers Before Installing Them (A Practical Checklist)

XYG-LUNA — Fri, 24 Jul 2026 15:52:34 +0000

The MCP (Model Context Protocol) ecosystem is growing fast. There are now hundreds of MCP servers available — but how do you know which ones are worth installing?

After building and evaluating 60+ MCP servers ourselves, we developed a practical checklist that saved us from shipping broken tools. Here's the framework we use.

The Problem

Most MCP server listings tell you what the server does. Very few tell you how well it does it. You install something that sounds perfect, then discover:

It activates on the wrong prompts (false positives)
It pulls irrelevant context (retrieval drift)
It sounds confident but gives wrong answers (ungrounded reasoning)
It never improves from feedback

Sound familiar?

The 5-Dimension Evaluation Checklist

Before installing any MCP server, ask these questions:

1. Trigger Precision

Question: Does this server activate when (and only when) it should?

Red flags:

Overly broad trigger descriptions ("use for anything related to X")
No documented activation conditions
Activates on common words that appear in unrelated contexts

Green flags:

Specific, documented trigger scenarios
Clear non-activation cases listed
Tested against diverse prompts

2. Retrieval Quality

Question: Does it pull the right context for the task?

Red flags:

Returns large chunks without filtering
No citation or source tracking
Retrieves plausible but outdated information

Green flags:

Targeted, minimal context retrieval
Source attribution for every piece of context
Version-aware (knows when data might be stale)

3. Reasoning Grounding

Question: Are its conclusions tied to actual data?

Red flags:

Generates advice without referencing specific inputs
Can't explain its reasoning chain
Confident answers that contradict its own retrieved context

Green flags:

Every conclusion references specific evidence
Explicitly flags uncertainty
Gracefully handles missing information

4. Output Usefulness

Question: Does the output actually solve your problem?

Red flags:

Generic responses that could apply to any input
Repeats the question back without adding value
Requires significant post-processing to be actionable

Green flags:

Directly actionable output
Adapted to specific input context
Includes edge cases and limitations

5. Feedback Integration

Question: Does it learn from usage?

Red flags:

Same mistake repeated across sessions
No mechanism for user corrections
Ignores conversation history

Green flags:

Adapts behavior based on user corrections
Tracks what worked and what didn't
Progressive improvement over time

Quick Scoring Template

For each dimension, score 0-1:

Dimension	Score	Notes
Trigger	_/1
Retrieval	_/1
Reasoning	_/1
Output	_/1
Feedback	_/1
Total	_/5

Our threshold: We don't ship anything scoring below 4/5 (0.8 per dimension).

Real Example: What Failure Looks Like

From our evaluation of 60+ servers, here's the distribution of failures:

Retrieval drift (40%): The #1 failure mode. Server pulls plausible but incorrect context.
Trigger false positives (25%): Activates too often, eroding user trust.
Reasoning without grounding (20%): Sounds logical but isn't tied to data.
Feedback absence (15%): Same mistakes repeated indefinitely.

Practical Tips

Test with adversarial prompts first. Don't just test the happy path. Try prompts that are similar to the intended use case but shouldn't activate the server.
Check the README for failure documentation. Servers that document their limitations are usually higher quality than those that claim to handle everything.
Look for version history. Active maintenance is a strong signal. Abandoned servers with a single commit are rarely production-ready.
Try it in a sandbox first. Run it against 10 diverse prompts and check whether it handles edge cases gracefully.

Resources

We've open-sourced our evaluation framework and 50+ evaluated servers:

GitHub: github.com/tancoai/lianzhu-skill
Platform with evaluated servers: tancoai.com

If you've developed your own evaluation criteria for MCP servers, I'd love to hear about it in the comments.

This post is part of a series on building production-quality AI agent tools. The first post covered our Five Elements framework.

Building 60 MCP Servers Using the Five Elements Framework: What We Learned

XYG-LUNA — Fri, 24 Jul 2026 15:20:19 +0000

Building 60 MCP Servers Using the Five Elements Framework: A Build-in-Public Journey

Most people focus on adding more features to their AI agents. I discovered better evaluation loops matter more.

Over the past several months, my team and I have been building tancoai.com — a platform hosting 60+ MCP (Model Context Protocol) servers and Skills. What started as "let's build a few useful AI tools" turned into a deep exploration of what makes a Skill actually reliable in production.

Along the way, we developed something we call the Five Elements Framework (连珠五环). It's not a library or a package — it's a way of thinking about Skill design that forced us to stop adding features blindly and start measuring whether what we built actually worked.

This article is an honest account of what happened when we applied this framework across 60+ servers. Including the parts where it didn't go well.

The Problem We Faced

When we started, the approach was straightforward: identify a useful task, build a Skill for it, test it a few times, ship it. Repeat.

This worked for the first 10 or so Skills. They passed basic tests. They returned plausible-looking outputs. But something felt wrong.

We call it the "works but feels wrong" syndrome. A Skill would pass our manual test cases — we'd type a prompt, get a reasonable response, and mark it done. But when we looked at real usage logs, the picture was different:

Trigger failures: Skills activated on prompts they shouldn't have, or failed to activate when they should.
Context gaps: Skills retrieved irrelevant information or missed the context that actually mattered.
Format drift: The same Skill would return JSON 80% of the time and prose 20% of the time, breaking downstream consumers.
No feedback loop: We had no way to know if a Skill was getting better or worse over time.

The breaking point came when we analyzed 100+ failed Skill implementations. Not crashes — "successful" executions that produced wrong or unhelpful results. The patterns were striking:

Failure Type	Occurrence
Trigger mismatches (Skill ran on wrong input type)	67%
Retrieval problems (relevant context existed but wasn't surfaced)	54%
Reasoning errors (logic sound in isolation, failed on edge cases)	43%
Output format issues (structure inconsistent across runs)	31%
Any feedback mechanism at all	0%

That last number was the wake-up call. We were building Skills with no way to know if they were getting better.

Introducing the Five Elements Framework

We didn't set out to create a "framework." We set out to stop making the same mistakes. But after a while, the patterns we kept checking condensed into five elements:

1. Trigger — Does it activate at the right moment?

Before anything else, a Skill needs to know when to run. This sounds trivial, but it's where most silent failures begin. A fact-checking Skill that activates on every question containing a URL is too aggressive. One that only activates on explicit "fact-check this" commands is too passive.

We test triggers with a corpus of "should fire" and "should not fire" inputs and measure precision and recall separately. A Skill isn't allowed to ship until both exceed 90%.

2. Retrieval — Is context found accurately?

Most Skills need external context — API data, documents, previous conversation history. The question isn't "can it retrieve?" but "does it retrieve the right things?"

We measure this with a hit-rate metric: for a set of test cases with known-relevant context, what percentage of the time does the Skill surface that context? Before the framework, we didn't track this at all. Turns out, several of our Skills were confidently answering questions using completely irrelevant source material.

3. Reasoning — Is decision logic sound?

This is the hardest element to test because "reasoning" is fuzzy. Our approach: for each Skill, we define 10-20 test cases with known-correct outcomes and measure pass rate. We also include adversarial cases — inputs designed to trigger common reasoning errors.

The key insight: reasoning quality isn't about the model being smarter. It's about the prompt, the context, and the constraints working together. A well-structured prompt with the right context can make a weaker model outperform a stronger one with poor structure.

4. Output — Is response format reliable?

This was our most embarrassing finding. We assumed our Skills returned consistent formats. They didn't. JSON fields would be missing, types would shift between string and number, markdown would sometimes include code fences and sometimes not.

Now, every Skill has an output schema test. We run the Skill 100 times on varied inputs and check that 100% of outputs conform to the declared schema. If even one run fails, the Skill doesn't ship.

5. Feedback — Can we measure improvement over time?

This is the element that ties everything together. Without feedback, the other four are just snapshots. With it, they become a trend.

Our feedback system tracks:

Per-Skill accuracy over time (test case pass rate by version)
Real-world usage patterns (which inputs are most common, where do users retry)
Failure clustering (grouping failures by root cause element)

When we deploy a new version of a Skill, we can see whether Trigger accuracy went up or down, whether Retrieval improved, whether Output consistency held. This is the difference between "I think it's better" and "it's measurably better on dimension X."

How They Work Together

The five elements aren't a checklist — they're a system. A Trigger failure means the Skill never gets a chance to Retrieve. A Retrieval failure means Reasoning operates on wrong data. An Output failure means Feedback can't be collected properly (because downstream systems break). Feedback informs improvements to all four.

The framework's value isn't in any single element. It's in the discipline of checking all five before shipping.

Building 60 Servers: What Actually Happened

Here's an honest timeline:

Weeks 1-4: Built the first 10 Skills using trial-and-error. No framework. No eval. Just vibes. About 6 of those 10 Skills had serious issues that we only discovered weeks later.

Weeks 5-8: The analysis. We stopped building and started looking at what was broken. This is when we analyzed the 100+ failed implementations and started forming the framework. Productive? Not in terms of new Skills. But it changed everything that came after.

Weeks 9-16: Rebuilt with the framework. We went back through the first 10 Skills and applied all five elements. This was painful — several Skills needed fundamental redesigns, not tweaks.

Weeks 17-24: Scaled to 60+ Skills. With the framework in place, building new Skills became faster. Not because the framework writes code, but because it tells you when you're done. Each element has a pass/fail threshold. You're not done when it "looks good." You're done when Trigger >= 90%, Retrieval >= 85%, Reasoning >= 90%, Output = 100%, and Feedback is wired up.

Key Failure Point: The Fact-Checking Skill (辩真)

Our fact-checking Skill initially had 70% accuracy on our test suite. The problem wasn't reasoning — it was Retrieval. The Skill was pulling context from the wrong sources. After restructuring the retrieval pipeline (and adding the retrieval hit-rate metric), accuracy went to 92%. Same model, same prompt structure. Just better context.

# Before: retrieval was implicit — whatever comes back, we use
def fact_check(claim):
    context = search_web(claim)
    return llm.verify(claim, context)

# After: retrieval is tested, filtered, and honest about gaps
def fact_check(claim):
    candidates = search_web(claim, top_k=10)
    relevant = filter_by_relevance(candidates, claim, threshold=0.7)
    if len(relevant) < 2:
        return {"status": "insufficient_sources", "claim": claim}
    return llm.verify(claim, relevant)

That threshold=0.7 and the len(relevant) < 2 check came directly from the Retrieval element analysis. Before, the Skill would confidently verify claims using a single low-relevance source. After, it would honestly report when it couldn't find enough relevant context.

The Honest Struggles

Bots vs. real traffic. Early on, our usage data was dominated by crawlers and automated tools. It took weeks to separate real usage signals from noise. We eventually added client-side behavioral signals to filter this.
Documentation debt. Building 60 Skills means 60 sets of docs. We fell behind badly. The eval reports partially solve this — they serve as living documentation of what each Skill actually does and how well.
Maintenance burden. 60 Skills don't maintain themselves. When an upstream API changes, 3-4 Skills might break simultaneously. The Feedback element helps catch this faster, but it's still a constant effort.
The temptation to skip. Around Skill #45, we got tired. The framework felt like overhead. We shipped two Skills without full eval. Both came back with issues within a week. The framework exists because discipline is hard to maintain manually.

Lessons Learned

What surprised us most: The biggest accuracy improvements didn't come from better models or better prompts. They came from better Trigger and Retrieval — the elements before reasoning. We spent so much energy optimizing prompts that we missed the fact that our Skills were running on wrong inputs and retrieving wrong context.

Advice for builders:

Start with Feedback. Even if you can only measure one thing, measure it consistently. You can't improve what you can't track.
Don't build a "framework" on day one. Build 5-10 things, notice your patterns, then formalize.
Output consistency matters more than output quality. A Skill that always returns valid JSON with 85% accuracy is more useful than one that returns brilliant prose 95% of the time but breaks your pipeline 5% of the time.

When to use this framework vs. keep it simple: If you're building 1-3 Skills, ad-hoc testing is fine. If you're building 10+, the lack of structure will catch up with you. If you're building 50+, you need this or something like it — there's no way to hold 50 Skills' quality in your head.

What's Next

We're continuing to build in public. The eval reports for all Skills are available on tancoai.com, showing both strengths and weaknesses — no spin. When a Skill scores poorly on an element, it's visible. When we improve it, the trend is visible too.

The framework itself is open source. We're not claiming it's the only way to think about Skill design — but it's the way that worked for us after 60+ servers worth of trial and error.

GitHub: https://github.com/tancoai/lianzhu-skill

We welcome issues, discussions, and contributions. If you've built Skills and hit similar walls, we'd love to hear about your approach. Disagreement is especially welcome — the framework evolved through arguments, and it should keep evolving.

**Website with live demos and eval dashboards: [https://tancoai.com](https://ta

Try 252 AI Skills for Free — Just Copy This curl Command

XYG-LUNA — Tue, 14 Jul 2026 12:33:39 +0000

I built an MCP Server that bundles 252 AI skills into a single npm package. Each skill costs just 0.05 RMB (about $0.007) per call, with 10 free calls per day. No signup required.

What is MCP?

MCP (Model Context Protocol) is an open protocol by Anthropic that lets AI assistants like Claude Desktop, Cursor, and VS Code connect to external tools and data sources. Think of it as a USB standard for AI tools.

What are the 252 skills?

They cover 15+ categories:

Psychology & Mysticism: MBTI personality analysis, I-Ching divination, tarot reading
Code Development: PR review, bug fixing, API design, system debugging
Productivity: Weekly reports, meeting notes, PPT outlines
E-commerce: Product copywriting, ad copy generation, pricing calculators
Legal: Contract review, legal document templates
Browser Automation: Puppeteer/Playwright scripts
Text Processing: AI text humanizer, academic text authenticity

Technical Architecture

Single npm Package

All 252 skills are stored in one TypeScript file and loaded dynamically at runtime. No external database needed.

Dual Transport Mode

SSE mode: Remote connection, no installation needed
stdio mode: Local run with npx xiangguangyu-mcp-skills

Pay-Per-Use with HTTP 402

Each skill gives 10 free calls per day. After that, the server returns HTTP 402 Payment Required with an Alipay payment link. User scans the QR code, pays 0.05 RMB, and the request is automatically approved.

Quick Start

Claude Desktop / Cursor / VS Code (stdio)

Add this to your MCP config:

{
  "mcpServers": {
    "xiangguangyu": {
      "command": "npx",
      "args": ["-y", "xiangguangyu-mcp-skills@latest"]
    }
  }
}

SSE Remote Connection

{
  "mcpServers": {
    "xiangguangyu": {
      "url": "http://124.222.26.218:3100/sse"
    }
  }
}

12 MCP Tools

The 252 skills are exposed through 12 MCP tools:

discover_skills - Browse all 252 skills
get_skill_detail - Get detailed documentation
skill_mbti-deep-analysis - MBTI personality test
skill_bianzhen - Multi-model fact-checking
skill_zhuojian - 5-layer deep analysis
skill_cuilu - Skill forging engine
skill_ad-copywriter - Ad copy generation
skill_contract-guardian - Contract risk review
skill_weekly-report - Weekly report writer
skill_taobao-listing - E-commerce product copy
skill_game-audio - Game audio design
skill_shijin - Skill quality checker

Real Stats (3 days after launch)

Total calls: 391
Free calls: 376
Paid calls: 8 (all my own tests)
Real users: 2-3
Real revenue: 0

The product works. The payment mechanism works. Now I just need more people to know about it.

Building a Payment-Enabled MCP Server: Let AI Agents Pay for Skills via HTTP 402

XYG-LUNA — Tue, 14 Jul 2026 07:15:05 +0000

Building a Payment-Enabled MCP Server: Let AI Agents Pay for Skills via HTTP 402

The Problem

In the traditional SaaS model, users need to sign up, subscribe, and bind a credit card before they can use an AI tool. This creates high friction.

The answer is HTTP 402 Payment Required — a rarely-used HTTP status code perfect for pay-per-use AI APIs.

What is HTTP 402?

HTTP 402 "Payment Required" is a standard HTTP status code. When a client calls an API without payment, the server returns 402 with payment parameters. After payment, the request is processed.

The Architecture

I built this for CHROMATIC-MCP — an MCP Server exposing 252 AI skills through 12 MCP tools:

Client → API Gateway (Auth + Payment Check) → Skill Router → Skill Server

Key Components

Free Tier: 10 free calls per skill per day, no auth needed
Alipay AI Pay: Auto-debit agreement for seamless payments
MCP Tools: Each skill registered as individual MCP tool

12 MCP Tools

Tool	Price	Description
discover_skills	Free	Browse all 252 skills
skill_mbti-deep-analysis	¥0.10	MBTI assessment
skill_bianzhen	¥0.50	Multi-model fact-checking
skill_ad-copywriter	¥0.10	Ad copy generation
skill_zhuojian	¥0.50	5-layer deep analysis
skill_cuilu	¥0.50	Skill forging engine
skill_weekly-report	¥0.10	Weekly report generator
skill_taobao-listing	¥0.10	E-commerce copywriting
skill_contract-guardian	¥0.10	AI contract review
skill_game-audio	¥0.10	Game audio design
skill_shijin	¥0.50	Skill quality testing
get_skill_detail	Free	Get skill details

Quick Start

Install via npx

npx -y chromatic-mcp-skills@latest

Configure in Claude Desktop / Cursor

{
  "mcpServers": {
    "CHROMATIC-MCP": {
      "command": "npx",
      "args": ["-y", "chromatic-mcp-skills@latest"]
    }
  }
}

Try a Skill (Free)

curl http://124.222.26.218:3000/api/skill/mbti-deep-analysis

Why HTTP 402 Works for AI

Zero friction: No signup, no credit card. First 10 calls free.
Standard protocol: Any HTTP client understands 402.
Agent-friendly: AI agents can detect 402 and handle payment.
Granular pricing: ¥0.10–¥0.50 per call depending on complexity.

Lessons Learned

402 is underutilized but semantically correct for payment walls
Free tier removes all friction for evaluation
Alipay AI Pay auto-debit means returning users never see payment prompts
MCP is the future — any AI agent can discover and use skills

What's Next

Multi-model support
Volume discounts
Third-party skill submissions
More payment methods

GitHub: https://github.com/Chromatic0618/alipay-mcp-server
npm: chromatic-mcp-skills
Live API: http://124.222.26.218:3000/api/skills

Built by Chromatic0618. MIT License.