Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:52:26 +08:00
commit cd85d9d995
16 changed files with 2047 additions and 0 deletions

View File

@@ -0,0 +1,7 @@
# Assets
Bundled resources for api-mock-server skill
- [ ] mock_server_template.yaml: A template YAML file for configuring the mock server, including placeholders for the OpenAPI spec, response configurations, and other settings.
- [ ] example_responses/: A directory containing example responses for different API endpoints, including successful responses, error responses, and edge cases.
- [ ] openapi_example.yaml: Example OpenAPI spec file to be used as a starting point.

View File

@@ -0,0 +1,32 @@
{
"skill": {
"name": "skill-name",
"version": "1.0.0",
"enabled": true,
"settings": {
"verbose": false,
"autoActivate": true,
"toolRestrictions": true
}
},
"triggers": {
"keywords": [
"example-trigger-1",
"example-trigger-2"
],
"patterns": []
},
"tools": {
"allowed": [
"Read",
"Grep",
"Bash"
],
"restricted": []
},
"metadata": {
"author": "Plugin Author",
"category": "general",
"tags": []
}
}

View File

@@ -0,0 +1,76 @@
# Configuration for the API Mock Server Plugin
# --- OpenAPI Specification ---
# Path to your OpenAPI (Swagger) specification file (YAML or JSON).
# This file defines the API endpoints, request parameters, and response schemas.
openapi_spec_path: "REPLACE_ME/path/to/your/openapi.yaml"
# --- Server Settings ---
# Host and port for the mock server to listen on.
host: "0.0.0.0" # Listen on all interfaces
port: 8080
# --- Response Configuration ---
# Default settings for generating responses. These can be overridden per-endpoint.
default_response:
# Simulate network latency (in milliseconds).
latency: 50 # milliseconds
# Probability of returning an error (0.0 to 1.0).
error_rate: 0.05 # 5% chance of error
# Default HTTP status code to return for successful requests.
success_status_code: 200
# Endpoint-specific overrides. Use the OpenAPI path as the key.
endpoints:
"/users":
# Override the default latency for this endpoint.
latency: 100
# Example of a custom response for a specific HTTP method and status code.
GET:
200:
# Custom response body (JSON). If not specified, will generate a fake response.
body:
message: "Successfully retrieved users"
users:
- id: "user1"
name: "John Doe"
- id: "user2"
name: "Jane Smith"
500:
body:
error: "Simulated server error"
status_code: 500
"/products/{product_id}":
GET:
404:
body:
error: "Product not found"
status_code: 404
# --- Data Persistence ---
# Whether to persist data between requests (stateful mocking).
stateful: true
# Path to a file where data will be stored. If empty, data will be stored in memory.
data_file: "REPLACE_ME/path/to/data.json" # Example: data.json
# --- Security ---
# API Key authentication (example).
api_key:
enabled: false
# Header name for the API Key.
header_name: "X-API-Key"
# Valid API Key value.
valid_key: "YOUR_API_KEY_HERE"
# --- Logging ---
# Configure logging level. Options: DEBUG, INFO, WARNING, ERROR, CRITICAL
log_level: INFO
# --- Advanced Settings ---
# CORS configuration (optional).
cors:
enabled: true
# Allowed origins (e.g., "http://localhost:3000"). Use "*" to allow all origins (not recommended for production).
allowed_origins: "*"

View File

@@ -0,0 +1,145 @@
# openapi_example.yaml
# This file defines an example OpenAPI specification for the API Mock Server plugin.
# It's designed to be a starting point and should be customized to your specific API.
openapi: 3.0.0
info:
title: Example API
version: 1.0.0
description: A simple example API for demonstration purposes.
servers:
- url: http://localhost:8080 # The base URL where the mock server will run. Change if needed.
description: Local development server
paths:
/users:
get:
summary: Get a list of users
description: Returns a list of all users.
operationId: getUsers
responses:
'200':
description: A list of users.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/User'
'500':
description: Internal server error. Simulates a possible error response.
content:
application/json:
schema:
type: object
properties:
error:
type: string
description: Error message.
example: "Internal Server Error"
post:
summary: Create a new user
description: Creates a new user.
operationId: createUser
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/UserCreate'
responses:
'201':
description: User created successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/User'
'400':
description: Bad request. Invalid input.
content:
application/json:
schema:
type: object
properties:
error:
type: string
description: Error message.
example: "Invalid input data"
/users/{userId}:
get:
summary: Get a user by ID
description: Returns a single user by their ID.
operationId: getUserById
parameters:
- in: path
name: userId
schema:
type: integer
required: true
description: The ID of the user to retrieve.
responses:
'200':
description: The user object.
content:
application/json:
schema:
$ref: '#/components/schemas/User'
'404':
description: User not found.
content:
application/json:
schema:
type: object
properties:
error:
type: string
description: Error message.
example: "User not found"
components:
schemas:
User:
type: object
properties:
id:
type: integer
description: The user's ID.
example: 123
name:
type: string
description: The user's name.
example: "John Doe"
email:
type: string
format: email
description: The user's email address.
example: "john.doe@example.com"
# Add more user properties as needed
# Example:
# role:
# type: string
# description: The user's role.
# example: "admin"
required:
- id
- name
- email
UserCreate:
type: object
properties:
name:
type: string
description: The user's name.
example: "Jane Doe"
email:
type: string
format: email
description: The user's email address.
example: "jane.doe@example.com"
# Add more user creation properties as needed
required:
- name
- email

View File

@@ -0,0 +1,28 @@
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Claude Skill Configuration",
"type": "object",
"required": ["name", "description"],
"properties": {
"name": {
"type": "string",
"pattern": "^[a-z0-9-]+$",
"maxLength": 64,
"description": "Skill identifier (lowercase, hyphens only)"
},
"description": {
"type": "string",
"maxLength": 1024,
"description": "What the skill does and when to use it"
},
"allowed-tools": {
"type": "string",
"description": "Comma-separated list of allowed tools"
},
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+$",
"description": "Semantic version (x.y.z)"
}
}
}

View File

@@ -0,0 +1,27 @@
{
"testCases": [
{
"name": "Basic activation test",
"input": "trigger phrase example",
"expected": {
"activated": true,
"toolsUsed": ["Read", "Grep"],
"success": true
}
},
{
"name": "Complex workflow test",
"input": "multi-step trigger example",
"expected": {
"activated": true,
"steps": 3,
"toolsUsed": ["Read", "Write", "Bash"],
"success": true
}
}
],
"fixtures": {
"sampleInput": "example data",
"expectedOutput": "processed result"
}
}

View File

@@ -0,0 +1,7 @@
# References
Bundled resources for api-mock-server skill
- [ ] openapi_specification.md: A detailed explanation of the OpenAPI specification and best practices for creating API specifications.
- [ ] mock_server_configuration.md: Documentation on the configuration options for the mock server, including how to customize responses, simulate latency, and handle errors.
- [ ] example_openapi_specs.md: A collection of example OpenAPI specifications for different types of APIs (e.g., REST, GraphQL) to serve as a starting point for users.

View File

@@ -0,0 +1,69 @@
# Skill Best Practices
Guidelines for optimal skill usage and development.
## For Users
### Activation Best Practices
1. **Use Clear Trigger Phrases**
- Match phrases from skill description
- Be specific about intent
- Provide necessary context
2. **Provide Sufficient Context**
- Include relevant file paths
- Specify scope of analysis
- Mention any constraints
3. **Understand Tool Permissions**
- Check allowed-tools in frontmatter
- Know what the skill can/cannot do
- Request appropriate actions
### Workflow Optimization
- Start with simple requests
- Build up to complex workflows
- Verify each step before proceeding
- Use skill consistently for related tasks
## For Developers
### Skill Development Guidelines
1. **Clear Descriptions**
- Include explicit trigger phrases
- Document all capabilities
- Specify limitations
2. **Proper Tool Permissions**
- Use minimal necessary tools
- Document security implications
- Test with restricted tools
3. **Comprehensive Documentation**
- Provide usage examples
- Document common pitfalls
- Include troubleshooting guide
### Maintenance
- Keep version updated
- Test after tool updates
- Monitor user feedback
- Iterate on descriptions
## Performance Tips
- Scope skills to specific domains
- Avoid overlapping trigger phrases
- Keep descriptions under 1024 chars
- Test activation reliability
## Security Considerations
- Never include secrets in skill files
- Validate all inputs
- Use read-only tools when possible
- Document security requirements

View File

@@ -0,0 +1,70 @@
# Skill Usage Examples
This document provides practical examples of how to use this skill effectively.
## Basic Usage
### Example 1: Simple Activation
**User Request:**
```
[Describe trigger phrase here]
```
**Skill Response:**
1. Analyzes the request
2. Performs the required action
3. Returns results
### Example 2: Complex Workflow
**User Request:**
```
[Describe complex scenario]
```
**Workflow:**
1. Step 1: Initial analysis
2. Step 2: Data processing
3. Step 3: Result generation
4. Step 4: Validation
## Advanced Patterns
### Pattern 1: Chaining Operations
Combine this skill with other tools:
```
Step 1: Use this skill for [purpose]
Step 2: Chain with [other tool]
Step 3: Finalize with [action]
```
### Pattern 2: Error Handling
If issues occur:
- Check trigger phrase matches
- Verify context is available
- Review allowed-tools permissions
## Tips & Best Practices
- ✅ Be specific with trigger phrases
- ✅ Provide necessary context
- ✅ Check tool permissions match needs
- ❌ Avoid vague requests
- ❌ Don't mix unrelated tasks
## Common Issues
**Issue:** Skill doesn't activate
**Solution:** Use exact trigger phrases from description
**Issue:** Unexpected results
**Solution:** Check input format and context
## See Also
- Main SKILL.md for full documentation
- scripts/ for automation helpers
- assets/ for configuration examples

View File

@@ -0,0 +1,7 @@
# Scripts
Bundled resources for api-mock-server skill
- [ ] create_mock_server.py: Script to generate a mock server based on an OpenAPI spec. It should take the OpenAPI spec as input and output the mock server configuration.
- [ ] update_mock_server.py: Script to update an existing mock server with a new OpenAPI spec or configuration changes.
- [ ] validate_openapi_spec.py: Script to validate an OpenAPI spec for correctness and compatibility before creating a mock server.

View File

@@ -0,0 +1,42 @@
#!/bin/bash
# Helper script template for skill automation
# Customize this for your skill's specific needs
set -e
function show_usage() {
echo "Usage: $0 [options]"
echo ""
echo "Options:"
echo " -h, --help Show this help message"
echo " -v, --verbose Enable verbose output"
echo ""
}
# Parse arguments
VERBOSE=false
while [[ $# -gt 0 ]]; do
case $1 in
-h|--help)
show_usage
exit 0
;;
-v|--verbose)
VERBOSE=true
shift
;;
*)
echo "Unknown option: $1"
show_usage
exit 1
;;
esac
done
# Your skill logic here
if [ "$VERBOSE" = true ]; then
echo "Running skill automation..."
fi
echo "✅ Complete"

View File

@@ -0,0 +1,32 @@
#!/bin/bash
# Skill validation helper
# Validates skill activation and functionality
set -e
echo "🔍 Validating skill..."
# Check if SKILL.md exists
if [ ! -f "../SKILL.md" ]; then
echo "❌ Error: SKILL.md not found"
exit 1
fi
# Validate frontmatter
if ! grep -q "^---$" "../SKILL.md"; then
echo "❌ Error: No frontmatter found"
exit 1
fi
# Check required fields
if ! grep -q "^name:" "../SKILL.md"; then
echo "❌ Error: Missing 'name' field"
exit 1
fi
if ! grep -q "^description:" "../SKILL.md"; then
echo "❌ Error: Missing 'description' field"
exit 1
fi
echo "✅ Skill validation passed"