Blueprints
Development Guide
Complete guide for contributing to VDK Blueprints - writing rules, testing, and community guidelines
Development Guide
Learn how to contribute to VDK Blueprints by writing new rules, improving existing ones, and following our community guidelines.
Quick Start for Contributors
1. Environment Setup
# Fork and clone the repository
git clone https://github.com/your-username/VDK-Blueprints.git
cd VDK-Blueprints
# Create a feature branch
git checkout -b feature/new-rule-name
# Set up development environment
npm install # If package.json exists
2. Understanding the Structure
.ai/
├── rules/ # Main rules directory
│ ├── core/ # Core behavioral patterns
│ ├── languages/ # Programming languages
│ ├── technologies/ # Frameworks and tools
│ ├── stacks/ # Technology combinations
│ ├── tasks/ # Development workflows
│ ├── assistants/ # AI platform configs
│ └── tools/ # Development tools
├── schemas/ # Validation schemas
├── templates/ # Contribution templates
└── scripts/ # Utility scripts
3. Choose Your Contribution Type
Type | Description | Template | Complexity |
---|---|---|---|
New Rule | Add support for new technology/pattern | rule-template.mdc | Medium |
Rule Enhancement | Improve existing rule | Edit existing .mdc | Easy |
Platform Support | Add new AI assistant support | platform-template.json | Hard |
Documentation | Improve guides and examples | Markdown files | Easy |
Schema Update | Modify validation schemas | JSON Schema | Hard |
Writing New Rules
Rule Template Structure
Every rule follows this structure:
---
# === Core Identification ===
id: "unique-rule-id"
title: "Human Readable Title"
description: "Brief description of what this rule does"
version: "2.0.1"
lastUpdated: "2025-07-25"
# === Categorization ===
category: "technology" # core|languages|technologies|stacks|tasks|assistants|tools
subcategory: "framework" # Optional subcategory
complexity: "medium" # simple|medium|complex
scope: "project" # system|project|component|file
audience: "developer" # developer|team-lead|architect
maturity: "stable" # experimental|beta|stable|deprecated
# === Platform Compatibility ===
platforms:
claude-code:
compatible: true
command: false
memory: true
namespace: "project"
allowedTools: ["Read", "Write", "Edit"]
mcpIntegration: false
cursor:
compatible: true
activation: "auto-attached"
globs: ["**/*.tsx", "**/*.jsx"]
priority: "high"
windsurf:
compatible: true
mode: "workspace"
xmlTag: "react-patterns"
characterLimit: 700
github-copilot:
compatible: true
priority: 8
reviewType: "code-quality"
# === Dependencies & Relationships ===
requires: [] # Required rules that must be loaded
suggests: ["typescript-modern", "tailwind4"] # Recommended rules
conflicts: [] # Rules that conflict with this one
supersedes: [] # Rules this one replaces
# === Content Structure ===
contentSections:
- "overview"
- "patterns"
- "examples"
- "best-practices"
- "common-mistakes"
---
# Rule Content Goes Here
## Overview
Brief explanation of what this rule covers and when to use it.
## Core Patterns
Key patterns and approaches the AI should follow.
## Examples
Concrete code examples showing the patterns in action.
## Best Practices
Guidelines for optimal implementation.
## Common Mistakes
What to avoid and how to prevent errors.
Rule Writing Guidelines
1. Clear and Specific Instructions
❌ Bad: "Write good React code"
✅ Good: "Use functional components with hooks. Prefer const assertions for better type inference. Always handle loading and error states in data fetching components."
2. Include Practical Examples
## Data Fetching Pattern
```typescript
const UserProfile = ({ userId }: { userId: string }) => {
const [user, setUser] = useState<User | null>(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState<string | null>(null);
useEffect(() => {
fetchUser(userId)
.then(setUser)
.catch(err => setError(err.message))
.finally(() => setLoading(false));
}, [userId]);
if (loading) return <LoadingSpinner />;
if (error) return <ErrorMessage error={error} />;
if (!user) return <NotFound />;
return <UserCard user={user} />;
};
#### 3. Context-Aware Guidance
```markdown
## When to Apply
- ✅ React components that fetch data
- ✅ Components with async operations
- ❌ Pure presentational components
- ❌ Server-side rendering contexts
4. Platform-Specific Optimizations
platforms:
cursor:
# Auto-activate for React files
globs: ["**/*.tsx", "**/*.jsx", "src/components/**/*"]
priority: "high"
windsurf:
# Memory-optimized version
characterLimit: 500
xmlTag: "react-data-fetching"
Rule Categories Deep Dive
Core Rules
- Purpose: Fundamental AI behavior that applies universally
- Audience: All developers using AI assistants
- Examples: Agent behavior, code quality, security practices
- Writing Tips: Focus on universal principles, avoid technology-specific details
Language Rules
- Purpose: Programming language-specific guidance
- Audience: Developers using specific languages
- Examples: TypeScript patterns, Python conventions, Swift guidelines
- Writing Tips: Include language-specific syntax, idioms, and best practices
Technology Rules
- Purpose: Framework and tool-specific implementation patterns
- Audience: Developers using specific technologies
- Examples: React patterns, Next.js guidelines, Tailwind utilities
- Writing Tips: Focus on framework conventions, common patterns, integration approaches
Stack Rules
- Purpose: Multi-technology combinations and integration patterns
- Audience: Full-stack developers working with technology combinations
- Examples: Next.js + Supabase, React Native mobile
- Writing Tips: Address integration challenges, data flow, deployment considerations
Task Rules
- Purpose: Specific development workflows and processes
- Audience: Developers performing specific tasks
- Examples: Code review, security audit, performance optimization
- Writing Tips: Provide step-by-step workflows, checklists, validation criteria
Assistant Rules
- Purpose: AI platform-specific optimizations
- Audience: Users of specific AI assistants
- Examples: Claude optimizations, Cursor configurations
- Writing Tips: Leverage platform-specific features, optimize for platform constraints
Testing and Validation
Schema Validation
# Validate rule schema
./scripts/validate-rule.py .ai/rules/technologies/my-new-rule.mdc
# Validate all rules
./scripts/validate-all-rules.py
Platform Testing
Test your rule with different AI assistants:
Claude Code Testing
# Add to CLAUDE.md for testing
Test rule: .ai/rules/technologies/my-new-rule.mdc
Expected behavior: [Describe expected AI behavior]
Test scenarios: [List test cases]
Cursor Testing
# Add to .cursorrules for testing
Include new rule content
Test with file patterns: **/*.tsx
Expected auto-completion improvements
Windsurf Testing
{
"testRule": {
"source": ".ai/rules/technologies/my-new-rule.mdc",
"characterLimit": 700,
"expectedBehavior": "Describe expected behavior"
}
}
Manual Testing Checklist
- Rule loads without errors
- AI assistant follows rule guidance
- No conflicts with existing rules
- Performance impact is acceptable
- All target platforms work correctly
- Examples compile and run
- Edge cases are handled
Contributing Process
1. Pre-Contribution Checklist
- Search existing issues and rules
- Read contribution guidelines
- Understand rule writing standards
- Set up development environment
2. Development Workflow
# 1. Create feature branch
git checkout -b feature/add-vue3-rule
# 2. Copy template
cp .ai/templates/rule-template.mdc .ai/rules/technologies/vue3.mdc
# 3. Write rule content
# Edit the rule file with your content
# 4. Validate rule
./scripts/validate-rule.py .ai/rules/technologies/vue3.mdc
# 5. Test with AI assistants
# Test rule with your preferred AI assistant
# 6. Commit changes
git add .ai/rules/technologies/vue3.mdc
git commit -m "feat: add Vue 3 development patterns rule"
# 7. Push and create PR
git push origin feature/add-vue3-rule
3. Pull Request Guidelines
PR Template
## Description
Brief description of the new rule or changes.
## Rule Details
- **Category**: technology
- **Target Technology**: Vue 3
- **Complexity**: medium
- **Platforms Tested**: Claude Code, Cursor
## Testing
- [ ] Schema validation passed
- [ ] Tested with Claude Code
- [ ] Tested with Cursor
- [ ] No conflicts with existing rules
- [ ] Performance impact assessed
## Checklist
- [ ] Rule follows template structure
- [ ] Metadata is complete and accurate
- [ ] Examples are practical and tested
- [ ] Documentation is clear
- [ ] Platform compatibility verified
Review Process
- Automated Checks: Schema validation, lint checks
- Community Review: Peer review by maintainers
- Platform Testing: Verification across AI assistants
- Documentation: Ensure adequate documentation
- Merge: Approved PRs are merged to main
4. Post-Contribution
- Rule is included in next release
- Documentation is updated automatically
- Community is notified of new rule
- Attribution added to contributors list
Community Guidelines
Code of Conduct
- Be respectful and inclusive
- Focus on constructive feedback
- Help newcomers learn and contribute
- Maintain professional communication
Communication Channels
- GitHub Issues: Bug reports and feature requests
- GitHub Discussions: Community Q&A and ideas
- Discord: Real-time community chat
- Documentation: Keep docs updated with changes
Recognition
Contributors are recognized through:
- Rule metadata attribution
- Contributors list in README
- Release note acknowledgments
- Community showcase features
Advanced Topics
Custom Schemas
Create custom validation schemas for specialized rules:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"customField": {
"type": "string",
"description": "Custom field for specialized rules"
}
}
}
Rule Dependencies
Manage complex rule relationships:
# In rule metadata
requires: ["typescript-modern"] # Must have TypeScript rule
suggests: ["react19", "nextjs"] # Works well with these
conflicts: ["vue3"] # Cannot coexist with Vue
supersedes: ["react18"] # Replaces older version
Performance Optimization
Optimize rules for better performance:
platforms:
windsurf:
# Optimize for memory constraints
characterLimit: 500
essentialOnly: true
xmlTag: "performance-critical"
Internationalization
Support multiple languages in rules:
i18n:
supported: ["en", "es", "fr", "de"]
defaultLocale: "en"
translationRequired: false
Next Steps
- Browse existing rules for inspiration
- Set up platform integration to test rules
- Join community discussions
- Report issues or request features