.claude/skills/skill-generator/SKILL.md
Generate new Claude Code skills following the context-aware pattern. Scaffolds SKILL.md, reference docs, and frontmatter.
npx skillsauth add foscomputerservices/FOSUtilities skill-generatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Generate new Claude Code skills following established patterns and best practices.
A skill is a specialized capability that Claude can invoke to perform specific development tasks. Skills follow the context-aware pattern:
User discusses requirements → Skill invoked → References context → Generates code
↑ ↓
(no file paths) (no Q&A prompts)
Key principle: Skills reference conversation context automatically. They don't parse files or ask questions—they infer requirements from what's already been discussed.
Skills shifted from file-parsing/Q&A to context-awareness because:
## Inputs
**Primary mode:** File path to Markdown specification
/skill-name specs/component-spec.md
**Fallback mode:** Conversational protocol (asks questions if no file provided)
## How to Use This Skill
**Invocation:**
/skill-name
**Prerequisites:**
- Requirements understood from conversation context
- (Specific prerequisites for this skill)
**Workflow integration:**
This skill is typically used after (context). The skill references
conversation context automatically—no file paths or Q&A needed.
Every skill must have these sections:
---
name: skill-name
description: One-line description. Use when (trigger conditions).
---
Description format:
# Skill Name
Brief description of what this skill generates.
## Conceptual Foundation
> For full architecture context, see [Architecture.md](../../docs/Architecture.md)
Explain the "why" before the "how":
- What problem does this solve?
- Where does this fit in the architecture?
- What are the key concepts?
Use diagrams for complex relationships:
┌─────────────┐ ┌─────────────────┐ ┌─────────────┐
│ Source │ ───► │ Generator │ ───► │ Output │
│ (Input) │ │ (This Skill) │ │ (Artifact) │
└─────────────┘ └─────────────────┘ └─────────────┘
## When to Use This Skill
- Trigger condition 1
- Trigger condition 2
- Following an implementation plan that requires (x)
Be specific about when the skill should be invoked.
## What This Skill Generates
| File | Location | Purpose |
|------|----------|---------|
| `{Name}.swift` | `Sources/{Target}/` | The main artifact |
| `{Name}Tests.swift` | `Tests/{Target}Tests/` | Test coverage |
List all files the skill creates, with placeholders explained.
## Project Structure Configuration
| Placeholder | Description | Example |
|-------------|-------------|---------|
| `{Target}` | The target name | `App`, `ViewModels` |
| `{Name}` | The component name | `User`, `Dashboard` |
Explain placeholders used throughout the skill.
## How to Use This Skill
**Invocation:**
/skill-name
**Prerequisites:**
- Requirement 1 understood from conversation context
- Requirement 2 discussed or documented
- Requirement 3 identified
**Workflow integration:**
This skill is typically used (when/after what). The skill references
conversation context automatically—no file paths or Q&A needed.
Often follows (related-skill).
Key elements:
## Pattern Implementation
This skill references conversation context to determine (what it builds):
### (Type) Detection
From conversation context, the skill identifies:
- **Key element 1** (from prior discussion or specifications read by Claude)
- **Key element 2** (from requirements already in context)
- **Key element 3** (from codebase or discussion)
### (Aspect) Analysis
From requirements already in context:
- **Design decision 1** (what guides this choice)
- **Design decision 2** (what guides this choice)
### (Output) Generation
Based on detected patterns:
1. First generated artifact
2. Second generated artifact
3. Third generated artifact
### Context Sources
Skill references information from:
- **Prior conversation**: Requirements discussed with user
- **Specification files**: If Claude has read specs/docs into context
- **Codebase analysis**: From reading existing code patterns
- **Related artifacts**: From other skills or previous generation
Structure:
## Key Patterns
### Pattern Name 1
Explain the pattern with code examples:
```swift
// Code example showing the pattern
Another important pattern...
Show concrete examples of what the skill generates.
### 9. File Templates
```markdown
## File Templates
See [reference.md](reference.md) for complete file templates.
Reference a separate file with full templates (don't inline massive templates).
## Naming Conventions
| Concept | Convention | Example |
|---------|------------|---------|
| File name | `{Pattern}` | `UserViewModel.swift` |
| Test name | `{Pattern}Tests` | `UserViewModelTests.swift` |
Establish consistent naming across generated files.
## See Also
- [Related Skill 1](../related-skill-1/SKILL.md) - When to use instead
- [Related Skill 2](../related-skill-2/SKILL.md) - Often used before this
- [Architecture Doc](../../docs/Architecture.md) - Full context
- [reference.md](reference.md) - Complete templates
Link to related skills and documentation.
## Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | YYYY-MM-DD | Initial skill |
Track changes over time.
## Collaboration Protocol
1. Confirm X with user
2. Ask about Y
3. Generate Z one file at a time with feedback
Why not: This implies Q&A interaction, which contradicts context-aware pattern.
## Generation Process
### Step 1: Understand Requirements
Ask:
1. **What is the name?**
2. **What fields does it have?**
Why not: Skills infer from context, they don't ask questions.
## Inputs
**Primary mode:** File path to specification
/skill-name specs/spec.md
**Fallback mode:** Q&A if no file provided
Why not: Claude reads files naturally into context. No special input mode needed.
Here's a minimal complete skill:
---
name: example-generator
description: Generate example components. Use when creating demo code or sample implementations.
---
# Example Generator
Generate example components following established patterns.
## Conceptual Foundation
An example component demonstrates (purpose). It shows how to use (API/pattern).
## When to Use This Skill
- Creating demo code
- Generating sample implementations
- Following tutorials or guides
## What This Skill Generates
| File | Location | Purpose |
|------|----------|---------|
| `Example.swift` | `Sources/Examples/` | The example implementation |
## Project Structure Configuration
| Placeholder | Description | Example |
|-------------|-------------|---------|
| `{Name}` | Example name | `HelloWorld` |
## How to Use This Skill
**Invocation:**
/example-generator
**Prerequisites:**
- Example purpose understood from conversation
- Target API discussed
**Workflow integration:**
This skill is used when demonstrating concepts. The skill references
conversation context automatically—no file paths or Q&A needed.
## Pattern Implementation
This skill references conversation context to determine example structure:
### Example Type Detection
From conversation context, the skill identifies:
- **Purpose** (demonstration, tutorial, testing)
- **API target** (what to demonstrate)
- **Complexity level** (simple, intermediate, advanced)
### Code Generation
Generates example with:
1. Clear comments explaining each step
2. Minimal dependencies
3. Runnable implementation
### Context Sources
Skill references information from:
- **Prior conversation**: Example requirements discussed
- **API documentation**: If Claude has read API docs into context
## Key Patterns
### Simple Example Pattern
\`\`\`swift
// Example showing basic usage
func example() {
// Step 1: Setup
// Step 2: Execute
// Step 3: Verify
}
\`\`\`
## File Templates
See [reference.md](reference.md) for complete templates.
## Naming Conventions
| Concept | Convention | Example |
|---------|------------|---------|
| Example file | `{Name}Example.swift` | `HelloWorldExample.swift` |
## See Also
- [Architecture Doc](../../docs/Architecture.md) - Full context
- [reference.md](reference.md) - Complete templates
## Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | 2026-01-24 | Initial skill |
Generate source files (models, views, controllers, etc.)
Focus on:
Example: fosmvvm-viewmodel-generator
Generate test files for existing code
Focus on:
Example: fosmvvm-serverrequest-test-generator
Generate infrastructure or configuration
Focus on:
Example: fosmvvm-swiftui-app-setup
Generate specific architectural patterns
Focus on:
Example: fosmvvm-fields-generator
The workflow:
User: "I need a ViewModel for the dashboard"
↓
[Discussion of requirements - properties, relationships, etc.]
↓
User: "/fosmvvm-viewmodel-generator"
↓
Skill references prior discussion → Generates ViewModel
NOT:
User: "/fosmvvm-viewmodel-generator"
↓
Skill: "What properties does the ViewModel have?"
↓
User: "Title, cards, user"
↓
Skill: "What types are those?"
When creating a new skill:
When should this skill be invoked?
What information does the skill need?
How does the skill identify:
What files does it create?
Show concrete examples:
What skills work together?
After creating a skill, verify:
/skill-name, no arguments❌ Bad:
The skill accepts JSON in this format:
{
"name": "ComponentName",
"fields": [...]
}
✅ Good:
From conversation context, the skill identifies:
- Component name (from prior discussion)
- Fields (from requirements already in context)
❌ Bad:
The skill parses the specification file to extract field definitions.
✅ Good:
If Claude has read specification files into context, the skill
references that information.
❌ Bad:
Step 1: Ask what type of component
Step 2: Ask what properties it has
✅ Good:
From conversation context, the skill identifies:
- Component type
- Properties
❌ Bad:
The skill cannot proceed without a specification file.
✅ Good:
Prerequisites:
- Requirements understood from conversation context
❌ Bad:
This skill generates any type of component based on user input.
✅ Good:
This skill generates ViewModels for MVVM architecture.
(Specific purpose, specific output)
| Pattern | Example | When to Use |
|---------|---------|-------------|
| {domain}-{type}-generator | fosmvvm-viewmodel-generator | Generates a specific type |
| {domain}-{action}-{type} | fosmvvm-serverrequest-test-generator | Generates tests for a type |
| {domain}-{component}-setup | fosmvvm-swiftui-app-setup | Sets up infrastructure |
| {specific-task} | skill-generator | Meta-skills or utilities |
.claude/skills/
├── skill-name/
│ ├── SKILL.md # Main skill documentation (this file)
│ ├── reference.md # Complete file templates
│ └── examples/ # Optional: example outputs
│ ├── example1.swift
│ └── example2.swift
SKILL.md - Main documentation (what you're reading) reference.md - Full templates (too large for SKILL.md) examples/ - Optional concrete examples
| Version | Date | Changes | |---------|------|---------| | 1.0 | 2026-01-24 | Initial skill-generator meta-skill |
testing
Generate ViewModel tests with codable round-trip, versioning stability, and multi-locale translation verification.
data-ai
Generate FOSMVVM ViewModels for SwiftUI screens, pages, and components. Scaffolds RequestableViewModel, localization bindings, and stub factories.
testing
Generate UI tests for FOSMVVM SwiftUI views using XCTest and FOSTestingUI. Covers accessibility identifiers, ViewModelOperations, and test data transport.
data-ai
Generate SwiftUI views that render FOSMVVM ViewModels. Scaffolds ViewModelView pattern with binding, loading states, and previews.