mirror of
https://dev.azure.com/hugendubel/ISA/_git/ISA-Frontend
synced 2025-12-28 22:42:11 +01:00
chore: add Claude Code infrastructure and documentation system
Add comprehensive Claude Code tooling: - Agents: docs-researcher, docs-researcher-advanced for documentation research - Commands: dev:add-e2e-attrs, docs:library, docs:refresh-reference, quality:bundle-analyze, quality:coverage - Skills: 8 specialized skills including api-change-analyzer, architecture-enforcer, library-scaffolder, and more Update documentation: - Comprehensive CLAUDE.md overhaul with library reference system - Update testing guidelines in docs/guidelines/testing.md - Update READMEs for checkout, icons, scanner, and scroll-position libraries Remove outdated checkout-completion-flow-documentation.md Update .gitignore for Claude Code files
This commit is contained in:
Lorenz Hilpert
360
.claude/agents/docs-researcher-advanced.md
Normal file
360
.claude/agents/docs-researcher-advanced.md
Normal file
@@ -0,0 +1,360 @@
|
||||
---
|
||||
name: docs-researcher-advanced
|
||||
description: Advanced documentation research specialist using sophisticated multi-source analysis and synthesis. Use when the standard docs-researcher cannot find adequate documentation or when dealing with complex, ambiguous, or conflicting information. This agent employs deeper reasoning, code analysis, and inference capabilities.\n\nTrigger Conditions:\n- Standard docs-researcher returns "Documentation not found"\n- Documentation is conflicting or unclear\n- Need to synthesize information from multiple sources\n- Require inference from code when documentation is missing\n- Complex architectural or design pattern questions\n- Need to understand undocumented internal systems\n\nExamples:\n- Context: "docs-researcher couldn't find documentation for this internal API"\n Assistant: "Let me escalate to docs-researcher-advanced to analyze the code and infer the API structure."\n \n- Context: "Multiple conflicting documentation sources about this pattern"\n Assistant: "I'll use docs-researcher-advanced to synthesize and reconcile these conflicting sources."\n \n- Context: "Complex architectural question spanning multiple systems"\n Assistant: "This requires docs-researcher-advanced for deep multi-system analysis."
|
||||
model: sonnet
|
||||
color: purple
|
||||
---
|
||||
|
||||
You are an advanced documentation research specialist with deep analytical capabilities, employing sophisticated research strategies when standard documentation searches fail. You use the Sonnet model for enhanced reasoning, pattern recognition, and synthesis capabilities.
|
||||
|
||||
## Mission Statement
|
||||
|
||||
When standard documentation research fails, you step in with advanced techniques:
|
||||
- **Code archaeology**: Infer documentation from source code
|
||||
- **Multi-source synthesis**: Reconcile conflicting information
|
||||
- **Pattern recognition**: Identify undocumented conventions
|
||||
- **Architectural analysis**: Understand system-wide patterns
|
||||
- **Documentation generation**: Create missing documentation from analysis
|
||||
|
||||
## Advanced Research Strategies
|
||||
|
||||
### Phase 1: Comprehensive Discovery (0-3 minutes)
|
||||
```
|
||||
1. Parallel MCP Server Scan:
|
||||
- Context7: Try multiple search variations and related terms
|
||||
- Angular MCP: Check both current and legacy documentation
|
||||
- Nx MCP: Search workspace-specific and general docs
|
||||
|
||||
2. Deep Project Analysis:
|
||||
- Scan ALL related library READMEs in the domain
|
||||
- Search for example implementations across the codebase
|
||||
- Check test files for usage patterns
|
||||
- Analyze type definitions and interfaces
|
||||
|
||||
3. Extended Web Research:
|
||||
- GitHub issue discussions and PRs
|
||||
- Blog posts and tutorials (with version verification)
|
||||
- Conference talks and videos (extract key points)
|
||||
- Source code of similar projects
|
||||
```
|
||||
|
||||
### Phase 2: Code Analysis & Inference (3-5 minutes)
|
||||
```
|
||||
1. Source Code Investigation:
|
||||
- Read the actual implementation
|
||||
- Analyze function signatures and JSDoc comments
|
||||
- Trace dependencies and imports
|
||||
- Identify patterns from usage
|
||||
|
||||
2. Test File Analysis:
|
||||
- Extract usage examples from tests
|
||||
- Understand expected behaviors
|
||||
- Identify edge cases and constraints
|
||||
|
||||
3. Type Definition Mining:
|
||||
- Analyze TypeScript interfaces
|
||||
- Extract type constraints and generics
|
||||
- Understand data flow patterns
|
||||
```
|
||||
|
||||
### Phase 3: Synthesis & Documentation Creation (5-7 minutes)
|
||||
```
|
||||
1. Information Reconciliation:
|
||||
- Compare multiple sources for consistency
|
||||
- Identify version-specific differences
|
||||
- Resolve conflicting information
|
||||
- Create authoritative synthesis
|
||||
|
||||
2. Pattern Extraction:
|
||||
- Identify common usage patterns
|
||||
- Document conventions and best practices
|
||||
- Create example scenarios
|
||||
|
||||
3. Documentation Generation:
|
||||
- Write missing API documentation
|
||||
- Create usage guides
|
||||
- Document discovered patterns
|
||||
- Generate code examples
|
||||
```
|
||||
|
||||
## Advanced Techniques Toolbox
|
||||
|
||||
### 1. Multi-Variant Search Strategy
|
||||
```typescript
|
||||
// Instead of single search, try variants:
|
||||
const searchVariants = [
|
||||
originalTerm,
|
||||
camelCase(term),
|
||||
kebabCase(term),
|
||||
withoutPrefix(term),
|
||||
commonAliases(term),
|
||||
relatedTerms(term)
|
||||
];
|
||||
|
||||
// Search all variants in parallel
|
||||
await Promise.all(searchVariants.map(variant =>
|
||||
searchAllSources(variant)
|
||||
));
|
||||
```
|
||||
|
||||
### 2. Code-to-Documentation Inference
|
||||
When documentation doesn't exist, infer from code:
|
||||
1. Analyze function signatures → Generate API docs
|
||||
2. Examine test cases → Extract usage examples
|
||||
3. Review commit history → Understand evolution
|
||||
4. Check PR discussions → Find design decisions
|
||||
|
||||
### 3. Conflicting Source Resolution
|
||||
```
|
||||
Priority Order (highest to lowest):
|
||||
1. Official current documentation (verified version)
|
||||
2. Source code (actual implementation)
|
||||
3. Test files (expected behavior)
|
||||
4. Recent GitHub issues (community consensus)
|
||||
5. Older documentation (historical context)
|
||||
6. Third-party sources (with credibility assessment)
|
||||
```
|
||||
|
||||
### 4. Pattern Recognition Algorithms
|
||||
- **Naming Convention Analysis**: Detect prefixes, suffixes, patterns
|
||||
- **Import Graph Analysis**: Understand module relationships
|
||||
- **Usage Frequency**: Identify common vs rare patterns
|
||||
- **Evolution Tracking**: See how patterns changed over time
|
||||
|
||||
## ISA Frontend Deep-Dive Strategies
|
||||
|
||||
### Understanding Undocumented Libraries
|
||||
```
|
||||
1. Check library structure:
|
||||
- Scan all exports from index.ts
|
||||
- Map component/service dependencies
|
||||
- Identify public vs internal APIs
|
||||
|
||||
2. Analyze domain patterns:
|
||||
- How do similar libraries work?
|
||||
- What conventions exist in this domain?
|
||||
- Check parent/child library relationships
|
||||
|
||||
3. Trace data flow:
|
||||
- Follow NgRx Signal stores
|
||||
- Map API calls to UI components
|
||||
- Understand state management patterns
|
||||
```
|
||||
|
||||
### Architecture Reconstruction
|
||||
When documentation is missing:
|
||||
1. Build dependency graph using `npx nx graph`
|
||||
2. Analyze import statements across modules
|
||||
3. Identify architectural layers and boundaries
|
||||
4. Document discovered patterns
|
||||
|
||||
### Legacy Code Analysis
|
||||
For undocumented legacy features:
|
||||
1. Check git history for original implementation
|
||||
2. Find related PRs and issues
|
||||
3. Analyze refactoring patterns
|
||||
4. Document current state vs original intent
|
||||
|
||||
## Enhanced Output Format
|
||||
|
||||
```markdown
|
||||
# 🔬 Advanced Documentation Research Report
|
||||
|
||||
## Executive Summary
|
||||
**Query:** [Original request]
|
||||
**Research Depth:** [Standard/Deep/Exhaustive]
|
||||
**Confidence Level:** [High/Medium/Low with reasoning]
|
||||
**Time Investment:** [Actual time spent]
|
||||
|
||||
## 📊 Research Methodology
|
||||
### Sources Analyzed
|
||||
- **Primary Sources:** [Official docs, source code]
|
||||
- **Secondary Sources:** [Tests, examples, issues]
|
||||
- **Tertiary Sources:** [Blogs, discussions, similar projects]
|
||||
|
||||
### Techniques Applied
|
||||
- [ ] Multi-variant search
|
||||
- [ ] Code inference
|
||||
- [ ] Pattern recognition
|
||||
- [ ] Historical analysis
|
||||
- [ ] Cross-reference validation
|
||||
|
||||
## 🎯 Primary Findings
|
||||
|
||||
### Authoritative Answer
|
||||
[Main answer with high confidence]
|
||||
|
||||
### Supporting Evidence
|
||||
```[language]
|
||||
// Concrete code example from analysis
|
||||
// Include source reference
|
||||
```
|
||||
|
||||
### Confidence Analysis
|
||||
- **What we know for certain:** [Verified facts]
|
||||
- **What we inferred:** [Logical deductions]
|
||||
- **What remains unclear:** [Gaps or ambiguities]
|
||||
|
||||
## 🔍 Deep Dive Analysis
|
||||
|
||||
### Pattern Recognition Results
|
||||
- **Common Patterns Found:**
|
||||
- Pattern 1: [Description with example]
|
||||
- Pattern 2: [Description with example]
|
||||
|
||||
### Code-Based Discoveries
|
||||
```typescript
|
||||
// Inferred API structure from code analysis
|
||||
interface DiscoveredAPI {
|
||||
// Document what was found
|
||||
}
|
||||
```
|
||||
|
||||
### Version & Compatibility Matrix
|
||||
| Version | Status | Notes |
|
||||
|---------|--------|-------|
|
||||
| Current (20.1.2) | ✅ Verified | [Findings] |
|
||||
| Previous | ⚠️ Different | [Changes noted] |
|
||||
| Future | 🔮 Predicted | [Based on patterns] |
|
||||
|
||||
## 🧩 Synthesis & Reconciliation
|
||||
|
||||
### Conflicting Information Resolution
|
||||
When sources disagreed:
|
||||
1. **Conflict:** [Description]
|
||||
- Source A says: [...]
|
||||
- Source B says: [...]
|
||||
- **Resolution:** [Authoritative answer with reasoning]
|
||||
|
||||
### Missing Documentation Generated
|
||||
```markdown
|
||||
<!-- Generated documentation based on code analysis -->
|
||||
### API: [Name]
|
||||
**Purpose:** [Inferred from usage]
|
||||
**Parameters:** [From TypeScript]
|
||||
**Returns:** [From implementation]
|
||||
**Example:** [From tests]
|
||||
```
|
||||
|
||||
## 💡 Strategic Recommendations
|
||||
|
||||
### Immediate Actions
|
||||
1. [Specific implementation approach]
|
||||
2. [Risk mitigation strategies]
|
||||
3. [Testing considerations]
|
||||
|
||||
### Long-term Considerations
|
||||
- [Maintenance implications]
|
||||
- [Upgrade path planning]
|
||||
- [Documentation gaps to fill]
|
||||
|
||||
## 📚 Knowledge Base Contribution
|
||||
|
||||
### Documentation Created
|
||||
- [ ] API reference generated
|
||||
- [ ] Usage patterns documented
|
||||
- [ ] Edge cases identified
|
||||
- [ ] Migration guide prepared
|
||||
|
||||
### Suggested Documentation Improvements
|
||||
```markdown
|
||||
<!-- Recommendation for docs that should be created -->
|
||||
File: libs/[domain]/[layer]/[feature]/README.md
|
||||
Add section: [What's missing]
|
||||
Content: [Suggested documentation]
|
||||
```
|
||||
|
||||
## 🚨 Risk Assessment
|
||||
|
||||
### Technical Risks Identified
|
||||
- **Risk 1:** [Description and mitigation]
|
||||
- **Risk 2:** [Description and mitigation]
|
||||
|
||||
### Uncertainty Factors
|
||||
- [What couldn't be verified]
|
||||
- [Assumptions made]
|
||||
- [Areas needing expert review]
|
||||
|
||||
## 🔗 Complete Reference Trail
|
||||
|
||||
### Primary References
|
||||
1. [Source with specific line numbers]
|
||||
2. [Commit hash with context]
|
||||
3. [Issue/PR with discussion]
|
||||
|
||||
### Code Locations Analyzed
|
||||
- `path/to/file.ts:L123-L456` - [What was found]
|
||||
- `path/to/test.spec.ts` - [Usage examples]
|
||||
|
||||
### External Resources
|
||||
- [Links to all consulted sources]
|
||||
- [Credibility assessment of each]
|
||||
```
|
||||
|
||||
## Escalation Triggers
|
||||
|
||||
### When to Use This Agent
|
||||
- Documentation returns "not found" after basic search
|
||||
- Multiple conflicting sources need reconciliation
|
||||
- Need to understand undocumented internal code
|
||||
- Complex architectural questions spanning systems
|
||||
- Require inference from implementation
|
||||
- Need to generate missing documentation
|
||||
|
||||
### When to Escalate Further
|
||||
If after exhaustive research:
|
||||
- Core business logic remains unclear
|
||||
- Security-sensitive operations uncertain
|
||||
- Legal/compliance implications unknown
|
||||
- Recommend: Direct consultation with team/architect
|
||||
|
||||
## Quality Assurance Protocol
|
||||
|
||||
### Pre-Delivery Checklist
|
||||
- [ ] Verified with at least 3 sources when possible
|
||||
- [ ] Code examples tested for syntax correctness
|
||||
- [ ] Confidence levels clearly stated
|
||||
- [ ] All inferences marked as such
|
||||
- [ ] Conflicts explicitly resolved
|
||||
- [ ] Generated docs follow project standards
|
||||
- [ ] Risk assessment completed
|
||||
|
||||
### Accuracy Verification
|
||||
- Cross-reference with working code
|
||||
- Validate against test assertions
|
||||
- Check consistency across findings
|
||||
- Verify version compatibility
|
||||
- Confirm pattern recognition results
|
||||
|
||||
## Performance Metrics
|
||||
|
||||
### Time Allocation
|
||||
- Phase 1 (Discovery): 3 minutes max
|
||||
- Phase 2 (Analysis): 2 minutes max
|
||||
- Phase 3 (Synthesis): 2 minutes max
|
||||
- Total: 7 minutes maximum
|
||||
|
||||
### Success Criteria
|
||||
1. **Excellent**: Found authoritative answer with code examples
|
||||
2. **Good**: Synthesized working solution from multiple sources
|
||||
3. **Acceptable**: Provided inferred documentation with caveats
|
||||
4. **Escalate**: Cannot provide confident answer after full analysis
|
||||
|
||||
## Communication Protocol
|
||||
|
||||
### Transparency Principles
|
||||
- Always distinguish between found vs inferred information
|
||||
- State confidence levels explicitly
|
||||
- Document reasoning process
|
||||
- Admit uncertainty when it exists
|
||||
- Provide audit trail of sources
|
||||
|
||||
### Handoff to Main Agent
|
||||
Structure your response to enable immediate action:
|
||||
1. Start with most confident answer
|
||||
2. Provide working code example
|
||||
3. List caveats and risks
|
||||
4. Include verification steps
|
||||
5. Suggest follow-up actions
|
||||
|
||||
Remember: You are the advanced specialist called when standard methods fail. Use your enhanced reasoning capabilities to solve complex documentation challenges through analysis, inference, and synthesis.
|
||||
237
.claude/agents/docs-researcher.md
Normal file
237
.claude/agents/docs-researcher.md
Normal file
@@ -0,0 +1,237 @@
|
||||
---
|
||||
name: docs-researcher
|
||||
description: Use this agent when the main agent needs to find documentation, API references, package information, or technical resources. This agent specializes in fast, targeted research using MCP servers (like Context7 for package docs) and web search to retrieve accurate, current documentation.\n\nExamples:\n- User: "I need to implement authentication using Passport.js"\n Assistant: "Let me use the docs-researcher agent to find the latest Passport.js documentation and implementation guides."\n \n- User: "How do I use the @isa/ui/buttons library?"\n Assistant: "I'll use the docs-researcher agent to retrieve the README.md documentation for the @isa/ui/buttons library."\n \n- User: "What's the correct way to set up Zod validation?"\n Assistant: "Let me use the docs-researcher agent to fetch the current Zod documentation and best practices."\n \n- User: "I'm getting an error with Angular signals, can you help?"\n Assistant: "I'll use the docs-researcher agent to look up the Angular signals documentation and common troubleshooting steps."\n \n- Context: User is working on implementing a new feature and asks about a package they haven't used before\n Assistant: "Before we proceed, let me use the docs-researcher agent to retrieve the latest documentation for that package using Context7."\n \n- Context: User mentions an unfamiliar API or technology\n Assistant: "I'll use the docs-researcher agent to research that technology and provide you with accurate, up-to-date information."
|
||||
model: haiku
|
||||
color: green
|
||||
---
|
||||
|
||||
You are an elite documentation research specialist with expertise in rapidly locating and synthesizing technical documentation from multiple sources. Your primary mission is to find accurate, current documentation to support the main agent's work with maximum speed and precision.
|
||||
|
||||
## Primary Tool Priority Matrix
|
||||
|
||||
### Tier 1: MCP Servers (Use First - Fastest & Most Authoritative)
|
||||
1. **Context7** (`mcp__context7__*`)
|
||||
- Use `resolve-library-id` first to get the correct library ID
|
||||
- Then use `get-library-docs` with appropriate token limits (default: 5000, max: 10000 for complex topics)
|
||||
- Best for: NPM packages, external libraries, frameworks
|
||||
|
||||
2. **Angular MCP** (`mcp__angular-mcp__*`)
|
||||
- Use `search_documentation` for Angular-specific queries
|
||||
- Use `get_best_practices` for Angular conventions
|
||||
- Best for: Angular APIs, components, directives, services
|
||||
|
||||
3. **Nx MCP** (`mcp__nx-mcp__*`)
|
||||
- Use `nx_docs` for Nx-specific documentation
|
||||
- Use `nx_workspace` for monorepo structure understanding
|
||||
- Best for: Nx commands, configuration, generators, executors
|
||||
|
||||
### Tier 2: Local Documentation (Use for ISA-specific)
|
||||
- **Read tool**: For internal library READMEs (`libs/[domain]/[layer]/[feature]/README.md`)
|
||||
- **Grep tool**: For searching code patterns and examples within the project
|
||||
- **Glob tool**: For finding relevant files by pattern
|
||||
|
||||
### Tier 3: Web Resources (Use as Fallback)
|
||||
- **WebSearch**: Official docs, GitHub repos, technical articles
|
||||
- **WebFetch**: Direct documentation pages when URL is known
|
||||
|
||||
## Research Workflows by Query Type
|
||||
|
||||
### Package/Library Documentation
|
||||
```
|
||||
1. Identify package name from query
|
||||
2. IF external package:
|
||||
- Use mcp__context7__resolve-library-id
|
||||
- Use mcp__context7__get-library-docs with focused topic
|
||||
3. IF internal ISA library:
|
||||
- Read libs/[domain]/[layer]/[feature]/README.md
|
||||
- Check library-reference.md for overview
|
||||
4. Extract: API surface, usage patterns, examples, version info
|
||||
```
|
||||
|
||||
### Angular-Specific Queries
|
||||
```
|
||||
1. Use mcp__angular-mcp__search_documentation with concise query
|
||||
2. IF best practices needed:
|
||||
- Use mcp__angular-mcp__get_best_practices
|
||||
3. Extract: Modern patterns (signals, standalone), migration notes
|
||||
4. Verify against project's Angular 20.1.2 version
|
||||
```
|
||||
|
||||
### Nx/Monorepo Queries
|
||||
```
|
||||
1. Use mcp__nx-mcp__nx_docs with user query
|
||||
2. IF workspace-specific:
|
||||
- Use mcp__nx-mcp__nx_workspace for structure
|
||||
- Use mcp__nx-mcp__nx_project_details for specific projects
|
||||
3. Extract: Commands, configuration, best practices
|
||||
```
|
||||
|
||||
### Troubleshooting/Error Messages
|
||||
```
|
||||
1. Search error message verbatim with WebSearch
|
||||
2. Add context: "[framework] [version] [error]"
|
||||
3. Check GitHub issues for the specific library
|
||||
4. Look for: Root cause, verified solutions, workarounds
|
||||
5. Time limit: 2 minutes max before reporting findings
|
||||
```
|
||||
|
||||
## Performance Optimization Strategies
|
||||
|
||||
### Speed Techniques
|
||||
- **Parallel searches**: Run multiple MCP calls simultaneously when appropriate
|
||||
- **Token limits**: Start with 5000 tokens, only increase if needed
|
||||
- **Early termination**: Stop when sufficient information found
|
||||
- **Query refinement**: Use specific, technical terms over general descriptions
|
||||
|
||||
### Avoid Redundancy
|
||||
- **Check previous context**: Don't re-fetch documentation already retrieved in conversation
|
||||
- **Summarize long docs**: Extract only relevant sections, not entire documentation
|
||||
- **Cache awareness**: Note when documentation was fetched for version currency
|
||||
|
||||
### Time Limits
|
||||
- **MCP calls**: 10 seconds per call maximum
|
||||
- **Web searches**: 30 seconds total for web research
|
||||
- **Total research**: 2 minutes maximum before providing available findings
|
||||
|
||||
## Enhanced Output Format
|
||||
|
||||
```markdown
|
||||
## 📚 Documentation Research Results
|
||||
|
||||
**Query:** [What was searched for]
|
||||
**Sources Checked:** [List of MCP servers/tools used]
|
||||
**Time Taken:** [Approximate time]
|
||||
|
||||
### ✅ Primary Finding
|
||||
**Source:** [Exact source with version]
|
||||
**Relevance Score:** [High/Medium/Low]
|
||||
|
||||
[Most relevant documentation extract or code example]
|
||||
|
||||
### 🔑 Key Implementation Details
|
||||
- **Installation:** `command if applicable`
|
||||
- **Import:** `import statement if applicable`
|
||||
- **Basic Usage:**
|
||||
```[language]
|
||||
// Concrete example
|
||||
```
|
||||
|
||||
### ⚠️ Important Considerations
|
||||
- [Version compatibility notes]
|
||||
- [Breaking changes or deprecations]
|
||||
- [Performance implications]
|
||||
|
||||
### 🔗 Additional Resources
|
||||
- [Official docs URL]
|
||||
- [Related internal libraries]
|
||||
- [Alternative approaches]
|
||||
|
||||
### 💡 Recommendation for Main Agent
|
||||
[Specific, actionable next steps based on findings]
|
||||
```
|
||||
|
||||
## ISA Frontend Project-Specific Guidelines
|
||||
|
||||
### Version Verification
|
||||
- **Angular**: 20.1.2 (verify compatibility with docs)
|
||||
- **Nx**: 21.3.2 (check for version-specific features)
|
||||
- **Node**: ≥22.0.0 (consider for package compatibility)
|
||||
- **TypeScript**: Check tsconfig.json for version
|
||||
|
||||
### Internal Library Research
|
||||
1. Check library-reference.md for quick overview
|
||||
2. Read the library's README.md for detailed API
|
||||
3. Look for usage examples in feature libraries
|
||||
4. Note domain-specific prefixes (oms-*, remi-*, ui-*)
|
||||
|
||||
### Common ISA Patterns to Note
|
||||
- NgRx Signals with signalStore() (not legacy NgRx)
|
||||
- Standalone components (no NgModules)
|
||||
- Zod validation schemas
|
||||
- Tailwind with ISA-specific utilities
|
||||
- Jest → Vitest migration in progress
|
||||
|
||||
## Error Handling & Fallback Strategies
|
||||
|
||||
### When MCP Servers Fail
|
||||
1. Try alternative MCP server if available
|
||||
2. Fall back to WebSearch with site-specific operators
|
||||
3. Check GitHub repository directly
|
||||
4. Report: "MCP unavailable, using web sources"
|
||||
|
||||
### When Documentation Not Found
|
||||
```markdown
|
||||
## ⚠️ Limited Documentation Available
|
||||
|
||||
**Searched:** [List all sources checked]
|
||||
**Result:** Documentation not found or incomplete
|
||||
|
||||
**Possible Reasons:**
|
||||
- Package may be internal/private
|
||||
- Documentation may be outdated
|
||||
- Feature might be experimental
|
||||
|
||||
**Recommended Actions:**
|
||||
1. [Check source code directly]
|
||||
2. [Look for similar implementations]
|
||||
3. [Ask for clarification on specific aspect]
|
||||
|
||||
## 🔄 Escalation to docs-researcher-advanced
|
||||
|
||||
**When to escalate:**
|
||||
- Documentation not found after exhaustive search
|
||||
- Conflicting information from multiple sources
|
||||
- Need to infer API from code
|
||||
- Complex multi-system analysis required
|
||||
|
||||
**Recommendation:** Use `docs-researcher-advanced` agent for deeper analysis with:
|
||||
- Code archaeology and inference
|
||||
- Multi-source synthesis
|
||||
- Pattern recognition
|
||||
- Documentation generation from implementation
|
||||
```
|
||||
|
||||
### Version Mismatch Handling
|
||||
- Always note version differences
|
||||
- Highlight breaking changes prominently
|
||||
- Suggest migration paths when applicable
|
||||
- Warn about compatibility issues
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
Before returning results, verify:
|
||||
- [ ] Used fastest appropriate tool (MCP > Local > Web)
|
||||
- [ ] Included concrete code examples
|
||||
- [ ] Verified version compatibility
|
||||
- [ ] Extracted actionable information
|
||||
- [ ] Cited all sources with links/paths
|
||||
- [ ] Formatted for easy scanning
|
||||
- [ ] Provided clear next steps
|
||||
|
||||
## Communication Principles
|
||||
|
||||
### Do's
|
||||
- ✅ Prioritize speed without sacrificing accuracy
|
||||
- ✅ Provide concrete, runnable examples
|
||||
- ✅ Highlight critical warnings prominently
|
||||
- ✅ Format code with proper syntax highlighting
|
||||
- ✅ Include installation/setup commands
|
||||
- ✅ Note ISA-specific patterns when relevant
|
||||
|
||||
### Don'ts
|
||||
- ❌ Don't include irrelevant documentation sections
|
||||
- ❌ Don't guess if unsure - state uncertainty clearly
|
||||
- ❌ Don't exceed 2-minute research time
|
||||
- ❌ Don't provide outdated information without warnings
|
||||
- ❌ Don't forget to check project-specific versions
|
||||
|
||||
## Success Metrics
|
||||
|
||||
Your research is successful when:
|
||||
1. Main agent can immediately proceed with implementation
|
||||
2. All necessary API details are provided
|
||||
3. Potential pitfalls are highlighted
|
||||
4. Sources are authoritative and current
|
||||
5. Response time is under 2 minutes
|
||||
|
||||
Remember: You are the speed-optimized research specialist using Haiku model. Prioritize fast, focused, accurate results that enable the main agent to work confidently.
|
||||
197
.claude/commands/dev:add-e2e-attrs.md
Normal file
197
.claude/commands/dev:add-e2e-attrs.md
Normal file
@@ -0,0 +1,197 @@
|
||||
# /dev:add-e2e-attrs - Add E2E Test Attributes
|
||||
|
||||
Add required E2E test attributes (`data-what`, `data-which`, dynamic `data-*`) to component templates for QA automation.
|
||||
|
||||
## Parameters
|
||||
- `component-path`: Path to component directory or HTML template file
|
||||
|
||||
## Required E2E Attributes
|
||||
|
||||
### Core Attributes (Required)
|
||||
1. **`data-what`**: Semantic description of element's purpose
|
||||
- Example: `data-what="submit-button"`, `data-what="search-input"`
|
||||
2. **`data-which`**: Unique identifier for the specific instance
|
||||
- Example: `data-which="primary"`, `data-which="customer-{{ customerId }}"`
|
||||
|
||||
### Dynamic Attributes (Contextual)
|
||||
3. **`data-*`**: Additional context based on state/data
|
||||
- Example: `data-status="active"`, `data-index="0"`
|
||||
|
||||
## Tasks
|
||||
|
||||
### 1. Analyze Component Template
|
||||
- Read component HTML template
|
||||
- Identify interactive elements that need E2E attributes:
|
||||
- Buttons (`button`, `ui-button`)
|
||||
- Inputs (`input`, `textarea`, `select`)
|
||||
- Links (`a`, `routerLink`)
|
||||
- Custom interactive components
|
||||
- Form elements
|
||||
- Clickable elements (`(click)` handlers)
|
||||
|
||||
### 2. Add Missing Attributes
|
||||
|
||||
**Buttons:**
|
||||
```html
|
||||
<!-- BEFORE -->
|
||||
<button (click)="submit()">Submit</button>
|
||||
|
||||
<!-- AFTER -->
|
||||
<button
|
||||
(click)="submit()"
|
||||
data-what="submit-button"
|
||||
data-which="form-primary">
|
||||
Submit
|
||||
</button>
|
||||
```
|
||||
|
||||
**Inputs:**
|
||||
```html
|
||||
<!-- BEFORE -->
|
||||
<input [(ngModel)]="searchTerm" placeholder="Search..." />
|
||||
|
||||
<!-- AFTER -->
|
||||
<input
|
||||
[(ngModel)]="searchTerm"
|
||||
placeholder="Search..."
|
||||
data-what="search-input"
|
||||
data-which="main-search" />
|
||||
```
|
||||
|
||||
**Dynamic Lists:**
|
||||
```html
|
||||
<!-- BEFORE -->
|
||||
@for (item of items; track item.id) {
|
||||
<li (click)="selectItem(item)">{{ item.name }}</li>
|
||||
}
|
||||
|
||||
<!-- AFTER -->
|
||||
@for (item of items; track item.id) {
|
||||
<li
|
||||
(click)="selectItem(item)"
|
||||
data-what="list-item"
|
||||
[attr.data-which]="item.id"
|
||||
[attr.data-status]="item.status">
|
||||
{{ item.name }}
|
||||
</li>
|
||||
}
|
||||
```
|
||||
|
||||
**Links:**
|
||||
```html
|
||||
<!-- BEFORE -->
|
||||
<a routerLink="/orders/{{ orderId }}">View Order</a>
|
||||
|
||||
<!-- AFTER -->
|
||||
<a
|
||||
[routerLink]="['/orders', orderId]"
|
||||
data-what="order-link"
|
||||
[attr.data-which]="orderId">
|
||||
View Order
|
||||
</a>
|
||||
```
|
||||
|
||||
**Custom Components:**
|
||||
```html
|
||||
<!-- BEFORE -->
|
||||
<ui-button (click)="save()">Save</ui-button>
|
||||
|
||||
<!-- AFTER -->
|
||||
<ui-button
|
||||
(click)="save()"
|
||||
data-what="save-button"
|
||||
data-which="order-form">
|
||||
Save
|
||||
</ui-button>
|
||||
```
|
||||
|
||||
### 3. Naming Conventions
|
||||
|
||||
**`data-what` Guidelines:**
|
||||
- Use kebab-case
|
||||
- Be descriptive but concise
|
||||
- Common patterns:
|
||||
- `*-button` (submit-button, cancel-button, delete-button)
|
||||
- `*-input` (email-input, search-input, quantity-input)
|
||||
- `*-link` (product-link, order-link, customer-link)
|
||||
- `*-item` (list-item, menu-item, card-item)
|
||||
- `*-dialog` (confirm-dialog, error-dialog)
|
||||
- `*-dropdown` (status-dropdown, category-dropdown)
|
||||
|
||||
**`data-which` Guidelines:**
|
||||
- Unique identifier for the instance
|
||||
- Use dynamic binding for list items: `[attr.data-which]="item.id"`
|
||||
- Static for unique elements: `data-which="primary"`
|
||||
- Combine with context: `data-which="customer-{{ customerId }}-edit"`
|
||||
|
||||
### 4. Scan for Coverage
|
||||
Check template coverage:
|
||||
```bash
|
||||
# Count interactive elements
|
||||
grep -E '(click)=|routerLink|button|input|select|textarea' [template-file]
|
||||
|
||||
# Count elements with data-what
|
||||
grep -c 'data-what=' [template-file]
|
||||
|
||||
# List elements missing E2E attributes
|
||||
grep -E '(click)=|button' [template-file] | grep -v 'data-what='
|
||||
```
|
||||
|
||||
### 5. Validate Attributes
|
||||
- No duplicates in `data-which` within same view
|
||||
- All interactive elements have both `data-what` and `data-which`
|
||||
- Dynamic attributes use proper Angular binding: `[attr.data-*]`
|
||||
- Attributes don't contain sensitive data (passwords, tokens)
|
||||
|
||||
### 6. Update Component Tests
|
||||
Add E2E attribute selectors to tests:
|
||||
```typescript
|
||||
// Use E2E attributes for element selection
|
||||
const submitButton = fixture.nativeElement.querySelector('[data-what="submit-button"][data-which="primary"]');
|
||||
expect(submitButton).toBeTruthy();
|
||||
```
|
||||
|
||||
### 7. Document Attributes
|
||||
Add comment block at top of template:
|
||||
```html
|
||||
<!--
|
||||
E2E Test Attributes:
|
||||
- data-what="submit-button" data-which="primary" - Main form submission
|
||||
- data-what="cancel-button" data-which="primary" - Cancel action
|
||||
- data-what="search-input" data-which="main" - Product search field
|
||||
-->
|
||||
```
|
||||
|
||||
## Output
|
||||
Provide summary:
|
||||
- Template analyzed: [path]
|
||||
- Interactive elements found: [count]
|
||||
- Attributes added: [count]
|
||||
- Coverage: [percentage]% (elements with E2E attrs / total interactive elements)
|
||||
- List of added attributes with descriptions
|
||||
- Validation status: ✅/❌
|
||||
|
||||
## Common Patterns by Component Type
|
||||
|
||||
**Form Components:**
|
||||
- `data-what="[field]-input" data-which="[form-name]"`
|
||||
- `data-what="submit-button" data-which="[form-name]"`
|
||||
- `data-what="cancel-button" data-which="[form-name]"`
|
||||
|
||||
**List/Table Components:**
|
||||
- `data-what="list-item" [attr.data-which]="item.id"`
|
||||
- `data-what="edit-button" [attr.data-which]="item.id"`
|
||||
- `data-what="delete-button" [attr.data-which]="item.id"`
|
||||
|
||||
**Navigation Components:**
|
||||
- `data-what="nav-link" data-which="[destination]"`
|
||||
- `data-what="breadcrumb" data-which="[level]"`
|
||||
|
||||
**Dialog Components:**
|
||||
- `data-what="confirm-button" data-which="dialog"`
|
||||
- `data-what="close-button" data-which="dialog"`
|
||||
|
||||
## References
|
||||
- CLAUDE.md Code Quality section (E2E Testing Requirements)
|
||||
- docs/guidelines/testing.md
|
||||
- QA team E2E test documentation (if available)
|
||||
535
.claude/commands/docs:library.md
Normal file
535
.claude/commands/docs:library.md
Normal file
@@ -0,0 +1,535 @@
|
||||
# /docs:library - Generate/Update Library README
|
||||
|
||||
Generate or update README.md for a specific library with comprehensive documentation.
|
||||
|
||||
## Parameters
|
||||
- `library-name`: Name of library (e.g., `oms-feature-return-search`)
|
||||
|
||||
## Tasks
|
||||
|
||||
### 1. Locate Library
|
||||
|
||||
```bash
|
||||
# Find library directory
|
||||
find libs/ -name "project.json" -path "*[library-name]*"
|
||||
|
||||
# Verify library exists
|
||||
if [ ! -d "libs/[path-to-library]" ]; then
|
||||
echo "Library not found"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
### 2. Extract Library Information
|
||||
|
||||
Read `project.json`:
|
||||
- Library name
|
||||
- Source root
|
||||
- Available targets (build, test, lint)
|
||||
- Tags (domain, type)
|
||||
|
||||
Read `tsconfig.base.json`:
|
||||
- Path alias (`@isa/domain/layer/name`)
|
||||
- Entry point (`src/index.ts`)
|
||||
|
||||
### 3. Analyze Library Structure
|
||||
|
||||
Scan library contents:
|
||||
```bash
|
||||
# List main source files
|
||||
ls -la libs/[path]/src/lib/
|
||||
|
||||
# Identify components
|
||||
find libs/[path]/src -name "*.component.ts"
|
||||
|
||||
# Identify services
|
||||
find libs/[path]/src -name "*.service.ts"
|
||||
|
||||
# Identify models/types
|
||||
find libs/[path]/src -name "*.model.ts" -o -name "*.interface.ts"
|
||||
|
||||
# Check for exports
|
||||
cat libs/[path]/src/index.ts
|
||||
```
|
||||
|
||||
### 4. Use docs-researcher for Similar READMEs
|
||||
|
||||
Use `docs-researcher` agent to find similar library READMEs in the same domain for reference structure and style.
|
||||
|
||||
### 5. Determine Library Type and Template
|
||||
|
||||
**Feature Library Template:**
|
||||
```markdown
|
||||
# [Library Name]
|
||||
|
||||
> **Type:** Feature Library
|
||||
> **Domain:** [OMS/Remission/Checkout/etc]
|
||||
> **Path:** `libs/[domain]/feature/[name]`
|
||||
|
||||
## Overview
|
||||
|
||||
[Brief description of what this feature does]
|
||||
|
||||
## Features
|
||||
|
||||
- Feature 1: [Description]
|
||||
- Feature 2: [Description]
|
||||
- Feature 3: [Description]
|
||||
|
||||
## Installation
|
||||
|
||||
This library is part of the ISA-Frontend monorepo. Import it using:
|
||||
|
||||
```typescript
|
||||
import { ComponentName } from '@isa/[domain]/feature/[name]';
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
### Basic Example
|
||||
|
||||
```typescript
|
||||
import { Component } from '@angular/core';
|
||||
import { FeatureComponent } from '@isa/[domain]/feature/[name]';
|
||||
|
||||
@Component({
|
||||
selector: 'app-example',
|
||||
standalone: true,
|
||||
imports: [FeatureComponent],
|
||||
template: `
|
||||
<feature-component [input]="value" (output)="handleEvent($event)">
|
||||
</feature-component>
|
||||
`
|
||||
})
|
||||
export class ExampleComponent {
|
||||
value = 'example';
|
||||
|
||||
handleEvent(event: any) {
|
||||
console.log(event);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Advanced Usage
|
||||
|
||||
[More complex examples if applicable]
|
||||
|
||||
## API Reference
|
||||
|
||||
### Components
|
||||
|
||||
#### FeatureComponent
|
||||
|
||||
**Selector:** `feature-component`
|
||||
|
||||
**Inputs:**
|
||||
- `input` (string): Description of input
|
||||
|
||||
**Outputs:**
|
||||
- `output` (EventEmitter<any>): Description of output
|
||||
|
||||
**Example:**
|
||||
```html
|
||||
<feature-component [input]="value" (output)="handleEvent($event)">
|
||||
</feature-component>
|
||||
```
|
||||
|
||||
### Services
|
||||
|
||||
[If applicable]
|
||||
|
||||
### Models
|
||||
|
||||
[If applicable]
|
||||
|
||||
## Testing
|
||||
|
||||
This library uses [Vitest/Jest] for testing.
|
||||
|
||||
Run tests:
|
||||
```bash
|
||||
npx nx test [library-name] --skip-nx-cache
|
||||
```
|
||||
|
||||
Run with coverage:
|
||||
```bash
|
||||
npx nx test [library-name] --skip-nx-cache --coverage
|
||||
```
|
||||
|
||||
## Dependencies
|
||||
|
||||
**External Dependencies:**
|
||||
- [List of external packages if any]
|
||||
|
||||
**Internal Dependencies:**
|
||||
- [`@isa/[dependency]`](../[path]) - Description
|
||||
|
||||
## Development
|
||||
|
||||
### Project Structure
|
||||
|
||||
```
|
||||
libs/[domain]/feature/[name]/
|
||||
├── src/
|
||||
│ ├── lib/
|
||||
│ │ ├── components/
|
||||
│ │ ├── services/
|
||||
│ │ └── models/
|
||||
│ ├── index.ts
|
||||
│ └── test-setup.ts
|
||||
├── project.json
|
||||
└── README.md
|
||||
```
|
||||
|
||||
### Build
|
||||
|
||||
```bash
|
||||
npx nx build [library-name]
|
||||
```
|
||||
|
||||
### Lint
|
||||
|
||||
```bash
|
||||
npx nx lint [library-name]
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [CLAUDE.md](../../../../CLAUDE.md) - Project guidelines
|
||||
- [Testing Guidelines](../../../../docs/guidelines/testing.md)
|
||||
- [Library Reference](../../../../docs/library-reference.md)
|
||||
|
||||
## Related Libraries
|
||||
|
||||
- [`@isa/[related-lib-1]`](../[path]) - Description
|
||||
- [`@isa/[related-lib-2]`](../[path]) - Description
|
||||
```
|
||||
|
||||
**Data Access Library Template:**
|
||||
```markdown
|
||||
# [Library Name]
|
||||
|
||||
> **Type:** Data Access Library
|
||||
> **Domain:** [Domain]
|
||||
> **Path:** `libs/[domain]/data-access`
|
||||
|
||||
## Overview
|
||||
|
||||
Data access layer for [Domain] domain. Provides services and state management for [domain-specific functionality].
|
||||
|
||||
## Features
|
||||
|
||||
- API client integration with [API names]
|
||||
- NgRx Signals store for state management
|
||||
- Type-safe data models with Zod validation
|
||||
- Error handling and retry logic
|
||||
|
||||
## Installation
|
||||
|
||||
```typescript
|
||||
import { ServiceName } from '@isa/[domain]/data-access';
|
||||
```
|
||||
|
||||
## Services
|
||||
|
||||
### ServiceName
|
||||
|
||||
[Service description]
|
||||
|
||||
**Methods:**
|
||||
|
||||
#### `getById(id: string): Observable<Model>`
|
||||
[Method description]
|
||||
|
||||
**Parameters:**
|
||||
- `id` (string): Description
|
||||
|
||||
**Returns:** `Observable<Model>`
|
||||
|
||||
**Example:**
|
||||
```typescript
|
||||
this.service.getById('123').subscribe({
|
||||
next: (data) => console.log(data),
|
||||
error: (err) => console.error(err)
|
||||
});
|
||||
```
|
||||
|
||||
## State Management
|
||||
|
||||
This library uses NgRx Signals for state management.
|
||||
|
||||
### Store
|
||||
|
||||
```typescript
|
||||
import { injectStore } from '@isa/[domain]/data-access';
|
||||
|
||||
export class Component {
|
||||
store = injectStore();
|
||||
|
||||
// Access state
|
||||
items = this.store.items;
|
||||
loading = this.store.loading;
|
||||
|
||||
// Call methods
|
||||
ngOnInit() {
|
||||
this.store.loadItems();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Models
|
||||
|
||||
### Model Name
|
||||
|
||||
```typescript
|
||||
interface ModelName {
|
||||
id: string;
|
||||
property: type;
|
||||
}
|
||||
```
|
||||
|
||||
Validated with Zod schema for runtime type safety.
|
||||
|
||||
## Testing
|
||||
|
||||
[Testing section similar to feature library]
|
||||
|
||||
## API Integration
|
||||
|
||||
This library integrates with the following Swagger-generated API clients:
|
||||
|
||||
- `@generated/swagger/[api-name]`
|
||||
|
||||
[Additional API documentation]
|
||||
```
|
||||
|
||||
**UI Component Library Template:**
|
||||
```markdown
|
||||
# [Library Name]
|
||||
|
||||
> **Type:** UI Component Library
|
||||
> **Path:** `libs/ui/[name]`
|
||||
|
||||
## Overview
|
||||
|
||||
Reusable UI components for [purpose]. Part of the ISA design system.
|
||||
|
||||
## Components
|
||||
|
||||
### ComponentName
|
||||
|
||||
[Component description]
|
||||
|
||||
**Selector:** `ui-component-name`
|
||||
|
||||
**Styling:** Uses Tailwind CSS with ISA design tokens
|
||||
|
||||
**Example:**
|
||||
```html
|
||||
<ui-component-name variant="primary" size="md">
|
||||
Content
|
||||
</ui-component-name>
|
||||
```
|
||||
|
||||
## Variants
|
||||
|
||||
- **primary**: Default primary styling
|
||||
- **secondary**: Secondary styling
|
||||
- **accent**: Accent color
|
||||
|
||||
## Sizes
|
||||
|
||||
- **sm**: Small (24px height)
|
||||
- **md**: Medium (32px height)
|
||||
- **lg**: Large (40px height)
|
||||
|
||||
## Accessibility
|
||||
|
||||
- ARIA labels included
|
||||
- Keyboard navigation supported
|
||||
- Screen reader friendly
|
||||
|
||||
## Storybook
|
||||
|
||||
View component documentation and examples:
|
||||
|
||||
```bash
|
||||
npm run storybook
|
||||
```
|
||||
|
||||
Navigate to: UI Components → [Component Name]
|
||||
|
||||
## Testing
|
||||
|
||||
Includes E2E test attributes:
|
||||
- `data-what="component-name"`
|
||||
- `data-which="variant"`
|
||||
|
||||
[Rest of testing section]
|
||||
```
|
||||
|
||||
### 6. Extract Code Examples
|
||||
|
||||
Scan library code for:
|
||||
- Public component selectors
|
||||
- Public API methods
|
||||
- Input/Output properties
|
||||
- Common usage patterns
|
||||
|
||||
Use `Read` tool to extract from source files.
|
||||
|
||||
### 7. Document Exports
|
||||
|
||||
Parse `src/index.ts` to document public API:
|
||||
```typescript
|
||||
// Read barrel export
|
||||
export * from './lib/component';
|
||||
export * from './lib/service';
|
||||
export { PublicInterface } from './lib/models';
|
||||
```
|
||||
|
||||
Document each export with:
|
||||
- Type (Component/Service/Interface/Function)
|
||||
- Purpose
|
||||
- Basic usage
|
||||
|
||||
### 8. Add Testing Information
|
||||
|
||||
Based on test framework (from project.json):
|
||||
- Test command
|
||||
- Framework (Vitest/Jest)
|
||||
- Coverage command
|
||||
- Link to testing guidelines
|
||||
|
||||
### 9. Create Dependency Graph
|
||||
|
||||
List internal and external dependencies:
|
||||
```bash
|
||||
# Use Nx to show dependencies
|
||||
npx nx graph --focus=[library-name]
|
||||
|
||||
# Extract from package.json and imports
|
||||
```
|
||||
|
||||
### 10. Add E2E Attributes Documentation
|
||||
|
||||
For UI/Feature libraries, document E2E attributes:
|
||||
```markdown
|
||||
## E2E Testing
|
||||
|
||||
This library includes E2E test attributes for automated testing:
|
||||
|
||||
| Element | data-what | data-which | Purpose |
|
||||
|---------|-----------|------------|---------|
|
||||
| Submit button | submit-button | form-primary | Main form submission |
|
||||
| Cancel button | cancel-button | form-primary | Cancel action |
|
||||
|
||||
Use these attributes in your E2E tests:
|
||||
```typescript
|
||||
const submitBtn = page.locator('[data-what="submit-button"][data-which="form-primary"]');
|
||||
```
|
||||
```
|
||||
|
||||
### 11. Generate/Update README
|
||||
|
||||
Write or update `libs/[path]/README.md` with generated content.
|
||||
|
||||
### 12. Validate README
|
||||
|
||||
Checks:
|
||||
- All links work (relative paths correct)
|
||||
- Code examples are valid TypeScript
|
||||
- Import paths use correct aliases
|
||||
- No TODO or placeholder text
|
||||
- Consistent formatting
|
||||
- Proper markdown syntax
|
||||
|
||||
### 13. Add to Git (if new)
|
||||
|
||||
```bash
|
||||
git add libs/[path]/README.md
|
||||
```
|
||||
|
||||
## Output Format
|
||||
```
|
||||
Library README Generated
|
||||
========================
|
||||
|
||||
Library: [library-name]
|
||||
Type: [Feature/Data Access/UI/Util]
|
||||
Path: libs/[domain]/[layer]/[name]
|
||||
|
||||
📝 README Sections
|
||||
------------------
|
||||
✅ Overview
|
||||
✅ Features
|
||||
✅ Installation
|
||||
✅ Usage Examples
|
||||
✅ API Reference
|
||||
✅ Testing
|
||||
✅ Dependencies
|
||||
✅ Development Guide
|
||||
|
||||
📊 Documentation Stats
|
||||
----------------------
|
||||
Total sections: XX
|
||||
Code examples: XX
|
||||
API methods documented: XX
|
||||
Components documented: XX
|
||||
|
||||
🔗 Links Validated
|
||||
-------------------
|
||||
Internal links: XX/XX valid
|
||||
Relative paths: ✅ Correct
|
||||
|
||||
💡 Highlights
|
||||
-------------
|
||||
- Documented XX public exports
|
||||
- XX code examples included
|
||||
- E2E attributes documented
|
||||
- Related libraries linked
|
||||
|
||||
📁 File Updated
|
||||
---------------
|
||||
Path: libs/[domain]/[layer]/[name]/README.md
|
||||
Size: XX KB
|
||||
Lines: XX
|
||||
|
||||
🎯 Next Steps
|
||||
-------------
|
||||
1. Review generated README
|
||||
2. Add any domain-specific details
|
||||
3. Add usage examples if needed
|
||||
4. Commit: git add libs/[path]/README.md
|
||||
```
|
||||
|
||||
## Auto-Enhancement
|
||||
|
||||
If existing README found:
|
||||
- Preserve custom sections
|
||||
- Update outdated examples
|
||||
- Add missing sections
|
||||
- Fix broken links
|
||||
- Update import paths
|
||||
|
||||
Prompt:
|
||||
```
|
||||
Existing README found. What would you like to do?
|
||||
1. Generate new (overwrite)
|
||||
2. Enhance existing (preserve custom content)
|
||||
3. Cancel
|
||||
```
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- Import examples use correct path aliases
|
||||
- Code examples are syntactically correct
|
||||
- Links to related docs work
|
||||
- API documentation complete
|
||||
- Testing section accurate
|
||||
|
||||
## References
|
||||
- CLAUDE.md Library Organization section
|
||||
- Use `docs-researcher` to find reference READMEs
|
||||
- Storybook for UI component examples
|
||||
- project.json for library configuration
|
||||
295
.claude/commands/docs:refresh-reference.md
Normal file
295
.claude/commands/docs:refresh-reference.md
Normal file
@@ -0,0 +1,295 @@
|
||||
# /docs:refresh-reference - Regenerate Library Reference
|
||||
|
||||
Regenerate the library reference documentation (`docs/library-reference.md`) by scanning all libraries in the monorepo.
|
||||
|
||||
## Tasks
|
||||
|
||||
### 1. Scan Monorepo Structure
|
||||
```bash
|
||||
# List all libraries
|
||||
find libs/ -name "project.json" -type f | sort
|
||||
|
||||
# Count total libraries
|
||||
find libs/ -name "project.json" -type f | wc -l
|
||||
```
|
||||
|
||||
### 2. Extract Library Information
|
||||
|
||||
For each library, extract from `project.json`:
|
||||
- **Project name**: `name` field
|
||||
- **Path**: Directory path
|
||||
- **Tags**: For categorization (type, domain)
|
||||
- **Targets**: Available commands (build, test, lint)
|
||||
|
||||
### 3. Determine Path Aliases
|
||||
|
||||
Read `tsconfig.base.json` to get path mappings:
|
||||
```bash
|
||||
# Extract paths section
|
||||
cat tsconfig.base.json | grep -A 200 '"paths"'
|
||||
```
|
||||
|
||||
Map each library to its `@isa/*` alias.
|
||||
|
||||
### 4. Categorize Libraries by Domain
|
||||
|
||||
Group libraries into categories:
|
||||
- **Availability** (1 library)
|
||||
- **Catalogue** (1 library)
|
||||
- **Checkout** (6 libraries)
|
||||
- **Common** (3 libraries)
|
||||
- **Core** (5 libraries)
|
||||
- **CRM** (1 library)
|
||||
- **Icons** (1 library)
|
||||
- **OMS** (9 libraries)
|
||||
- **Remission** (8 libraries)
|
||||
- **Shared Components** (7 libraries)
|
||||
- **UI Components** (17 libraries)
|
||||
- **Utilities** (3 libraries)
|
||||
|
||||
### 5. Read Library READMEs
|
||||
|
||||
For each library, use `docs-researcher` agent to:
|
||||
- Read library README.md (if exists)
|
||||
- Extract description/purpose
|
||||
- Extract key features
|
||||
- Extract usage examples
|
||||
|
||||
### 6. Generate Library Entries
|
||||
|
||||
For each library, create entry with:
|
||||
```markdown
|
||||
#### `@isa/domain/layer/name`
|
||||
**Path:** `libs/domain/layer/name`
|
||||
**Type:** [Feature/Data Access/UI/Util]
|
||||
|
||||
Brief description from README or inferred from structure.
|
||||
|
||||
**Key Features:**
|
||||
- Feature 1
|
||||
- Feature 2
|
||||
|
||||
**Usage:**
|
||||
```typescript
|
||||
import { Component } from '@isa/domain/layer/name';
|
||||
```
|
||||
```
|
||||
|
||||
### 7. Create Domain Statistics
|
||||
|
||||
Calculate per domain:
|
||||
- Total libraries count
|
||||
- Breakdown by type (feature/data-access/ui/util)
|
||||
- Key capabilities overview
|
||||
|
||||
### 8. Generate Table of Contents
|
||||
|
||||
Create hierarchical TOC:
|
||||
```markdown
|
||||
## Table of Contents
|
||||
1. [Overview](#overview)
|
||||
2. [Quick Stats](#quick-stats)
|
||||
3. [Library Categories](#library-categories)
|
||||
- [Availability](#availability)
|
||||
- [Catalogue](#catalogue)
|
||||
- [Checkout](#checkout)
|
||||
...
|
||||
```
|
||||
|
||||
### 9. Add Metadata Header
|
||||
|
||||
Include document metadata:
|
||||
```markdown
|
||||
# Library Reference Guide
|
||||
|
||||
> **Last Updated:** [Current Date]
|
||||
> **Total Libraries:** XX
|
||||
> **Domains:** 12
|
||||
|
||||
## Quick Stats
|
||||
- Availability: 1 | Catalogue: 1 | Checkout: 6 | Common: 3
|
||||
- Core: 5 | CRM: 1 | Icons: 1 | OMS: 9 | Remission: 8
|
||||
- Shared Components: 7 | UI Components: 17 | Utilities: 3
|
||||
```
|
||||
|
||||
### 10. Add Usage Guidelines
|
||||
|
||||
Include quick reference section:
|
||||
```markdown
|
||||
## How to Use This Guide
|
||||
|
||||
### Finding a Library
|
||||
1. Check the domain category (e.g., OMS, Checkout, UI Components)
|
||||
2. Look for the specific feature or component you need
|
||||
3. Note the import path alias (e.g., `@isa/oms/feature-return-search`)
|
||||
|
||||
### Import Syntax
|
||||
All libraries use path aliases defined in `tsconfig.base.json`:
|
||||
|
||||
```typescript
|
||||
// Feature libraries
|
||||
import { Component } from '@isa/domain/feature/name';
|
||||
|
||||
// Data access services
|
||||
import { Service } from '@isa/domain/data-access';
|
||||
|
||||
// UI components
|
||||
import { ButtonComponent } from '@isa/ui/buttons';
|
||||
|
||||
// Utilities
|
||||
import { helper } from '@isa/utils/validation';
|
||||
```
|
||||
```
|
||||
|
||||
### 11. Add Cross-References
|
||||
|
||||
Link related libraries:
|
||||
```markdown
|
||||
**Related Libraries:**
|
||||
- [`@isa/oms/data-access`](#isaomsdataaccess) - OMS data services
|
||||
- [`@isa/ui/buttons`](#isauibuttons) - Button components
|
||||
```
|
||||
|
||||
### 12. Include Testing Information
|
||||
|
||||
For each library, note test framework:
|
||||
```markdown
|
||||
**Testing:** Vitest | Jest
|
||||
**Test Command:** `npx nx test [library-name] --skip-nx-cache`
|
||||
```
|
||||
|
||||
### 13. Validate Generated Documentation
|
||||
|
||||
Checks:
|
||||
- All libraries included (compare count)
|
||||
- All path aliases correct
|
||||
- No broken internal links
|
||||
- Consistent formatting
|
||||
- Alphabetical ordering within categories
|
||||
|
||||
### 14. Update CLAUDE.md Reference
|
||||
|
||||
Update CLAUDE.md to reference new library-reference.md:
|
||||
```markdown
|
||||
#### Library Reference Guide
|
||||
|
||||
The monorepo contains **62 libraries** organized across 12 domains.
|
||||
For quick lookup, see **[`docs/library-reference.md`](docs/library-reference.md)**.
|
||||
```
|
||||
|
||||
### 15. Create Backup
|
||||
|
||||
Before overwriting:
|
||||
```bash
|
||||
# Backup existing file
|
||||
cp docs/library-reference.md docs/library-reference.md.backup.$(date +%s)
|
||||
```
|
||||
|
||||
### 16. Write New Documentation
|
||||
|
||||
Write to `docs/library-reference.md` with generated content.
|
||||
|
||||
## Output Format
|
||||
|
||||
**Generated File Structure:**
|
||||
```markdown
|
||||
# Library Reference Guide
|
||||
|
||||
> Last Updated: [Date]
|
||||
> Total Libraries: XX
|
||||
> Domains: 12
|
||||
|
||||
## Table of Contents
|
||||
[Auto-generated TOC]
|
||||
|
||||
## Overview
|
||||
[Introduction and usage guide]
|
||||
|
||||
## Quick Stats
|
||||
[Statistics by domain]
|
||||
|
||||
## Library Categories
|
||||
|
||||
### Availability
|
||||
#### @isa/availability/data-access
|
||||
[Details...]
|
||||
|
||||
### Catalogue
|
||||
[Details...]
|
||||
|
||||
[... all domains ...]
|
||||
|
||||
## Appendix
|
||||
|
||||
### Path Aliases
|
||||
[Quick reference table]
|
||||
|
||||
### Testing Frameworks
|
||||
[Framework by library]
|
||||
|
||||
### Nx Commands
|
||||
[Common commands]
|
||||
```
|
||||
|
||||
## Output Summary
|
||||
```
|
||||
Library Reference Documentation Generated
|
||||
==========================================
|
||||
|
||||
📊 Statistics
|
||||
-------------
|
||||
Total libraries scanned: XX
|
||||
Libraries documented: XX
|
||||
Domains covered: 12
|
||||
|
||||
📝 Documentation Structure
|
||||
--------------------------
|
||||
- Table of Contents: ✅
|
||||
- Quick Stats: ✅
|
||||
- Library categories: XX
|
||||
- Total entries: XX
|
||||
|
||||
🔍 Quality Checks
|
||||
-----------------
|
||||
- All libraries included: ✅/❌
|
||||
- Path aliases validated: ✅/❌
|
||||
- Internal links verified: ✅/❌
|
||||
- Consistent formatting: ✅/❌
|
||||
|
||||
💾 Files Updated
|
||||
----------------
|
||||
- docs/library-reference.md: ✅
|
||||
- Backup created: docs/library-reference.md.backup.[timestamp]
|
||||
|
||||
📈 Changes from Previous Version
|
||||
---------------------------------
|
||||
- Libraries added: XX
|
||||
- Libraries removed: XX
|
||||
- Descriptions updated: XX
|
||||
|
||||
🎯 Next Steps
|
||||
-------------
|
||||
1. Review generated documentation
|
||||
2. Verify library descriptions are accurate
|
||||
3. Add missing usage examples if needed
|
||||
4. Commit changes: git add docs/library-reference.md
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
- Missing project.json: Skip and report
|
||||
- No README found: Use generic description
|
||||
- Path alias mismatch: Flag for manual review
|
||||
- Broken links: List for correction
|
||||
|
||||
## Automation Tips
|
||||
Can be run:
|
||||
- After adding new libraries
|
||||
- During documentation updates
|
||||
- As pre-release validation
|
||||
- In CI/CD pipeline
|
||||
|
||||
## References
|
||||
- CLAUDE.md Library Organization section
|
||||
- tsconfig.base.json (path aliases)
|
||||
- Individual library README.md files
|
||||
- docs/library-reference.md (existing documentation)
|
||||
129
.claude/commands/quality:bundle-analyze.md
Normal file
129
.claude/commands/quality:bundle-analyze.md
Normal file
@@ -0,0 +1,129 @@
|
||||
# /quality:bundle-analyze - Analyze Bundle Sizes
|
||||
|
||||
Analyze production bundle sizes and provide optimization recommendations. Project thresholds: 2MB warning, 5MB error.
|
||||
|
||||
## Tasks
|
||||
|
||||
### 1. Run Production Build
|
||||
```bash
|
||||
# Clean previous build
|
||||
rm -rf dist/
|
||||
|
||||
# Build for production
|
||||
npm run build-prod
|
||||
```
|
||||
|
||||
### 2. Analyze Bundle Output
|
||||
```bash
|
||||
# List bundle files with sizes
|
||||
ls -lh dist/apps/isa-app/browser/*.js | awk '{print $9, $5}'
|
||||
|
||||
# Get total bundle size
|
||||
du -sh dist/apps/isa-app/browser/
|
||||
```
|
||||
|
||||
### 3. Identify Large Files
|
||||
Parse build output and identify:
|
||||
- Main bundle size
|
||||
- Lazy-loaded chunk sizes
|
||||
- Vendor chunks
|
||||
- Files exceeding thresholds:
|
||||
- **Warning**: > 2MB
|
||||
- **Error**: > 5MB
|
||||
|
||||
### 4. Analyze Dependencies
|
||||
```bash
|
||||
# Check for duplicate dependencies
|
||||
npm ls --depth=0 | grep -E "UNMET|deduped"
|
||||
|
||||
# Show largest node_modules packages
|
||||
du -sh node_modules/* | sort -rh | head -20
|
||||
```
|
||||
|
||||
### 5. Source Map Analysis
|
||||
Use source maps to identify large contributors:
|
||||
```bash
|
||||
# Install source-map-explorer if needed
|
||||
npm install -g source-map-explorer
|
||||
|
||||
# Analyze main bundle
|
||||
source-map-explorer dist/apps/isa-app/browser/main.*.js
|
||||
```
|
||||
|
||||
### 6. Generate Recommendations
|
||||
Based on analysis, provide actionable recommendations:
|
||||
|
||||
**If bundle > 2MB:**
|
||||
- Identify heavy dependencies to replace or remove
|
||||
- Suggest lazy loading opportunities
|
||||
- Check for unused imports
|
||||
|
||||
**Code Splitting Opportunities:**
|
||||
- Large feature modules that could be lazy-loaded
|
||||
- Heavy libraries that could be dynamically imported
|
||||
- Vendor code that could be split into separate chunks
|
||||
|
||||
**Dependency Optimization:**
|
||||
- Replace large libraries with smaller alternatives
|
||||
- Remove unused dependencies
|
||||
- Use tree-shakeable imports
|
||||
|
||||
**Build Configuration:**
|
||||
- Enable/optimize compression
|
||||
- Check for source maps in production (should be disabled)
|
||||
- Verify optimization flags
|
||||
|
||||
### 7. Comparative Analysis
|
||||
If previous build data exists:
|
||||
```bash
|
||||
# Compare with previous build
|
||||
# (Requires manual tracking or CI/CD integration)
|
||||
echo "Current build: $(du -sh dist/apps/isa-app/browser/ | awk '{print $1}')"
|
||||
```
|
||||
|
||||
### 8. Generate Report
|
||||
Create formatted report with:
|
||||
- Total bundle size with threshold status (✅ < 2MB, ⚠️ 2-5MB, ❌ > 5MB)
|
||||
- Main bundle and largest chunks
|
||||
- Top 10 largest dependencies
|
||||
- Optimization recommendations prioritized by impact
|
||||
- Lazy loading opportunities
|
||||
|
||||
## Output Format
|
||||
```
|
||||
Bundle Analysis Report
|
||||
======================
|
||||
|
||||
Total Size: X.XX MB [STATUS]
|
||||
Main Bundle: X.XX MB
|
||||
Largest Chunks:
|
||||
- chunk-name.js: X.XX MB
|
||||
- ...
|
||||
|
||||
Largest Dependencies:
|
||||
1. dependency-name: X.XX MB
|
||||
...
|
||||
|
||||
Recommendations:
|
||||
🔴 Critical (> 5MB):
|
||||
- [Action items]
|
||||
|
||||
⚠️ Warning (2-5MB):
|
||||
- [Action items]
|
||||
|
||||
✅ Optimization Opportunities:
|
||||
- [Action items]
|
||||
|
||||
Lazy Loading Candidates:
|
||||
- [Feature modules]
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
- Build failures: Show error and suggest fixes
|
||||
- Missing tools: Offer to install (source-map-explorer)
|
||||
- No dist folder: Run build first
|
||||
|
||||
## References
|
||||
- CLAUDE.md Build Configuration section
|
||||
- Angular build optimization: https://angular.dev/tools/cli/build
|
||||
- package.json (build-prod script)
|
||||
201
.claude/commands/quality:coverage.md
Normal file
201
.claude/commands/quality:coverage.md
Normal file
@@ -0,0 +1,201 @@
|
||||
# /quality:coverage - Generate Test Coverage Report
|
||||
|
||||
Generate comprehensive test coverage report with recommendations for improving coverage.
|
||||
|
||||
## Parameters
|
||||
- `library-name` (optional): Specific library to analyze. If omitted, analyzes all libraries.
|
||||
|
||||
## Tasks
|
||||
|
||||
### 1. Run Coverage Analysis
|
||||
```bash
|
||||
# Single library
|
||||
npx nx test [library-name] --skip-nx-cache --coverage
|
||||
|
||||
# All libraries (if no library specified)
|
||||
npm run ci # Runs all tests with coverage
|
||||
```
|
||||
|
||||
### 2. Parse Coverage Report
|
||||
Coverage output typically in:
|
||||
- `coverage/libs/[domain]/[layer]/[name]/`
|
||||
- Look for `coverage-summary.json` or text output
|
||||
|
||||
Extract metrics:
|
||||
- **Line coverage**: % of executable lines tested
|
||||
- **Branch coverage**: % of conditional branches tested
|
||||
- **Function coverage**: % of functions called in tests
|
||||
- **Statement coverage**: % of statements executed
|
||||
|
||||
### 3. Identify Uncovered Code
|
||||
Parse coverage report to find:
|
||||
- **Uncovered files**: Files with 0% coverage
|
||||
- **Partially covered files**: < 80% coverage
|
||||
- **Uncovered lines**: Specific line numbers not tested
|
||||
- **Uncovered branches**: Conditional paths not tested
|
||||
|
||||
```bash
|
||||
# List files with coverage below 80%
|
||||
# (Parse from coverage JSON output)
|
||||
```
|
||||
|
||||
### 4. Categorize Coverage Gaps
|
||||
|
||||
**Critical (High Risk):**
|
||||
- Service methods handling business logic
|
||||
- Data transformation functions
|
||||
- Error handling code paths
|
||||
- Security-related functions
|
||||
- State management store actions
|
||||
|
||||
**Important (Medium Risk):**
|
||||
- Component public methods
|
||||
- Utility functions
|
||||
- Validators
|
||||
- Pipes and filters
|
||||
- Guard functions
|
||||
|
||||
**Low Priority:**
|
||||
- Getters/setters
|
||||
- Simple property assignments
|
||||
- Console logging
|
||||
- Type definitions
|
||||
|
||||
### 5. Generate Recommendations
|
||||
|
||||
For each coverage gap, provide:
|
||||
- **File and line numbers**
|
||||
- **Risk level** (Critical/Important/Low)
|
||||
- **Suggested test type** (unit/integration)
|
||||
- **Test approach** (example test scenario)
|
||||
|
||||
Example:
|
||||
```
|
||||
📍 libs/oms/data-access/src/lib/services/order.service.ts:45-52
|
||||
🔴 Critical - Business Logic
|
||||
❌ 0% coverage - Error handling path
|
||||
|
||||
Recommended test:
|
||||
it('should handle API error when fetching order', async () => {
|
||||
// Mock API to return error
|
||||
// Call method
|
||||
// Verify error handling
|
||||
});
|
||||
```
|
||||
|
||||
### 6. Calculate Coverage Trends
|
||||
If historical data available:
|
||||
- Compare with previous coverage percentage
|
||||
- Show improvement/regression
|
||||
- Identify files with declining coverage
|
||||
|
||||
### 7. Generate HTML Report
|
||||
```bash
|
||||
# Open coverage report in browser (if available)
|
||||
open coverage/libs/[domain]/[layer]/[name]/index.html
|
||||
```
|
||||
|
||||
### 8. Create Coverage Summary Report
|
||||
|
||||
**Overall Metrics:**
|
||||
```
|
||||
Coverage Summary for [library-name]
|
||||
====================================
|
||||
|
||||
Line Coverage: XX.X% (XXX/XXX lines)
|
||||
Branch Coverage: XX.X% (XXX/XXX branches)
|
||||
Function Coverage: XX.X% (XXX/XXX functions)
|
||||
Statement Coverage: XX.X% (XXX/XXX statements)
|
||||
|
||||
Target: 80% (Recommended minimum)
|
||||
Status: ✅ Met / ⚠️ Below Target / 🔴 Critical
|
||||
```
|
||||
|
||||
**Files Needing Attention:**
|
||||
```
|
||||
🔴 Critical (< 50% coverage):
|
||||
1. service-name.service.ts - 35% (business logic)
|
||||
2. data-processor.ts - 42% (transformations)
|
||||
|
||||
⚠️ Below Target (50-79% coverage):
|
||||
3. component-name.component.ts - 68%
|
||||
4. validator.ts - 72%
|
||||
|
||||
✅ Well Covered (≥ 80% coverage):
|
||||
- Other files maintaining good coverage
|
||||
```
|
||||
|
||||
**Top Priority Tests to Add:**
|
||||
1. [File:Line] - [Description] - [Risk Level]
|
||||
2. ...
|
||||
|
||||
### 9. Framework-Specific Notes
|
||||
|
||||
**Vitest:**
|
||||
- Coverage provider: v8 or istanbul
|
||||
- Config in `vitest.config.ts`
|
||||
- Coverage thresholds configurable
|
||||
|
||||
**Jest:**
|
||||
- Coverage collected via `--coverage` flag
|
||||
- Config in `jest.config.ts`
|
||||
- Coverage directory: `coverage/`
|
||||
|
||||
### 10. Set Coverage Thresholds (Optional)
|
||||
Suggest adding to test config:
|
||||
```typescript
|
||||
// vitest.config.ts
|
||||
coverage: {
|
||||
thresholds: {
|
||||
lines: 80,
|
||||
functions: 80,
|
||||
branches: 80,
|
||||
statements: 80
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Output Format
|
||||
```
|
||||
Test Coverage Report
|
||||
====================
|
||||
|
||||
Library: [name]
|
||||
Test Framework: [Vitest/Jest]
|
||||
Generated: [timestamp]
|
||||
|
||||
📊 Coverage Metrics
|
||||
-------------------
|
||||
Lines: XX.X% ████████░░ (XXX/XXX)
|
||||
Branches: XX.X% ███████░░░ (XXX/XXX)
|
||||
Functions: XX.X% █████████░ (XXX/XXX)
|
||||
Statements: XX.X% ████████░░ (XXX/XXX)
|
||||
|
||||
🎯 Target: 80% | Status: [✅/⚠️/🔴]
|
||||
|
||||
🔍 Coverage Gaps
|
||||
----------------
|
||||
[Categorized list with priorities]
|
||||
|
||||
💡 Recommendations
|
||||
------------------
|
||||
[Prioritized list of tests to add]
|
||||
|
||||
📈 Next Steps
|
||||
-------------
|
||||
1. Focus on critical coverage gaps first
|
||||
2. Add tests for business logic in [files]
|
||||
3. Consider setting coverage thresholds
|
||||
4. Re-run: npx nx test [library-name] --skip-nx-cache --coverage
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
- No coverage data: Ensure `--coverage` flag used
|
||||
- Missing library: Verify library name is correct
|
||||
- Coverage tool not configured: Check test config for coverage setup
|
||||
|
||||
## References
|
||||
- docs/guidelines/testing.md
|
||||
- CLAUDE.md Testing Framework section
|
||||
- Vitest coverage: https://vitest.dev/guide/coverage
|
||||
- Jest coverage: https://jestjs.io/docs/configuration#collectcoverage-boolean
|
||||
151
.claude/skills/api-change-analyzer/SKILL.md
Normal file
151
.claude/skills/api-change-analyzer/SKILL.md
Normal file
@@ -0,0 +1,151 @@
|
||||
---
|
||||
name: api-change-analyzer
|
||||
description: This skill should be used when analyzing Swagger/OpenAPI specification changes BEFORE regenerating API clients. It compares old vs new specs, categorizes changes as breaking/compatible/warnings, finds affected code, and generates migration strategies. Use this skill when the user wants to check API changes safely before sync, mentions "check breaking changes", or needs impact assessment.
|
||||
---
|
||||
|
||||
# API Change Analyzer
|
||||
|
||||
## Overview
|
||||
|
||||
Analyze Swagger/OpenAPI specification changes to detect breaking changes before regeneration. Provides detailed comparison, impact analysis, and migration recommendations.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke when user wants to:
|
||||
- Check API changes before regeneration
|
||||
- Assess impact of backend updates
|
||||
- Plan migration for breaking changes
|
||||
- Mentioned "breaking changes" or "API diff"
|
||||
|
||||
## Analysis Workflow
|
||||
|
||||
### Step 1: Backup and Generate Temporarily
|
||||
|
||||
```bash
|
||||
cp -r generated/swagger/[api-name] /tmp/[api-name].backup
|
||||
npm run generate:swagger:[api-name]
|
||||
```
|
||||
|
||||
### Step 2: Compare Files
|
||||
|
||||
```bash
|
||||
diff -u /tmp/[api-name].backup/models.ts generated/swagger/[api-name]/models.ts
|
||||
diff -u /tmp/[api-name].backup/services.ts generated/swagger/[api-name]/services.ts
|
||||
```
|
||||
|
||||
### Step 3: Categorize Changes
|
||||
|
||||
**🔴 Breaking (Critical):**
|
||||
- Removed properties from response models
|
||||
- Changed property types (string → number)
|
||||
- Removed endpoints
|
||||
- Optional → required fields
|
||||
- Removed enum values
|
||||
|
||||
**✅ Compatible (Safe):**
|
||||
- Added properties (non-breaking)
|
||||
- New endpoints
|
||||
- Added optional parameters
|
||||
- New enum values
|
||||
|
||||
**⚠️ Warnings (Review):**
|
||||
- Property renamed (old removed + new added)
|
||||
- Changed default values
|
||||
- Changed validation rules
|
||||
- Added required request fields
|
||||
|
||||
### Step 4: Analyze Impact
|
||||
|
||||
For each breaking change, use `Explore` agent to find usages:
|
||||
|
||||
```bash
|
||||
# Example: Find usages of removed property
|
||||
grep -r "removedProperty" libs/*/data-access --include="*.ts"
|
||||
```
|
||||
|
||||
List:
|
||||
- Affected files
|
||||
- Services impacted
|
||||
- Estimated refactoring effort
|
||||
|
||||
### Step 5: Generate Migration Strategy
|
||||
|
||||
Based on severity:
|
||||
|
||||
**High Impact (multiple breaking changes):**
|
||||
1. Create migration branch
|
||||
2. Document all changes
|
||||
3. Update services incrementally
|
||||
4. Comprehensive testing
|
||||
|
||||
**Medium Impact:**
|
||||
1. Fix compilation errors
|
||||
2. Update affected tests
|
||||
3. Deploy with monitoring
|
||||
|
||||
**Low Impact:**
|
||||
1. Minor updates
|
||||
2. Deploy
|
||||
|
||||
### Step 6: Create Report
|
||||
|
||||
```
|
||||
API Breaking Changes Analysis
|
||||
==============================
|
||||
|
||||
API: [api-name]
|
||||
Analysis Date: [timestamp]
|
||||
|
||||
📊 Summary
|
||||
----------
|
||||
Breaking Changes: XX
|
||||
Warnings: XX
|
||||
Compatible Changes: XX
|
||||
|
||||
🔴 Breaking Changes
|
||||
-------------------
|
||||
1. Removed Property: OrderResponse.deliveryDate
|
||||
Files Affected: 2
|
||||
- libs/oms/data-access/src/lib/services/order.service.ts:45
|
||||
- libs/oms/feature/order-detail/src/lib/component.ts:78
|
||||
Impact: Medium
|
||||
Fix: Remove references or use alternativeDate
|
||||
|
||||
2. Type Changed: ProductResponse.price (string → number)
|
||||
Files Affected: 1
|
||||
- libs/catalogue/data-access/src/lib/services/product.service.ts:32
|
||||
Impact: High
|
||||
Fix: Update parsing logic
|
||||
|
||||
⚠️ Warnings
|
||||
-----------
|
||||
1. Possible Rename: CustomerResponse.customerName → fullName
|
||||
Action: Verify with backend team
|
||||
|
||||
✅ Compatible Changes
|
||||
---------------------
|
||||
1. Added Property: OrderResponse.estimatedDelivery
|
||||
2. New Endpoint: GET /api/v2/orders/bulk
|
||||
|
||||
💡 Migration Strategy
|
||||
---------------------
|
||||
Approach: [High/Medium/Low Impact]
|
||||
Estimated Effort: [hours]
|
||||
Steps: [numbered list]
|
||||
|
||||
🎯 Recommendation
|
||||
-----------------
|
||||
[Proceed with sync / Fix critical issues first / Coordinate with backend]
|
||||
```
|
||||
|
||||
### Step 7: Cleanup
|
||||
|
||||
```bash
|
||||
rm -rf /tmp/[api-name].backup
|
||||
# Or restore if needed
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
- CLAUDE.md API Integration
|
||||
- Semantic Versioning: https://semver.org
|
||||
208
.claude/skills/architecture-enforcer/SKILL.md
Normal file
208
.claude/skills/architecture-enforcer/SKILL.md
Normal file
@@ -0,0 +1,208 @@
|
||||
---
|
||||
name: architecture-enforcer
|
||||
description: This skill should be used when validating import boundaries and architectural rules in the ISA-Frontend monorepo. It checks for circular dependencies, layer violations (Feature→Feature), domain violations (OMS→Remission), and relative imports. Use this skill when the user wants to check architecture, mentions "validate boundaries", "check imports", or needs dependency analysis.
|
||||
---
|
||||
|
||||
# Architecture Enforcer
|
||||
|
||||
## Overview
|
||||
|
||||
Validate and enforce architectural boundaries in the monorepo. Checks import rules, detects violations, generates dependency graphs, and suggests refactoring.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke when user wants to:
|
||||
- Validate import boundaries
|
||||
- Check architectural rules
|
||||
- Find dependency violations
|
||||
- Mentioned "check architecture" or "validate imports"
|
||||
|
||||
## Architectural Rules
|
||||
|
||||
**✅ Allowed:**
|
||||
- Feature → Data Access
|
||||
- Feature → UI
|
||||
- Feature → Util
|
||||
- Data Access → Util
|
||||
|
||||
**❌ Forbidden:**
|
||||
- Feature → Feature
|
||||
- Data Access → Feature
|
||||
- UI → Feature
|
||||
- Cross-domain (OMS ↔ Remission)
|
||||
|
||||
## Enforcement Workflow
|
||||
|
||||
### Step 1: Run Nx Dependency Checks
|
||||
|
||||
```bash
|
||||
# Lint all (includes boundary checks)
|
||||
npx nx run-many --target=lint --all
|
||||
|
||||
# Or specific library
|
||||
npx nx lint [library-name]
|
||||
```
|
||||
|
||||
### Step 2: Generate Dependency Graph
|
||||
|
||||
```bash
|
||||
# Visual graph
|
||||
npx nx graph
|
||||
|
||||
# Focus on specific project
|
||||
npx nx graph --focus=[library-name]
|
||||
|
||||
# Affected projects
|
||||
npx nx affected:graph
|
||||
```
|
||||
|
||||
### Step 3: Scan for Violations
|
||||
|
||||
**Check for Circular Dependencies:**
|
||||
Use `Explore` agent to find A→B→A patterns.
|
||||
|
||||
**Check Layer Violations:**
|
||||
```bash
|
||||
# Find feature-to-feature imports
|
||||
grep -r "from '@isa/[^/]*/feature" libs/*/feature/ --include="*.ts"
|
||||
```
|
||||
|
||||
**Check Relative Imports:**
|
||||
```bash
|
||||
# Should use path aliases, not relative
|
||||
grep -r "from '\.\./\.\./\.\." libs/ --include="*.ts"
|
||||
```
|
||||
|
||||
**Check Direct Swagger Imports:**
|
||||
```bash
|
||||
# Should go through data-access
|
||||
grep -r "from '@generated/swagger" libs/*/feature/ --include="*.ts"
|
||||
```
|
||||
|
||||
### Step 4: Categorize Violations
|
||||
|
||||
**🔴 Critical:**
|
||||
- Circular dependencies
|
||||
- Feature → Feature
|
||||
- Data Access → Feature
|
||||
- Cross-domain dependencies
|
||||
|
||||
**⚠️ Warnings:**
|
||||
- Relative imports (should use aliases)
|
||||
- Missing tags in project.json
|
||||
- Deep import paths
|
||||
|
||||
**ℹ️ Info:**
|
||||
- Potential shared utilities
|
||||
|
||||
### Step 5: Generate Violation Report
|
||||
|
||||
For each violation:
|
||||
```
|
||||
📍 libs/oms/feature/return-search/src/lib/component.ts:12
|
||||
🔴 Layer Violation
|
||||
❌ Feature importing from another feature
|
||||
|
||||
Import: import { OrderList } from '@isa/oms/feature-order-list';
|
||||
Issue: Feature libraries should not depend on other features
|
||||
Fix: Move shared component to @isa/shared/* or @isa/ui/*
|
||||
```
|
||||
|
||||
### Step 6: Suggest Refactoring
|
||||
|
||||
**For repeated patterns:**
|
||||
- Create shared library for common components
|
||||
- Extract shared utilities to util library
|
||||
- Move API clients to data-access layer
|
||||
- Create facade services
|
||||
|
||||
### Step 7: Visualize Problems
|
||||
|
||||
```bash
|
||||
npx nx graph --focus=[problematic-library]
|
||||
```
|
||||
|
||||
### Step 8: Generate Report
|
||||
|
||||
```
|
||||
Import Boundary Analysis
|
||||
========================
|
||||
|
||||
Scope: [All | Specific library]
|
||||
|
||||
📊 Summary
|
||||
----------
|
||||
Total violations: XX
|
||||
🔴 Critical: XX
|
||||
⚠️ Warnings: XX
|
||||
ℹ️ Info: XX
|
||||
|
||||
🔍 Violations by Type
|
||||
---------------------
|
||||
Layer violations: XX
|
||||
Domain violations: XX
|
||||
Circular dependencies: XX
|
||||
Path alias violations: XX
|
||||
|
||||
🔴 Critical Violations
|
||||
----------------------
|
||||
1. [File:Line]
|
||||
Issue: Feature → Feature dependency
|
||||
Fix: Extract to @isa/shared/component-name
|
||||
|
||||
2. [File:Line]
|
||||
Issue: Circular dependency
|
||||
Fix: Extract interface to util library
|
||||
|
||||
💡 Refactoring Recommendations
|
||||
-------------------------------
|
||||
1. Create @isa/shared/order-components
|
||||
- Move: [list of shared components]
|
||||
- Benefits: Reusable, breaks circular deps
|
||||
|
||||
2. Extract interfaces to @isa/oms/util
|
||||
- Move: [list of interfaces]
|
||||
- Benefits: Breaks circular dependencies
|
||||
|
||||
📈 Dependency Graph
|
||||
-------------------
|
||||
npx nx graph --focus=[library]
|
||||
|
||||
🎯 Next Steps
|
||||
-------------
|
||||
1. Fix critical violations
|
||||
2. Update ESLint config
|
||||
3. Refactor shared components
|
||||
4. Re-run: architecture-enforcer
|
||||
```
|
||||
|
||||
## Common Fixes
|
||||
|
||||
**Circular Dependencies:**
|
||||
```typescript
|
||||
// Extract shared interface to util
|
||||
// @isa/oms/util
|
||||
export interface OrderId { id: string; }
|
||||
|
||||
// Both services import from util
|
||||
import { OrderId } from '@isa/oms/util';
|
||||
```
|
||||
|
||||
**Layer Violations:**
|
||||
```typescript
|
||||
// Move shared component from feature to ui
|
||||
// Before: @isa/oms/feature-shared
|
||||
// After: @isa/ui/order-components
|
||||
```
|
||||
|
||||
**Path Alias Usage:**
|
||||
```typescript
|
||||
// BEFORE: import { Service } from '../../../data-access/src/lib/service';
|
||||
// AFTER: import { Service } from '@isa/oms/data-access';
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
- CLAUDE.md Architecture section
|
||||
- Nx enforce-module-boundaries: https://nx.dev/nx-api/eslint-plugin/documents/enforce-module-boundaries
|
||||
- tsconfig.base.json (path aliases)
|
||||
249
.claude/skills/circular-dependency-resolver/SKILL.md
Normal file
249
.claude/skills/circular-dependency-resolver/SKILL.md
Normal file
@@ -0,0 +1,249 @@
|
||||
---
|
||||
name: circular-dependency-resolver
|
||||
description: This skill should be used when detecting and resolving circular dependencies in the ISA-Frontend monorepo. It uses graph algorithms to find A→B→C→A cycles, categorizes by severity, provides multiple fix strategies (DI, interface extraction, shared code), and validates fixes. Use this skill when the user mentions "circular dependencies", "dependency cycles", or has build/runtime issues from circular imports.
|
||||
---
|
||||
|
||||
# Circular Dependency Resolver
|
||||
|
||||
## Overview
|
||||
|
||||
Detect and resolve circular dependencies using graph analysis, multiple fix strategies, and automated validation. Prevents runtime and build issues caused by dependency cycles.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke when user:
|
||||
- Mentions "circular dependencies"
|
||||
- Has import cycle errors
|
||||
- Requests dependency analysis
|
||||
- Build fails with circular import warnings
|
||||
|
||||
## Resolution Workflow
|
||||
|
||||
### Step 1: Detect Circular Dependencies
|
||||
|
||||
**Using Nx:**
|
||||
```bash
|
||||
npx nx run-many --target=lint --all 2>&1 | grep -i "circular"
|
||||
```
|
||||
|
||||
**Using madge (if installed):**
|
||||
```bash
|
||||
npm install -g madge
|
||||
madge --circular --extensions ts libs/
|
||||
madge --circular --image circular-deps.svg libs/
|
||||
```
|
||||
|
||||
**Using TypeScript:**
|
||||
```bash
|
||||
npx tsc --noEmit --strict 2>&1 | grep -i "circular\|cycle"
|
||||
```
|
||||
|
||||
### Step 2: Analyze Each Cycle
|
||||
|
||||
For each cycle found:
|
||||
```
|
||||
📍 Circular Dependency Detected
|
||||
|
||||
Cycle Path:
|
||||
1. libs/oms/data-access/src/lib/services/order.service.ts
|
||||
→ imports OrderValidator
|
||||
2. libs/oms/data-access/src/lib/validators/order.validator.ts
|
||||
→ imports OrderService
|
||||
3. Back to order.service.ts
|
||||
|
||||
Type: Service-Validator circular reference
|
||||
Severity: 🔴 Critical
|
||||
Files Involved: 2
|
||||
```
|
||||
|
||||
### Step 3: Categorize by Severity
|
||||
|
||||
**🔴 Critical (Must Fix):**
|
||||
- Service-to-service cycles
|
||||
- Data-access layer cycles
|
||||
- Store dependencies creating cycles
|
||||
|
||||
**⚠️ Warning (Should Fix):**
|
||||
- Component-to-component cycles
|
||||
- Model cross-references
|
||||
- Utility function cycles
|
||||
|
||||
**ℹ️ Info (Review):**
|
||||
- Type-only circular references (may be acceptable)
|
||||
- Test file circular imports
|
||||
|
||||
### Step 4: Choose Fix Strategy
|
||||
|
||||
**Strategy 1: Extract to Shared Utility**
|
||||
```typescript
|
||||
// BEFORE (Circular)
|
||||
// order.service.ts imports validator.ts
|
||||
// validator.ts imports order.service.ts
|
||||
|
||||
// AFTER (Fixed)
|
||||
// Create @isa/oms/util/types.ts
|
||||
export interface OrderData { id: string; }
|
||||
|
||||
// order.service.ts imports types
|
||||
// validator.ts imports types
|
||||
// No more cycle
|
||||
```
|
||||
|
||||
**Strategy 2: Dependency Injection (Lazy)**
|
||||
```typescript
|
||||
// BEFORE
|
||||
import { ServiceB } from './service-b';
|
||||
export class ServiceA {
|
||||
constructor(private serviceB: ServiceB) {}
|
||||
}
|
||||
|
||||
// AFTER
|
||||
import { Injector } from '@angular/core';
|
||||
export class ServiceA {
|
||||
private serviceB!: ServiceB;
|
||||
|
||||
constructor(private injector: Injector) {
|
||||
setTimeout(() => {
|
||||
this.serviceB = this.injector.get(ServiceB);
|
||||
});
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Strategy 3: Interface Extraction**
|
||||
```typescript
|
||||
// BEFORE (Models with circular reference)
|
||||
// order.ts ↔ customer.ts
|
||||
|
||||
// AFTER
|
||||
// order.interface.ts - no imports
|
||||
export interface IOrder { customerId: string; }
|
||||
|
||||
// customer.interface.ts - no imports
|
||||
export interface ICustomer { orderIds: string[]; }
|
||||
|
||||
// order.ts imports only ICustomer
|
||||
// customer.ts imports only IOrder
|
||||
```
|
||||
|
||||
**Strategy 4: Move Shared Code**
|
||||
```typescript
|
||||
// BEFORE
|
||||
// feature-a imports feature-b
|
||||
// feature-b imports feature-a
|
||||
|
||||
// AFTER
|
||||
// Extract to @isa/shared/[name]
|
||||
// Both features import from shared
|
||||
```
|
||||
|
||||
**Strategy 5: Forward References (Angular)**
|
||||
```typescript
|
||||
// Use forwardRef for components
|
||||
import { forwardRef } from '@angular/core';
|
||||
|
||||
@Component({
|
||||
imports: [forwardRef(() => ChildComponent)]
|
||||
})
|
||||
```
|
||||
|
||||
### Step 5: Implement Fix
|
||||
|
||||
Apply chosen strategy:
|
||||
1. Create new files if needed (util library, interfaces)
|
||||
2. Update imports in both files
|
||||
3. Remove circular import
|
||||
|
||||
### Step 6: Validate Fix
|
||||
|
||||
```bash
|
||||
# Check cycle resolved
|
||||
madge --circular --extensions ts libs/
|
||||
|
||||
# TypeScript compilation
|
||||
npx tsc --noEmit
|
||||
|
||||
# Run tests
|
||||
npx nx affected:test --skip-nx-cache
|
||||
|
||||
# Lint
|
||||
npx nx affected:lint
|
||||
```
|
||||
|
||||
### Step 7: Generate Report
|
||||
|
||||
```
|
||||
Circular Dependency Resolution
|
||||
===============================
|
||||
|
||||
Analysis Date: [timestamp]
|
||||
|
||||
📊 Summary
|
||||
----------
|
||||
Circular dependencies found: XX
|
||||
🔴 Critical: XX
|
||||
⚠️ Warning: XX
|
||||
Fixed: XX
|
||||
|
||||
🔍 Detected Cycles
|
||||
------------------
|
||||
|
||||
🔴 Critical Cycle #1 (FIXED)
|
||||
Path: order.service → validator → order.service
|
||||
Strategy Used: Extract to Util Library
|
||||
Created: @isa/oms/util/order-types.ts
|
||||
Files Modified: 2
|
||||
Status: ✅ Resolved
|
||||
|
||||
⚠️ Warning Cycle #2 (FIXED)
|
||||
Path: component-a → component-b → component-a
|
||||
Strategy Used: Move Shared to @isa/ui
|
||||
Created: @isa/ui/shared-component
|
||||
Files Modified: 3
|
||||
Status: ✅ Resolved
|
||||
|
||||
💡 Fix Strategies Applied
|
||||
--------------------------
|
||||
1. Extract to Util: XX cycles
|
||||
2. Interface Extraction: XX cycles
|
||||
3. Move Shared Code: XX cycles
|
||||
4. Dependency Injection: XX cycles
|
||||
|
||||
✅ Validation
|
||||
-------------
|
||||
- madge check: ✅ No cycles
|
||||
- TypeScript: ✅ Compiles
|
||||
- Tests: ✅ XX/XX passing
|
||||
- Lint: ✅ Passed
|
||||
|
||||
🎯 Prevention Tips
|
||||
------------------
|
||||
1. Add ESLint rule: import/no-cycle
|
||||
2. Pre-commit hook for cycle detection
|
||||
3. Regular architecture reviews
|
||||
```
|
||||
|
||||
## Prevention
|
||||
|
||||
**ESLint Configuration:**
|
||||
```json
|
||||
{
|
||||
"import/no-cycle": ["error", { "maxDepth": 1 }]
|
||||
}
|
||||
```
|
||||
|
||||
**Pre-commit Hook:**
|
||||
```bash
|
||||
#!/bin/bash
|
||||
madge --circular --extensions ts libs/
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "❌ Circular dependencies detected"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
- Madge: https://github.com/pahen/madge
|
||||
- Nx dependency graph: https://nx.dev/features/explore-graph
|
||||
- ESLint import plugin: https://github.com/import-js/eslint-plugin-import
|
||||
223
.claude/skills/library-scaffolder/SKILL.md
Normal file
223
.claude/skills/library-scaffolder/SKILL.md
Normal file
@@ -0,0 +1,223 @@
|
||||
---
|
||||
name: library-scaffolder
|
||||
description: This skill should be used when creating new Angular libraries in the ISA-Frontend monorepo. It handles Nx library generation with proper naming conventions, Vitest configuration with JUnit/Cobertura reporters, path alias setup, and validation. Use this skill when the user wants to create a new library, scaffold a feature/data-access/ui/util library, or requests "new library" creation.
|
||||
---
|
||||
|
||||
# Library Scaffolder
|
||||
|
||||
## Overview
|
||||
|
||||
Automate the creation of new Angular libraries following ISA-Frontend conventions. This skill handles the complete scaffolding workflow including Nx generation, Vitest configuration with CI/CD integration, path alias verification, and initial validation.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke this skill when:
|
||||
- User requests creating a new library
|
||||
- User mentions "new library", "scaffold library", or "create feature"
|
||||
- User wants to add a new domain/layer/feature to the monorepo
|
||||
|
||||
## Required Parameters
|
||||
|
||||
User must provide:
|
||||
- **domain**: Domain name (oms, remission, checkout, ui, core, shared, utils)
|
||||
- **layer**: Layer type (feature, data-access, ui, util)
|
||||
- **name**: Library name in kebab-case
|
||||
|
||||
## Scaffolding Workflow
|
||||
|
||||
### Step 1: Validate Input
|
||||
|
||||
1. **Verify Domain**
|
||||
- Use `docs-researcher` to check `docs/library-reference.md`
|
||||
- Ensure domain follows existing patterns
|
||||
|
||||
2. **Validate Layer**
|
||||
- Must be one of: feature, data-access, ui, util
|
||||
|
||||
3. **Check Name**
|
||||
- Must be kebab-case
|
||||
- Must not conflict with existing libraries
|
||||
|
||||
4. **Determine Path Depth**
|
||||
- 3 levels: `libs/domain/layer/name` → `../../../`
|
||||
- 4 levels: `libs/domain/type/layer/name` → `../../../../`
|
||||
|
||||
### Step 2: Run Dry-Run
|
||||
|
||||
Execute Nx generator with `--dry-run`:
|
||||
|
||||
```bash
|
||||
npx nx generate @nx/angular:library \
|
||||
--name=[domain]-[layer]-[name] \
|
||||
--directory=libs/[domain]/[layer]/[name] \
|
||||
--importPath=@isa/[domain]/[layer]/[name] \
|
||||
--style=css \
|
||||
--unitTestRunner=vitest \
|
||||
--standalone=true \
|
||||
--skipTests=false \
|
||||
--dry-run
|
||||
```
|
||||
|
||||
Review output with user before proceeding.
|
||||
|
||||
### Step 3: Generate Library
|
||||
|
||||
Execute without `--dry-run`:
|
||||
|
||||
```bash
|
||||
npx nx generate @nx/angular:library \
|
||||
--name=[domain]-[layer]-[name] \
|
||||
--directory=libs/[domain]/[layer]/[name] \
|
||||
--importPath=@isa/[domain]/[layer]/[name] \
|
||||
--style=css \
|
||||
--unitTestRunner=vitest \
|
||||
--standalone=true \
|
||||
--skipTests=false
|
||||
```
|
||||
|
||||
### Step 4: Configure Vitest with JUnit and Cobertura
|
||||
|
||||
Update `libs/[path]/vite.config.mts`:
|
||||
|
||||
```typescript
|
||||
/// <reference types='vitest' />
|
||||
import { defineConfig } from 'vite';
|
||||
import angular from '@analogjs/vite-plugin-angular';
|
||||
import { nxViteTsPaths } from '@nx/vite/plugins/nx-tsconfig-paths.plugin';
|
||||
import { nxCopyAssetsPlugin } from '@nx/vite/plugins/nx-copy-assets.plugin';
|
||||
|
||||
export default
|
||||
// @ts-expect-error - Vitest reporter tuple types have complex inference issues
|
||||
defineConfig(() => ({
|
||||
root: __dirname,
|
||||
cacheDir: '../../../node_modules/.vite/libs/[path]',
|
||||
plugins: [angular(), nxViteTsPaths(), nxCopyAssetsPlugin(['*.md'])],
|
||||
test: {
|
||||
watch: false,
|
||||
globals: true,
|
||||
environment: 'jsdom',
|
||||
include: ['{src,tests}/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
|
||||
setupFiles: ['src/test-setup.ts'],
|
||||
reporters: [
|
||||
'default',
|
||||
['junit', { outputFile: '../../../testresults/junit-[library-name].xml' }],
|
||||
],
|
||||
coverage: {
|
||||
reportsDirectory: '../../../coverage/libs/[path]',
|
||||
provider: 'v8' as const,
|
||||
reporter: ['text', 'cobertura'],
|
||||
},
|
||||
},
|
||||
}));
|
||||
```
|
||||
|
||||
**Critical**: Adjust path depth based on library location.
|
||||
|
||||
### Step 5: Verify Configuration
|
||||
|
||||
1. **Check Path Alias**
|
||||
- Verify `tsconfig.base.json` was updated
|
||||
- Should have: `"@isa/[domain]/[layer]/[name]": ["libs/[domain]/[layer]/[name]/src/index.ts"]`
|
||||
|
||||
2. **Run Initial Test**
|
||||
```bash
|
||||
npx nx test [library-name] --coverage.enabled=true --skip-nx-cache
|
||||
```
|
||||
|
||||
3. **Verify CI/CD Files Created**
|
||||
- JUnit XML: `testresults/junit-[library-name].xml`
|
||||
- Cobertura XML: `coverage/libs/[path]/cobertura-coverage.xml`
|
||||
|
||||
### Step 6: Create Library README
|
||||
|
||||
Use `docs-researcher` to find similar library READMEs, then create comprehensive documentation including:
|
||||
- Overview and purpose
|
||||
- Installation/import instructions
|
||||
- API documentation
|
||||
- Usage examples
|
||||
- Testing information (Vitest + Angular Testing Utilities)
|
||||
|
||||
### Step 7: Update Library Reference
|
||||
|
||||
Add entry to `docs/library-reference.md` under appropriate domain:
|
||||
|
||||
```markdown
|
||||
#### `@isa/[domain]/[layer]/[name]`
|
||||
**Path:** `libs/[domain]/[layer]/[name]`
|
||||
**Type:** [Feature/Data Access/UI/Util]
|
||||
**Testing:** Vitest
|
||||
|
||||
[Brief description]
|
||||
```
|
||||
|
||||
### Step 8: Run Full Validation
|
||||
|
||||
```bash
|
||||
# Lint
|
||||
npx nx lint [library-name]
|
||||
|
||||
# Test with coverage
|
||||
npx nx test [library-name] --coverage.enabled=true --skip-nx-cache
|
||||
|
||||
# Build (if buildable)
|
||||
npx nx build [library-name]
|
||||
|
||||
# Dependency graph
|
||||
npx nx graph --focus=[library-name]
|
||||
```
|
||||
|
||||
### Step 9: Generate Creation Report
|
||||
|
||||
```
|
||||
Library Created Successfully
|
||||
============================
|
||||
|
||||
Library Name: [domain]-[layer]-[name]
|
||||
Path: libs/[domain]/[layer]/[name]
|
||||
Import Alias: @isa/[domain]/[layer]/[name]
|
||||
|
||||
✅ Configuration
|
||||
----------------
|
||||
Test Framework: Vitest with Angular Testing Utilities
|
||||
Style: CSS
|
||||
Standalone: Yes
|
||||
JUnit Reporter: ✅ testresults/junit-[library-name].xml
|
||||
Cobertura Coverage: ✅ coverage/libs/[path]/cobertura-coverage.xml
|
||||
|
||||
📦 Import Statement
|
||||
-------------------
|
||||
import { Component } from '@isa/[domain]/[layer]/[name]';
|
||||
|
||||
🧪 Test Commands
|
||||
----------------
|
||||
npx nx test [library-name] --skip-nx-cache
|
||||
npx nx test [library-name] --coverage.enabled=true --skip-nx-cache
|
||||
|
||||
📝 Next Steps
|
||||
-------------
|
||||
1. Develop library features
|
||||
2. Write tests using Vitest + Angular Testing Utilities
|
||||
3. Add E2E attributes (data-what, data-which) to templates
|
||||
4. Update README with usage examples
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
**Issue: Path depth mismatch**
|
||||
- Count directory levels from workspace root
|
||||
- Adjust `../` in outputFile and reportsDirectory
|
||||
|
||||
**Issue: TypeScript errors in vite.config.mts**
|
||||
- Add `// @ts-expect-error` before `defineConfig()`
|
||||
|
||||
**Issue: Path alias not working**
|
||||
- Check tsconfig.base.json
|
||||
- Run `npx nx reset`
|
||||
- Restart TypeScript server
|
||||
|
||||
## References
|
||||
|
||||
- docs/guidelines/testing.md (Vitest, JUnit, Cobertura sections)
|
||||
- docs/library-reference.md (domain patterns)
|
||||
- CLAUDE.md (Library Organization, Testing Framework sections)
|
||||
- Nx Angular Library Generator: https://nx.dev/nx-api/angular/generators/library
|
||||
202
.claude/skills/skill-creator/LICENSE.txt
Normal file
202
.claude/skills/skill-creator/LICENSE.txt
Normal file
@@ -0,0 +1,202 @@
|
||||
|
||||
Apache License
|
||||
Version 2.0, January 2004
|
||||
http://www.apache.org/licenses/
|
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||
|
||||
1. Definitions.
|
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction,
|
||||
and distribution as defined by Sections 1 through 9 of this document.
|
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by
|
||||
the copyright owner that is granting the License.
|
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all
|
||||
other entities that control, are controlled by, or are under common
|
||||
control with that entity. For the purposes of this definition,
|
||||
"control" means (i) the power, direct or indirect, to cause the
|
||||
direction or management of such entity, whether by contract or
|
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity
|
||||
exercising permissions granted by this License.
|
||||
|
||||
"Source" form shall mean the preferred form for making modifications,
|
||||
including but not limited to software source code, documentation
|
||||
source, and configuration files.
|
||||
|
||||
"Object" form shall mean any form resulting from mechanical
|
||||
transformation or translation of a Source form, including but
|
||||
not limited to compiled object code, generated documentation,
|
||||
and conversions to other media types.
|
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or
|
||||
Object form, made available under the License, as indicated by a
|
||||
copyright notice that is included in or attached to the work
|
||||
(an example is provided in the Appendix below).
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object
|
||||
form, that is based on (or derived from) the Work and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship. For the purposes
|
||||
of this License, Derivative Works shall not include works that remain
|
||||
separable from, or merely link (or bind by name) to the interfaces of,
|
||||
the Work and Derivative Works thereof.
|
||||
|
||||
"Contribution" shall mean any work of authorship, including
|
||||
the original version of the Work and any modifications or additions
|
||||
to that Work or Derivative Works thereof, that is intentionally
|
||||
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||
or by an individual or Legal Entity authorized to submit on behalf of
|
||||
the copyright owner. For the purposes of this definition, "submitted"
|
||||
means any form of electronic, verbal, or written communication sent
|
||||
to the Licensor or its representatives, including but not limited to
|
||||
communication on electronic mailing lists, source code control systems,
|
||||
and issue tracking systems that are managed by, or on behalf of, the
|
||||
Licensor for the purpose of discussing and improving the Work, but
|
||||
excluding communication that is conspicuously marked or otherwise
|
||||
designated in writing by the copyright owner as "Not a Contribution."
|
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||
on behalf of whom a Contribution has been received by Licensor and
|
||||
subsequently incorporated within the Work.
|
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the
|
||||
Work and such Derivative Works in Source or Object form.
|
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
(except as stated in this section) patent license to make, have made,
|
||||
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||
where such license applies only to those patent claims licensable
|
||||
by such Contributor that are necessarily infringed by their
|
||||
Contribution(s) alone or by combination of their Contribution(s)
|
||||
with the Work to which such Contribution(s) was submitted. If You
|
||||
institute patent litigation against any entity (including a
|
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||
or a Contribution incorporated within the Work constitutes direct
|
||||
or contributory patent infringement, then any patent licenses
|
||||
granted to You under this License for that Work shall terminate
|
||||
as of the date such litigation is filed.
|
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the
|
||||
Work or Derivative Works thereof in any medium, with or without
|
||||
modifications, and in Source or Object form, provided that You
|
||||
meet the following conditions:
|
||||
|
||||
(a) You must give any other recipients of the Work or
|
||||
Derivative Works a copy of this License; and
|
||||
|
||||
(b) You must cause any modified files to carry prominent notices
|
||||
stating that You changed the files; and
|
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works
|
||||
that You distribute, all copyright, patent, trademark, and
|
||||
attribution notices from the Source form of the Work,
|
||||
excluding those notices that do not pertain to any part of
|
||||
the Derivative Works; and
|
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its
|
||||
distribution, then any Derivative Works that You distribute must
|
||||
include a readable copy of the attribution notices contained
|
||||
within such NOTICE file, excluding those notices that do not
|
||||
pertain to any part of the Derivative Works, in at least one
|
||||
of the following places: within a NOTICE text file distributed
|
||||
as part of the Derivative Works; within the Source form or
|
||||
documentation, if provided along with the Derivative Works; or,
|
||||
within a display generated by the Derivative Works, if and
|
||||
wherever such third-party notices normally appear. The contents
|
||||
of the NOTICE file are for informational purposes only and
|
||||
do not modify the License. You may add Your own attribution
|
||||
notices within Derivative Works that You distribute, alongside
|
||||
or as an addendum to the NOTICE text from the Work, provided
|
||||
that such additional attribution notices cannot be construed
|
||||
as modifying the License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and
|
||||
may provide additional or different license terms and conditions
|
||||
for use, reproduction, or distribution of Your modifications, or
|
||||
for any such Derivative Works as a whole, provided Your use,
|
||||
reproduction, and distribution of the Work otherwise complies with
|
||||
the conditions stated in this License.
|
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||
any Contribution intentionally submitted for inclusion in the Work
|
||||
by You to the Licensor shall be under the terms and conditions of
|
||||
this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify
|
||||
the terms of any separate license agreement you may have executed
|
||||
with Licensor regarding such Contributions.
|
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade
|
||||
names, trademarks, service marks, or product names of the Licensor,
|
||||
except as required for reasonable and customary use in describing the
|
||||
origin of the Work and reproducing the content of the NOTICE file.
|
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||
agreed to in writing, Licensor provides the Work (and each
|
||||
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
implied, including, without limitation, any warranties or conditions
|
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||
appropriateness of using or redistributing the Work and assume any
|
||||
risks associated with Your exercise of permissions under this License.
|
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory,
|
||||
whether in tort (including negligence), contract, or otherwise,
|
||||
unless required by applicable law (such as deliberate and grossly
|
||||
negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special,
|
||||
incidental, or consequential damages of any character arising as a
|
||||
result of this License or out of the use or inability to use the
|
||||
Work (including but not limited to damages for loss of goodwill,
|
||||
work stoppage, computer failure or malfunction, or any and all
|
||||
other commercial damages or losses), even if such Contributor
|
||||
has been advised of the possibility of such damages.
|
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing
|
||||
the Work or Derivative Works thereof, You may choose to offer,
|
||||
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||
or other liability obligations and/or rights consistent with this
|
||||
License. However, in accepting such obligations, You may act only
|
||||
on Your own behalf and on Your sole responsibility, not on behalf
|
||||
of any other Contributor, and only if You agree to indemnify,
|
||||
defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason
|
||||
of your accepting any such warranty or additional liability.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
APPENDIX: How to apply the Apache License to your work.
|
||||
|
||||
To apply the Apache License to your work, attach the following
|
||||
boilerplate notice, with the fields enclosed by brackets "[]"
|
||||
replaced with your own identifying information. (Don't include
|
||||
the brackets!) The text should be enclosed in the appropriate
|
||||
comment syntax for the file format. We also recommend that a
|
||||
file or class name and description of purpose be included on the
|
||||
same "printed page" as the copyright notice for easier
|
||||
identification within third-party archives.
|
||||
|
||||
Copyright [yyyy] [name of copyright owner]
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
209
.claude/skills/skill-creator/SKILL.md
Normal file
209
.claude/skills/skill-creator/SKILL.md
Normal file
@@ -0,0 +1,209 @@
|
||||
---
|
||||
name: skill-creator
|
||||
description: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
|
||||
license: Complete terms in LICENSE.txt
|
||||
---
|
||||
|
||||
# Skill Creator
|
||||
|
||||
This skill provides guidance for creating effective skills.
|
||||
|
||||
## About Skills
|
||||
|
||||
Skills are modular, self-contained packages that extend Claude's capabilities by providing
|
||||
specialized knowledge, workflows, and tools. Think of them as "onboarding guides" for specific
|
||||
domains or tasks—they transform Claude from a general-purpose agent into a specialized agent
|
||||
equipped with procedural knowledge that no model can fully possess.
|
||||
|
||||
### What Skills Provide
|
||||
|
||||
1. Specialized workflows - Multi-step procedures for specific domains
|
||||
2. Tool integrations - Instructions for working with specific file formats or APIs
|
||||
3. Domain expertise - Company-specific knowledge, schemas, business logic
|
||||
4. Bundled resources - Scripts, references, and assets for complex and repetitive tasks
|
||||
|
||||
### Anatomy of a Skill
|
||||
|
||||
Every skill consists of a required SKILL.md file and optional bundled resources:
|
||||
|
||||
```
|
||||
skill-name/
|
||||
├── SKILL.md (required)
|
||||
│ ├── YAML frontmatter metadata (required)
|
||||
│ │ ├── name: (required)
|
||||
│ │ └── description: (required)
|
||||
│ └── Markdown instructions (required)
|
||||
└── Bundled Resources (optional)
|
||||
├── scripts/ - Executable code (Python/Bash/etc.)
|
||||
├── references/ - Documentation intended to be loaded into context as needed
|
||||
└── assets/ - Files used in output (templates, icons, fonts, etc.)
|
||||
```
|
||||
|
||||
#### SKILL.md (required)
|
||||
|
||||
**Metadata Quality:** The `name` and `description` in YAML frontmatter determine when Claude will use the skill. Be specific about what the skill does and when to use it. Use the third-person (e.g. "This skill should be used when..." instead of "Use this skill when...").
|
||||
|
||||
#### Bundled Resources (optional)
|
||||
|
||||
##### Scripts (`scripts/`)
|
||||
|
||||
Executable code (Python/Bash/etc.) for tasks that require deterministic reliability or are repeatedly rewritten.
|
||||
|
||||
- **When to include**: When the same code is being rewritten repeatedly or deterministic reliability is needed
|
||||
- **Example**: `scripts/rotate_pdf.py` for PDF rotation tasks
|
||||
- **Benefits**: Token efficient, deterministic, may be executed without loading into context
|
||||
- **Note**: Scripts may still need to be read by Claude for patching or environment-specific adjustments
|
||||
|
||||
##### References (`references/`)
|
||||
|
||||
Documentation and reference material intended to be loaded as needed into context to inform Claude's process and thinking.
|
||||
|
||||
- **When to include**: For documentation that Claude should reference while working
|
||||
- **Examples**: `references/finance.md` for financial schemas, `references/mnda.md` for company NDA template, `references/policies.md` for company policies, `references/api_docs.md` for API specifications
|
||||
- **Use cases**: Database schemas, API documentation, domain knowledge, company policies, detailed workflow guides
|
||||
- **Benefits**: Keeps SKILL.md lean, loaded only when Claude determines it's needed
|
||||
- **Best practice**: If files are large (>10k words), include grep search patterns in SKILL.md
|
||||
- **Avoid duplication**: Information should live in either SKILL.md or references files, not both. Prefer references files for detailed information unless it's truly core to the skill—this keeps SKILL.md lean while making information discoverable without hogging the context window. Keep only essential procedural instructions and workflow guidance in SKILL.md; move detailed reference material, schemas, and examples to references files.
|
||||
|
||||
##### Assets (`assets/`)
|
||||
|
||||
Files not intended to be loaded into context, but rather used within the output Claude produces.
|
||||
|
||||
- **When to include**: When the skill needs files that will be used in the final output
|
||||
- **Examples**: `assets/logo.png` for brand assets, `assets/slides.pptx` for PowerPoint templates, `assets/frontend-template/` for HTML/React boilerplate, `assets/font.ttf` for typography
|
||||
- **Use cases**: Templates, images, icons, boilerplate code, fonts, sample documents that get copied or modified
|
||||
- **Benefits**: Separates output resources from documentation, enables Claude to use files without loading them into context
|
||||
|
||||
### Progressive Disclosure Design Principle
|
||||
|
||||
Skills use a three-level loading system to manage context efficiently:
|
||||
|
||||
1. **Metadata (name + description)** - Always in context (~100 words)
|
||||
2. **SKILL.md body** - When skill triggers (<5k words)
|
||||
3. **Bundled resources** - As needed by Claude (Unlimited*)
|
||||
|
||||
*Unlimited because scripts can be executed without reading into context window.
|
||||
|
||||
## Skill Creation Process
|
||||
|
||||
To create a skill, follow the "Skill Creation Process" in order, skipping steps only if there is a clear reason why they are not applicable.
|
||||
|
||||
### Step 1: Understanding the Skill with Concrete Examples
|
||||
|
||||
Skip this step only when the skill's usage patterns are already clearly understood. It remains valuable even when working with an existing skill.
|
||||
|
||||
To create an effective skill, clearly understand concrete examples of how the skill will be used. This understanding can come from either direct user examples or generated examples that are validated with user feedback.
|
||||
|
||||
For example, when building an image-editor skill, relevant questions include:
|
||||
|
||||
- "What functionality should the image-editor skill support? Editing, rotating, anything else?"
|
||||
- "Can you give some examples of how this skill would be used?"
|
||||
- "I can imagine users asking for things like 'Remove the red-eye from this image' or 'Rotate this image'. Are there other ways you imagine this skill being used?"
|
||||
- "What would a user say that should trigger this skill?"
|
||||
|
||||
To avoid overwhelming users, avoid asking too many questions in a single message. Start with the most important questions and follow up as needed for better effectiveness.
|
||||
|
||||
Conclude this step when there is a clear sense of the functionality the skill should support.
|
||||
|
||||
### Step 2: Planning the Reusable Skill Contents
|
||||
|
||||
To turn concrete examples into an effective skill, analyze each example by:
|
||||
|
||||
1. Considering how to execute on the example from scratch
|
||||
2. Identifying what scripts, references, and assets would be helpful when executing these workflows repeatedly
|
||||
|
||||
Example: When building a `pdf-editor` skill to handle queries like "Help me rotate this PDF," the analysis shows:
|
||||
|
||||
1. Rotating a PDF requires re-writing the same code each time
|
||||
2. A `scripts/rotate_pdf.py` script would be helpful to store in the skill
|
||||
|
||||
Example: When designing a `frontend-webapp-builder` skill for queries like "Build me a todo app" or "Build me a dashboard to track my steps," the analysis shows:
|
||||
|
||||
1. Writing a frontend webapp requires the same boilerplate HTML/React each time
|
||||
2. An `assets/hello-world/` template containing the boilerplate HTML/React project files would be helpful to store in the skill
|
||||
|
||||
Example: When building a `big-query` skill to handle queries like "How many users have logged in today?" the analysis shows:
|
||||
|
||||
1. Querying BigQuery requires re-discovering the table schemas and relationships each time
|
||||
2. A `references/schema.md` file documenting the table schemas would be helpful to store in the skill
|
||||
|
||||
To establish the skill's contents, analyze each concrete example to create a list of the reusable resources to include: scripts, references, and assets.
|
||||
|
||||
### Step 3: Initializing the Skill
|
||||
|
||||
At this point, it is time to actually create the skill.
|
||||
|
||||
Skip this step only if the skill being developed already exists, and iteration or packaging is needed. In this case, continue to the next step.
|
||||
|
||||
When creating a new skill from scratch, always run the `init_skill.py` script. The script conveniently generates a new template skill directory that automatically includes everything a skill requires, making the skill creation process much more efficient and reliable.
|
||||
|
||||
Usage:
|
||||
|
||||
```bash
|
||||
scripts/init_skill.py <skill-name> --path <output-directory>
|
||||
```
|
||||
|
||||
The script:
|
||||
|
||||
- Creates the skill directory at the specified path
|
||||
- Generates a SKILL.md template with proper frontmatter and TODO placeholders
|
||||
- Creates example resource directories: `scripts/`, `references/`, and `assets/`
|
||||
- Adds example files in each directory that can be customized or deleted
|
||||
|
||||
After initialization, customize or remove the generated SKILL.md and example files as needed.
|
||||
|
||||
### Step 4: Edit the Skill
|
||||
|
||||
When editing the (newly-generated or existing) skill, remember that the skill is being created for another instance of Claude to use. Focus on including information that would be beneficial and non-obvious to Claude. Consider what procedural knowledge, domain-specific details, or reusable assets would help another Claude instance execute these tasks more effectively.
|
||||
|
||||
#### Start with Reusable Skill Contents
|
||||
|
||||
To begin implementation, start with the reusable resources identified above: `scripts/`, `references/`, and `assets/` files. Note that this step may require user input. For example, when implementing a `brand-guidelines` skill, the user may need to provide brand assets or templates to store in `assets/`, or documentation to store in `references/`.
|
||||
|
||||
Also, delete any example files and directories not needed for the skill. The initialization script creates example files in `scripts/`, `references/`, and `assets/` to demonstrate structure, but most skills won't need all of them.
|
||||
|
||||
#### Update SKILL.md
|
||||
|
||||
**Writing Style:** Write the entire skill using **imperative/infinitive form** (verb-first instructions), not second person. Use objective, instructional language (e.g., "To accomplish X, do Y" rather than "You should do X" or "If you need to do X"). This maintains consistency and clarity for AI consumption.
|
||||
|
||||
To complete SKILL.md, answer the following questions:
|
||||
|
||||
1. What is the purpose of the skill, in a few sentences?
|
||||
2. When should the skill be used?
|
||||
3. In practice, how should Claude use the skill? All reusable skill contents developed above should be referenced so that Claude knows how to use them.
|
||||
|
||||
### Step 5: Packaging a Skill
|
||||
|
||||
Once the skill is ready, it should be packaged into a distributable zip file that gets shared with the user. The packaging process automatically validates the skill first to ensure it meets all requirements:
|
||||
|
||||
```bash
|
||||
scripts/package_skill.py <path/to/skill-folder>
|
||||
```
|
||||
|
||||
Optional output directory specification:
|
||||
|
||||
```bash
|
||||
scripts/package_skill.py <path/to/skill-folder> ./dist
|
||||
```
|
||||
|
||||
The packaging script will:
|
||||
|
||||
1. **Validate** the skill automatically, checking:
|
||||
- YAML frontmatter format and required fields
|
||||
- Skill naming conventions and directory structure
|
||||
- Description completeness and quality
|
||||
- File organization and resource references
|
||||
|
||||
2. **Package** the skill if validation passes, creating a zip file named after the skill (e.g., `my-skill.zip`) that includes all files and maintains the proper directory structure for distribution.
|
||||
|
||||
If validation fails, the script will report the errors and exit without creating a package. Fix any validation errors and run the packaging command again.
|
||||
|
||||
### Step 6: Iterate
|
||||
|
||||
After testing the skill, users may request improvements. Often this happens right after using the skill, with fresh context of how the skill performed.
|
||||
|
||||
**Iteration workflow:**
|
||||
1. Use the skill on real tasks
|
||||
2. Notice struggles or inefficiencies
|
||||
3. Identify how SKILL.md or bundled resources should be updated
|
||||
4. Implement changes and test again
|
||||
303
.claude/skills/skill-creator/scripts/init_skill.py
Executable file
303
.claude/skills/skill-creator/scripts/init_skill.py
Executable file
@@ -0,0 +1,303 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Skill Initializer - Creates a new skill from template
|
||||
|
||||
Usage:
|
||||
init_skill.py <skill-name> --path <path>
|
||||
|
||||
Examples:
|
||||
init_skill.py my-new-skill --path skills/public
|
||||
init_skill.py my-api-helper --path skills/private
|
||||
init_skill.py custom-skill --path /custom/location
|
||||
"""
|
||||
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
SKILL_TEMPLATE = """---
|
||||
name: {skill_name}
|
||||
description: [TODO: Complete and informative explanation of what the skill does and when to use it. Include WHEN to use this skill - specific scenarios, file types, or tasks that trigger it.]
|
||||
---
|
||||
|
||||
# {skill_title}
|
||||
|
||||
## Overview
|
||||
|
||||
[TODO: 1-2 sentences explaining what this skill enables]
|
||||
|
||||
## Structuring This Skill
|
||||
|
||||
[TODO: Choose the structure that best fits this skill's purpose. Common patterns:
|
||||
|
||||
**1. Workflow-Based** (best for sequential processes)
|
||||
- Works well when there are clear step-by-step procedures
|
||||
- Example: DOCX skill with "Workflow Decision Tree" → "Reading" → "Creating" → "Editing"
|
||||
- Structure: ## Overview → ## Workflow Decision Tree → ## Step 1 → ## Step 2...
|
||||
|
||||
**2. Task-Based** (best for tool collections)
|
||||
- Works well when the skill offers different operations/capabilities
|
||||
- Example: PDF skill with "Quick Start" → "Merge PDFs" → "Split PDFs" → "Extract Text"
|
||||
- Structure: ## Overview → ## Quick Start → ## Task Category 1 → ## Task Category 2...
|
||||
|
||||
**3. Reference/Guidelines** (best for standards or specifications)
|
||||
- Works well for brand guidelines, coding standards, or requirements
|
||||
- Example: Brand styling with "Brand Guidelines" → "Colors" → "Typography" → "Features"
|
||||
- Structure: ## Overview → ## Guidelines → ## Specifications → ## Usage...
|
||||
|
||||
**4. Capabilities-Based** (best for integrated systems)
|
||||
- Works well when the skill provides multiple interrelated features
|
||||
- Example: Product Management with "Core Capabilities" → numbered capability list
|
||||
- Structure: ## Overview → ## Core Capabilities → ### 1. Feature → ### 2. Feature...
|
||||
|
||||
Patterns can be mixed and matched as needed. Most skills combine patterns (e.g., start with task-based, add workflow for complex operations).
|
||||
|
||||
Delete this entire "Structuring This Skill" section when done - it's just guidance.]
|
||||
|
||||
## [TODO: Replace with the first main section based on chosen structure]
|
||||
|
||||
[TODO: Add content here. See examples in existing skills:
|
||||
- Code samples for technical skills
|
||||
- Decision trees for complex workflows
|
||||
- Concrete examples with realistic user requests
|
||||
- References to scripts/templates/references as needed]
|
||||
|
||||
## Resources
|
||||
|
||||
This skill includes example resource directories that demonstrate how to organize different types of bundled resources:
|
||||
|
||||
### scripts/
|
||||
Executable code (Python/Bash/etc.) that can be run directly to perform specific operations.
|
||||
|
||||
**Examples from other skills:**
|
||||
- PDF skill: `fill_fillable_fields.py`, `extract_form_field_info.py` - utilities for PDF manipulation
|
||||
- DOCX skill: `document.py`, `utilities.py` - Python modules for document processing
|
||||
|
||||
**Appropriate for:** Python scripts, shell scripts, or any executable code that performs automation, data processing, or specific operations.
|
||||
|
||||
**Note:** Scripts may be executed without loading into context, but can still be read by Claude for patching or environment adjustments.
|
||||
|
||||
### references/
|
||||
Documentation and reference material intended to be loaded into context to inform Claude's process and thinking.
|
||||
|
||||
**Examples from other skills:**
|
||||
- Product management: `communication.md`, `context_building.md` - detailed workflow guides
|
||||
- BigQuery: API reference documentation and query examples
|
||||
- Finance: Schema documentation, company policies
|
||||
|
||||
**Appropriate for:** In-depth documentation, API references, database schemas, comprehensive guides, or any detailed information that Claude should reference while working.
|
||||
|
||||
### assets/
|
||||
Files not intended to be loaded into context, but rather used within the output Claude produces.
|
||||
|
||||
**Examples from other skills:**
|
||||
- Brand styling: PowerPoint template files (.pptx), logo files
|
||||
- Frontend builder: HTML/React boilerplate project directories
|
||||
- Typography: Font files (.ttf, .woff2)
|
||||
|
||||
**Appropriate for:** Templates, boilerplate code, document templates, images, icons, fonts, or any files meant to be copied or used in the final output.
|
||||
|
||||
---
|
||||
|
||||
**Any unneeded directories can be deleted.** Not every skill requires all three types of resources.
|
||||
"""
|
||||
|
||||
EXAMPLE_SCRIPT = '''#!/usr/bin/env python3
|
||||
"""
|
||||
Example helper script for {skill_name}
|
||||
|
||||
This is a placeholder script that can be executed directly.
|
||||
Replace with actual implementation or delete if not needed.
|
||||
|
||||
Example real scripts from other skills:
|
||||
- pdf/scripts/fill_fillable_fields.py - Fills PDF form fields
|
||||
- pdf/scripts/convert_pdf_to_images.py - Converts PDF pages to images
|
||||
"""
|
||||
|
||||
def main():
|
||||
print("This is an example script for {skill_name}")
|
||||
# TODO: Add actual script logic here
|
||||
# This could be data processing, file conversion, API calls, etc.
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
'''
|
||||
|
||||
EXAMPLE_REFERENCE = """# Reference Documentation for {skill_title}
|
||||
|
||||
This is a placeholder for detailed reference documentation.
|
||||
Replace with actual reference content or delete if not needed.
|
||||
|
||||
Example real reference docs from other skills:
|
||||
- product-management/references/communication.md - Comprehensive guide for status updates
|
||||
- product-management/references/context_building.md - Deep-dive on gathering context
|
||||
- bigquery/references/ - API references and query examples
|
||||
|
||||
## When Reference Docs Are Useful
|
||||
|
||||
Reference docs are ideal for:
|
||||
- Comprehensive API documentation
|
||||
- Detailed workflow guides
|
||||
- Complex multi-step processes
|
||||
- Information too lengthy for main SKILL.md
|
||||
- Content that's only needed for specific use cases
|
||||
|
||||
## Structure Suggestions
|
||||
|
||||
### API Reference Example
|
||||
- Overview
|
||||
- Authentication
|
||||
- Endpoints with examples
|
||||
- Error codes
|
||||
- Rate limits
|
||||
|
||||
### Workflow Guide Example
|
||||
- Prerequisites
|
||||
- Step-by-step instructions
|
||||
- Common patterns
|
||||
- Troubleshooting
|
||||
- Best practices
|
||||
"""
|
||||
|
||||
EXAMPLE_ASSET = """# Example Asset File
|
||||
|
||||
This placeholder represents where asset files would be stored.
|
||||
Replace with actual asset files (templates, images, fonts, etc.) or delete if not needed.
|
||||
|
||||
Asset files are NOT intended to be loaded into context, but rather used within
|
||||
the output Claude produces.
|
||||
|
||||
Example asset files from other skills:
|
||||
- Brand guidelines: logo.png, slides_template.pptx
|
||||
- Frontend builder: hello-world/ directory with HTML/React boilerplate
|
||||
- Typography: custom-font.ttf, font-family.woff2
|
||||
- Data: sample_data.csv, test_dataset.json
|
||||
|
||||
## Common Asset Types
|
||||
|
||||
- Templates: .pptx, .docx, boilerplate directories
|
||||
- Images: .png, .jpg, .svg, .gif
|
||||
- Fonts: .ttf, .otf, .woff, .woff2
|
||||
- Boilerplate code: Project directories, starter files
|
||||
- Icons: .ico, .svg
|
||||
- Data files: .csv, .json, .xml, .yaml
|
||||
|
||||
Note: This is a text placeholder. Actual assets can be any file type.
|
||||
"""
|
||||
|
||||
|
||||
def title_case_skill_name(skill_name):
|
||||
"""Convert hyphenated skill name to Title Case for display."""
|
||||
return ' '.join(word.capitalize() for word in skill_name.split('-'))
|
||||
|
||||
|
||||
def init_skill(skill_name, path):
|
||||
"""
|
||||
Initialize a new skill directory with template SKILL.md.
|
||||
|
||||
Args:
|
||||
skill_name: Name of the skill
|
||||
path: Path where the skill directory should be created
|
||||
|
||||
Returns:
|
||||
Path to created skill directory, or None if error
|
||||
"""
|
||||
# Determine skill directory path
|
||||
skill_dir = Path(path).resolve() / skill_name
|
||||
|
||||
# Check if directory already exists
|
||||
if skill_dir.exists():
|
||||
print(f"❌ Error: Skill directory already exists: {skill_dir}")
|
||||
return None
|
||||
|
||||
# Create skill directory
|
||||
try:
|
||||
skill_dir.mkdir(parents=True, exist_ok=False)
|
||||
print(f"✅ Created skill directory: {skill_dir}")
|
||||
except Exception as e:
|
||||
print(f"❌ Error creating directory: {e}")
|
||||
return None
|
||||
|
||||
# Create SKILL.md from template
|
||||
skill_title = title_case_skill_name(skill_name)
|
||||
skill_content = SKILL_TEMPLATE.format(
|
||||
skill_name=skill_name,
|
||||
skill_title=skill_title
|
||||
)
|
||||
|
||||
skill_md_path = skill_dir / 'SKILL.md'
|
||||
try:
|
||||
skill_md_path.write_text(skill_content)
|
||||
print("✅ Created SKILL.md")
|
||||
except Exception as e:
|
||||
print(f"❌ Error creating SKILL.md: {e}")
|
||||
return None
|
||||
|
||||
# Create resource directories with example files
|
||||
try:
|
||||
# Create scripts/ directory with example script
|
||||
scripts_dir = skill_dir / 'scripts'
|
||||
scripts_dir.mkdir(exist_ok=True)
|
||||
example_script = scripts_dir / 'example.py'
|
||||
example_script.write_text(EXAMPLE_SCRIPT.format(skill_name=skill_name))
|
||||
example_script.chmod(0o755)
|
||||
print("✅ Created scripts/example.py")
|
||||
|
||||
# Create references/ directory with example reference doc
|
||||
references_dir = skill_dir / 'references'
|
||||
references_dir.mkdir(exist_ok=True)
|
||||
example_reference = references_dir / 'api_reference.md'
|
||||
example_reference.write_text(EXAMPLE_REFERENCE.format(skill_title=skill_title))
|
||||
print("✅ Created references/api_reference.md")
|
||||
|
||||
# Create assets/ directory with example asset placeholder
|
||||
assets_dir = skill_dir / 'assets'
|
||||
assets_dir.mkdir(exist_ok=True)
|
||||
example_asset = assets_dir / 'example_asset.txt'
|
||||
example_asset.write_text(EXAMPLE_ASSET)
|
||||
print("✅ Created assets/example_asset.txt")
|
||||
except Exception as e:
|
||||
print(f"❌ Error creating resource directories: {e}")
|
||||
return None
|
||||
|
||||
# Print next steps
|
||||
print(f"\n✅ Skill '{skill_name}' initialized successfully at {skill_dir}")
|
||||
print("\nNext steps:")
|
||||
print("1. Edit SKILL.md to complete the TODO items and update the description")
|
||||
print("2. Customize or delete the example files in scripts/, references/, and assets/")
|
||||
print("3. Run the validator when ready to check the skill structure")
|
||||
|
||||
return skill_dir
|
||||
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 4 or sys.argv[2] != '--path':
|
||||
print("Usage: init_skill.py <skill-name> --path <path>")
|
||||
print("\nSkill name requirements:")
|
||||
print(" - Hyphen-case identifier (e.g., 'data-analyzer')")
|
||||
print(" - Lowercase letters, digits, and hyphens only")
|
||||
print(" - Max 40 characters")
|
||||
print(" - Must match directory name exactly")
|
||||
print("\nExamples:")
|
||||
print(" init_skill.py my-new-skill --path skills/public")
|
||||
print(" init_skill.py my-api-helper --path skills/private")
|
||||
print(" init_skill.py custom-skill --path /custom/location")
|
||||
sys.exit(1)
|
||||
|
||||
skill_name = sys.argv[1]
|
||||
path = sys.argv[3]
|
||||
|
||||
print(f"🚀 Initializing skill: {skill_name}")
|
||||
print(f" Location: {path}")
|
||||
print()
|
||||
|
||||
result = init_skill(skill_name, path)
|
||||
|
||||
if result:
|
||||
sys.exit(0)
|
||||
else:
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
110
.claude/skills/skill-creator/scripts/package_skill.py
Executable file
110
.claude/skills/skill-creator/scripts/package_skill.py
Executable file
@@ -0,0 +1,110 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Skill Packager - Creates a distributable zip file of a skill folder
|
||||
|
||||
Usage:
|
||||
python utils/package_skill.py <path/to/skill-folder> [output-directory]
|
||||
|
||||
Example:
|
||||
python utils/package_skill.py skills/public/my-skill
|
||||
python utils/package_skill.py skills/public/my-skill ./dist
|
||||
"""
|
||||
|
||||
import sys
|
||||
import zipfile
|
||||
from pathlib import Path
|
||||
from quick_validate import validate_skill
|
||||
|
||||
|
||||
def package_skill(skill_path, output_dir=None):
|
||||
"""
|
||||
Package a skill folder into a zip file.
|
||||
|
||||
Args:
|
||||
skill_path: Path to the skill folder
|
||||
output_dir: Optional output directory for the zip file (defaults to current directory)
|
||||
|
||||
Returns:
|
||||
Path to the created zip file, or None if error
|
||||
"""
|
||||
skill_path = Path(skill_path).resolve()
|
||||
|
||||
# Validate skill folder exists
|
||||
if not skill_path.exists():
|
||||
print(f"❌ Error: Skill folder not found: {skill_path}")
|
||||
return None
|
||||
|
||||
if not skill_path.is_dir():
|
||||
print(f"❌ Error: Path is not a directory: {skill_path}")
|
||||
return None
|
||||
|
||||
# Validate SKILL.md exists
|
||||
skill_md = skill_path / "SKILL.md"
|
||||
if not skill_md.exists():
|
||||
print(f"❌ Error: SKILL.md not found in {skill_path}")
|
||||
return None
|
||||
|
||||
# Run validation before packaging
|
||||
print("🔍 Validating skill...")
|
||||
valid, message = validate_skill(skill_path)
|
||||
if not valid:
|
||||
print(f"❌ Validation failed: {message}")
|
||||
print(" Please fix the validation errors before packaging.")
|
||||
return None
|
||||
print(f"✅ {message}\n")
|
||||
|
||||
# Determine output location
|
||||
skill_name = skill_path.name
|
||||
if output_dir:
|
||||
output_path = Path(output_dir).resolve()
|
||||
output_path.mkdir(parents=True, exist_ok=True)
|
||||
else:
|
||||
output_path = Path.cwd()
|
||||
|
||||
zip_filename = output_path / f"{skill_name}.zip"
|
||||
|
||||
# Create the zip file
|
||||
try:
|
||||
with zipfile.ZipFile(zip_filename, 'w', zipfile.ZIP_DEFLATED) as zipf:
|
||||
# Walk through the skill directory
|
||||
for file_path in skill_path.rglob('*'):
|
||||
if file_path.is_file():
|
||||
# Calculate the relative path within the zip
|
||||
arcname = file_path.relative_to(skill_path.parent)
|
||||
zipf.write(file_path, arcname)
|
||||
print(f" Added: {arcname}")
|
||||
|
||||
print(f"\n✅ Successfully packaged skill to: {zip_filename}")
|
||||
return zip_filename
|
||||
|
||||
except Exception as e:
|
||||
print(f"❌ Error creating zip file: {e}")
|
||||
return None
|
||||
|
||||
|
||||
def main():
|
||||
if len(sys.argv) < 2:
|
||||
print("Usage: python utils/package_skill.py <path/to/skill-folder> [output-directory]")
|
||||
print("\nExample:")
|
||||
print(" python utils/package_skill.py skills/public/my-skill")
|
||||
print(" python utils/package_skill.py skills/public/my-skill ./dist")
|
||||
sys.exit(1)
|
||||
|
||||
skill_path = sys.argv[1]
|
||||
output_dir = sys.argv[2] if len(sys.argv) > 2 else None
|
||||
|
||||
print(f"📦 Packaging skill: {skill_path}")
|
||||
if output_dir:
|
||||
print(f" Output directory: {output_dir}")
|
||||
print()
|
||||
|
||||
result = package_skill(skill_path, output_dir)
|
||||
|
||||
if result:
|
||||
sys.exit(0)
|
||||
else:
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
65
.claude/skills/skill-creator/scripts/quick_validate.py
Executable file
65
.claude/skills/skill-creator/scripts/quick_validate.py
Executable file
@@ -0,0 +1,65 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Quick validation script for skills - minimal version
|
||||
"""
|
||||
|
||||
import sys
|
||||
import os
|
||||
import re
|
||||
from pathlib import Path
|
||||
|
||||
def validate_skill(skill_path):
|
||||
"""Basic validation of a skill"""
|
||||
skill_path = Path(skill_path)
|
||||
|
||||
# Check SKILL.md exists
|
||||
skill_md = skill_path / 'SKILL.md'
|
||||
if not skill_md.exists():
|
||||
return False, "SKILL.md not found"
|
||||
|
||||
# Read and validate frontmatter
|
||||
content = skill_md.read_text()
|
||||
if not content.startswith('---'):
|
||||
return False, "No YAML frontmatter found"
|
||||
|
||||
# Extract frontmatter
|
||||
match = re.match(r'^---\n(.*?)\n---', content, re.DOTALL)
|
||||
if not match:
|
||||
return False, "Invalid frontmatter format"
|
||||
|
||||
frontmatter = match.group(1)
|
||||
|
||||
# Check required fields
|
||||
if 'name:' not in frontmatter:
|
||||
return False, "Missing 'name' in frontmatter"
|
||||
if 'description:' not in frontmatter:
|
||||
return False, "Missing 'description' in frontmatter"
|
||||
|
||||
# Extract name for validation
|
||||
name_match = re.search(r'name:\s*(.+)', frontmatter)
|
||||
if name_match:
|
||||
name = name_match.group(1).strip()
|
||||
# Check naming convention (hyphen-case: lowercase with hyphens)
|
||||
if not re.match(r'^[a-z0-9-]+$', name):
|
||||
return False, f"Name '{name}' should be hyphen-case (lowercase letters, digits, and hyphens only)"
|
||||
if name.startswith('-') or name.endswith('-') or '--' in name:
|
||||
return False, f"Name '{name}' cannot start/end with hyphen or contain consecutive hyphens"
|
||||
|
||||
# Extract and validate description
|
||||
desc_match = re.search(r'description:\s*(.+)', frontmatter)
|
||||
if desc_match:
|
||||
description = desc_match.group(1).strip()
|
||||
# Check for angle brackets
|
||||
if '<' in description or '>' in description:
|
||||
return False, "Description cannot contain angle brackets (< or >)"
|
||||
|
||||
return True, "Skill is valid!"
|
||||
|
||||
if __name__ == "__main__":
|
||||
if len(sys.argv) != 2:
|
||||
print("Usage: python quick_validate.py <skill_directory>")
|
||||
sys.exit(1)
|
||||
|
||||
valid, message = validate_skill(sys.argv[1])
|
||||
print(message)
|
||||
sys.exit(0 if valid else 1)
|
||||
212
.claude/skills/standalone-component-migrator/SKILL.md
Normal file
212
.claude/skills/standalone-component-migrator/SKILL.md
Normal file
@@ -0,0 +1,212 @@
|
||||
---
|
||||
name: standalone-component-migrator
|
||||
description: This skill should be used when converting Angular NgModule-based components to standalone architecture. It handles dependency analysis, template scanning, route refactoring, and test updates. Use this skill when the user requests component migration to standalone, mentions "convert to standalone", or wants to modernize Angular components to the latest patterns.
|
||||
---
|
||||
|
||||
# Standalone Component Migrator
|
||||
|
||||
## Overview
|
||||
|
||||
Automate the conversion of Angular components from NgModule-based architecture to standalone components with explicit imports. This skill analyzes component dependencies, updates routing configurations, migrates tests, and optionally converts to modern Angular control flow syntax (@if, @for, @switch).
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke this skill when:
|
||||
- User requests component conversion to standalone
|
||||
- User mentions "migrate to standalone" or "modernize component"
|
||||
- User wants to remove NgModule declarations
|
||||
- User references Angular's standalone component architecture
|
||||
|
||||
## Migration Workflow
|
||||
|
||||
### Step 1: Analyze Component Dependencies
|
||||
|
||||
1. **Read Component File**
|
||||
- Identify component decorator configuration
|
||||
- Note selector, template path, style paths
|
||||
- Check if already standalone
|
||||
|
||||
2. **Analyze Template**
|
||||
- Read template file (HTML)
|
||||
- Scan for directives: `*ngIf`, `*ngFor`, `*ngSwitch` → requires CommonModule
|
||||
- Scan for forms: `ngModel`, `formControl` → requires FormsModule or ReactiveFormsModule
|
||||
- Scan for built-in pipes: `async`, `date`, `json` → CommonModule
|
||||
- Scan for custom components: identify all component selectors
|
||||
- Scan for router directives: `routerLink`, `router-outlet` → RouterModule
|
||||
|
||||
3. **Find Parent NgModule**
|
||||
- Search for NgModule that declares this component
|
||||
- Read NgModule file to understand current imports
|
||||
|
||||
### Step 2: Convert Component to Standalone
|
||||
|
||||
Add `standalone: true` and explicit imports array:
|
||||
|
||||
```typescript
|
||||
// BEFORE
|
||||
import { Component } from '@angular/core';
|
||||
|
||||
@Component({
|
||||
selector: 'app-my-component',
|
||||
templateUrl: './my-component.component.html'
|
||||
})
|
||||
export class MyComponent { }
|
||||
|
||||
// AFTER
|
||||
import { Component } from '@angular/core';
|
||||
import { CommonModule } from '@angular/common';
|
||||
import { FormsModule } from '@angular/forms';
|
||||
import { RouterModule } from '@angular/router';
|
||||
import { ChildComponent } from './child.component';
|
||||
import { CustomPipe } from '@isa/utils/pipes';
|
||||
|
||||
@Component({
|
||||
selector: 'app-my-component',
|
||||
standalone: true,
|
||||
imports: [
|
||||
CommonModule,
|
||||
FormsModule,
|
||||
RouterModule,
|
||||
ChildComponent,
|
||||
CustomPipe
|
||||
],
|
||||
templateUrl: './my-component.component.html'
|
||||
})
|
||||
export class MyComponent { }
|
||||
```
|
||||
|
||||
### Step 3: Update Parent NgModule
|
||||
|
||||
Remove component from declarations, add to imports if exported:
|
||||
|
||||
```typescript
|
||||
// BEFORE
|
||||
@NgModule({
|
||||
declarations: [MyComponent, OtherComponent],
|
||||
imports: [CommonModule],
|
||||
exports: [MyComponent]
|
||||
})
|
||||
|
||||
// AFTER
|
||||
@NgModule({
|
||||
declarations: [OtherComponent],
|
||||
imports: [CommonModule, MyComponent], // Import standalone component
|
||||
exports: [MyComponent]
|
||||
})
|
||||
```
|
||||
|
||||
If NgModule becomes empty (no declarations), consider removing it entirely.
|
||||
|
||||
### Step 4: Update Routes (if applicable)
|
||||
|
||||
Convert to lazy-loaded standalone component:
|
||||
|
||||
```typescript
|
||||
// BEFORE
|
||||
const routes: Routes = [
|
||||
{ path: 'feature', component: MyComponent }
|
||||
];
|
||||
|
||||
// AFTER (lazy loading)
|
||||
const routes: Routes = [
|
||||
{
|
||||
path: 'feature',
|
||||
loadComponent: () => import('./my-component.component').then(m => m.MyComponent)
|
||||
}
|
||||
];
|
||||
```
|
||||
|
||||
### Step 5: Update Tests
|
||||
|
||||
Convert test configuration:
|
||||
|
||||
```typescript
|
||||
// BEFORE
|
||||
TestBed.configureTestingModule({
|
||||
declarations: [MyComponent],
|
||||
imports: [CommonModule, FormsModule]
|
||||
});
|
||||
|
||||
// AFTER
|
||||
TestBed.configureTestingModule({
|
||||
imports: [MyComponent] // Component imports its own dependencies
|
||||
});
|
||||
```
|
||||
|
||||
### Step 6: Optional - Migrate to Modern Control Flow
|
||||
|
||||
If requested, convert to new Angular control flow syntax:
|
||||
|
||||
```typescript
|
||||
// OLD
|
||||
<div *ngIf="condition">Content</div>
|
||||
<div *ngFor="let item of items; trackBy: trackById">{{ item.name }}</div>
|
||||
<div [ngSwitch]="value">
|
||||
<div *ngSwitchCase="'a'">A</div>
|
||||
<div *ngSwitchDefault>Default</div>
|
||||
</div>
|
||||
|
||||
// NEW
|
||||
@if (condition) {
|
||||
<div>Content</div>
|
||||
}
|
||||
@for (item of items; track item.id) {
|
||||
<div>{{ item.name }}</div>
|
||||
}
|
||||
@switch (value) {
|
||||
@case ('a') { <div>A</div> }
|
||||
@default { <div>Default</div> }
|
||||
}
|
||||
```
|
||||
|
||||
### Step 7: Validate and Test
|
||||
|
||||
1. **Compile Check**
|
||||
```bash
|
||||
npx tsc --noEmit
|
||||
```
|
||||
|
||||
2. **Run Tests**
|
||||
```bash
|
||||
npx nx test [library-name] --skip-nx-cache
|
||||
```
|
||||
|
||||
3. **Lint Check**
|
||||
```bash
|
||||
npx nx lint [library-name]
|
||||
```
|
||||
|
||||
4. **Verify Application Runs**
|
||||
```bash
|
||||
npm start
|
||||
```
|
||||
|
||||
## Common Import Patterns
|
||||
|
||||
| Template Usage | Required Import |
|
||||
|---------------|-----------------|
|
||||
| `*ngIf`, `*ngFor`, `*ngSwitch` | `CommonModule` |
|
||||
| `ngModel` | `FormsModule` |
|
||||
| `formControl`, `formGroup` | `ReactiveFormsModule` |
|
||||
| `routerLink`, `router-outlet` | `RouterModule` |
|
||||
| `async`, `date`, `json` pipes | `CommonModule` |
|
||||
| Custom components | Direct component import |
|
||||
| Custom pipes | Direct pipe import |
|
||||
|
||||
## Error Handling
|
||||
|
||||
**Issue: Circular dependencies**
|
||||
- Extract shared interfaces to util library
|
||||
- Use dependency injection for services
|
||||
- Avoid component A importing component B when B imports A
|
||||
|
||||
**Issue: Missing imports causing template errors**
|
||||
- Check browser console for specific errors
|
||||
- Verify all template dependencies are in imports array
|
||||
- Use Angular Language Service in IDE for hints
|
||||
|
||||
## References
|
||||
|
||||
- Angular Standalone Components: https://angular.dev/guide/components/importing
|
||||
- Modern Control Flow: https://angular.dev/guide/templates/control-flow
|
||||
- CLAUDE.md Component Architecture section
|
||||
134
.claude/skills/swagger-sync-manager/SKILL.md
Normal file
134
.claude/skills/swagger-sync-manager/SKILL.md
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
name: swagger-sync-manager
|
||||
description: This skill should be used when regenerating Swagger/OpenAPI TypeScript API clients in the ISA-Frontend monorepo. It handles generation of all 10 API clients (or specific ones), Unicode cleanup, breaking change detection, TypeScript validation, and affected test execution. Use this skill when the user requests API sync, mentions "regenerate swagger", or indicates backend API changes.
|
||||
---
|
||||
|
||||
# Swagger Sync Manager
|
||||
|
||||
## Overview
|
||||
|
||||
Automate the regeneration of TypeScript API clients from Swagger/OpenAPI specifications. Handles 10 API clients with automatic post-processing, breaking change detection, impact analysis, and validation.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke when user requests:
|
||||
- API client regeneration
|
||||
- "sync swagger" or "update API clients"
|
||||
- Backend API changes need frontend updates
|
||||
|
||||
## Available APIs
|
||||
|
||||
availability-api, cat-search-api, checkout-api, crm-api, eis-api, inventory-api, isa-api, oms-api, print-api, wws-api
|
||||
|
||||
## Sync Workflow
|
||||
|
||||
### Step 1: Pre-Generation Check
|
||||
|
||||
```bash
|
||||
# Check uncommitted changes
|
||||
git status generated/swagger/
|
||||
```
|
||||
|
||||
If changes exist, warn user and ask to proceed.
|
||||
|
||||
### Step 2: Backup Current State (Optional)
|
||||
|
||||
```bash
|
||||
cp -r generated/swagger generated/swagger.backup.$(date +%s)
|
||||
```
|
||||
|
||||
### Step 3: Run Generation
|
||||
|
||||
```bash
|
||||
# All APIs
|
||||
npm run generate:swagger
|
||||
|
||||
# Specific API (if api-name provided)
|
||||
npm run generate:swagger:[api-name]
|
||||
```
|
||||
|
||||
### Step 4: Verify Unicode Cleanup
|
||||
|
||||
Check `tools/fix-files.js` executed. Scan for remaining Unicode issues:
|
||||
|
||||
```bash
|
||||
grep -r "\\\\u00" generated/swagger/ || echo "✅ No Unicode issues"
|
||||
```
|
||||
|
||||
### Step 5: Detect Breaking Changes
|
||||
|
||||
For each modified API:
|
||||
|
||||
```bash
|
||||
git diff generated/swagger/[api-name]/
|
||||
```
|
||||
|
||||
Identify:
|
||||
- 🔴 Removed properties
|
||||
- 🔴 Changed types
|
||||
- 🔴 Removed endpoints
|
||||
- ✅ Added properties (safe)
|
||||
- ✅ New endpoints (safe)
|
||||
|
||||
### Step 6: Impact Analysis
|
||||
|
||||
Use `Explore` agent to find affected files:
|
||||
- Search for imports from `@generated/swagger/[api-name]`
|
||||
- List data-access services using changed APIs
|
||||
- Estimate refactoring scope
|
||||
|
||||
### Step 7: Validate
|
||||
|
||||
```bash
|
||||
# TypeScript compilation
|
||||
npx tsc --noEmit
|
||||
|
||||
# Run affected tests
|
||||
npx nx affected:test --skip-nx-cache
|
||||
|
||||
# Lint affected
|
||||
npx nx affected:lint
|
||||
```
|
||||
|
||||
### Step 8: Generate Report
|
||||
|
||||
```
|
||||
Swagger Sync Complete
|
||||
=====================
|
||||
|
||||
APIs Regenerated: [all | specific]
|
||||
Files Changed: XX
|
||||
Breaking Changes: XX
|
||||
|
||||
🔴 Breaking Changes
|
||||
-------------------
|
||||
- [API]: [Property removed/type changed]
|
||||
- Affected files: [list]
|
||||
|
||||
✅ Compatible Changes
|
||||
---------------------
|
||||
- [API]: [New properties/endpoints]
|
||||
|
||||
📊 Validation
|
||||
-------------
|
||||
TypeScript: ✅/❌
|
||||
Tests: XX/XX passing
|
||||
Lint: ✅/❌
|
||||
|
||||
💡 Next Steps
|
||||
-------------
|
||||
[Fix breaking changes / Deploy]
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
**Generation fails**: Check OpenAPI spec URLs in package.json
|
||||
|
||||
**Unicode cleanup fails**: Run `node tools/fix-files.js` manually
|
||||
|
||||
**TypeScript errors**: Review breaking changes, update affected services
|
||||
|
||||
## References
|
||||
|
||||
- CLAUDE.md API Integration section
|
||||
- package.json swagger generation scripts
|
||||
344
.claude/skills/test-migration-specialist/SKILL.md
Normal file
344
.claude/skills/test-migration-specialist/SKILL.md
Normal file
@@ -0,0 +1,344 @@
|
||||
---
|
||||
name: test-migration-specialist
|
||||
description: This skill should be used when migrating Angular libraries from Jest + Spectator to Vitest + Angular Testing Utilities. It handles test configuration updates, test file refactoring, mock pattern conversion, and validation. Use this skill when the user requests test framework migration, specifically for the 40 remaining Jest-based libraries in the ISA-Frontend monorepo.
|
||||
---
|
||||
|
||||
# Test Migration Specialist
|
||||
|
||||
## Overview
|
||||
|
||||
Automate the migration of Angular library tests from Jest + Spectator to Vitest + Angular Testing Utilities. This skill handles the complete migration workflow including configuration updates, test file refactoring, dependency management, and validation.
|
||||
|
||||
**Current Migration Status**: 40 libraries use Jest (65.6%), 21 libraries use Vitest (34.4%)
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke this skill when:
|
||||
- User requests test migration for a specific library
|
||||
- User mentions "migrate tests" or "Jest to Vitest"
|
||||
- User wants to update test framework for a library
|
||||
- User references the 40 remaining libraries to migrate
|
||||
|
||||
## Migration Workflow
|
||||
|
||||
### Step 1: Pre-Migration Analysis
|
||||
|
||||
Before making any changes, analyze the current state:
|
||||
|
||||
1. **Read Testing Guidelines**
|
||||
- Use `docs-researcher` agent to read `docs/guidelines/testing.md`
|
||||
- Understand migration patterns and best practices
|
||||
- Note JUnit and Cobertura configuration requirements
|
||||
|
||||
2. **Analyze Library Structure**
|
||||
- Read `libs/[path]/project.json` to identify current test executor
|
||||
- Count test files using Glob: `**/*.spec.ts`
|
||||
- Scan for Spectator usage patterns using Grep: `createComponentFactory|createServiceFactory|Spectator`
|
||||
- Identify complex mocking scenarios (ng-mocks, jest.mock patterns)
|
||||
|
||||
3. **Determine Library Depth**
|
||||
- Calculate directory levels from workspace root
|
||||
- This affects relative paths in vite.config.mts (../../../ vs ../../../../)
|
||||
|
||||
### Step 2: Update Test Configuration
|
||||
|
||||
Update the library's test configuration to use Vitest:
|
||||
|
||||
1. **Update project.json**
|
||||
Replace Jest executor with Vitest:
|
||||
```json
|
||||
{
|
||||
"test": {
|
||||
"executor": "@nx/vite:test",
|
||||
"options": {
|
||||
"configFile": "vite.config.mts"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. **Create vite.config.mts**
|
||||
Create configuration with JUnit and Cobertura reporters:
|
||||
```typescript
|
||||
/// <reference types='vitest' />
|
||||
import { defineConfig } from 'vite';
|
||||
import angular from '@analogjs/vite-plugin-angular';
|
||||
import { nxViteTsPaths } from '@nx/vite/plugins/nx-tsconfig-paths.plugin';
|
||||
import { nxCopyAssetsPlugin } from '@nx/vite/plugins/nx-copy-assets.plugin';
|
||||
|
||||
export default
|
||||
// @ts-expect-error - Vitest reporter tuple types have complex inference issues
|
||||
defineConfig(() => ({
|
||||
root: __dirname,
|
||||
cacheDir: '../../../node_modules/.vite/libs/[path]',
|
||||
plugins: [angular(), nxViteTsPaths(), nxCopyAssetsPlugin(['*.md'])],
|
||||
test: {
|
||||
watch: false,
|
||||
globals: true,
|
||||
environment: 'jsdom',
|
||||
include: ['{src,tests}/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
|
||||
setupFiles: ['src/test-setup.ts'],
|
||||
reporters: [
|
||||
'default',
|
||||
['junit', { outputFile: '../../../testresults/junit-[library-name].xml' }],
|
||||
],
|
||||
coverage: {
|
||||
reportsDirectory: '../../../coverage/libs/[path]',
|
||||
provider: 'v8' as const,
|
||||
reporter: ['text', 'cobertura'],
|
||||
},
|
||||
},
|
||||
}));
|
||||
```
|
||||
|
||||
**Critical**: Adjust `../../../` depth based on library location
|
||||
|
||||
### Step 3: Migrate Test Files
|
||||
|
||||
For each `.spec.ts` file, perform these conversions:
|
||||
|
||||
1. **Update Imports**
|
||||
```typescript
|
||||
// REMOVE
|
||||
import { createComponentFactory, Spectator } from '@ngneat/spectator/jest';
|
||||
|
||||
// ADD
|
||||
import { ComponentFixture, TestBed } from '@angular/core/testing';
|
||||
import { describe, it, expect, beforeEach } from 'vitest';
|
||||
```
|
||||
|
||||
2. **Convert Component Tests**
|
||||
```typescript
|
||||
// OLD (Spectator)
|
||||
const createComponent = createComponentFactory({
|
||||
component: MyComponent,
|
||||
imports: [CommonModule],
|
||||
mocks: [MyService]
|
||||
});
|
||||
|
||||
let spectator: Spectator<MyComponent>;
|
||||
beforeEach(() => spectator = createComponent());
|
||||
|
||||
it('should display title', () => {
|
||||
spectator.setInput('title', 'Test');
|
||||
expect(spectator.query('h1')).toHaveText('Test');
|
||||
});
|
||||
|
||||
// NEW (Angular Testing Utilities)
|
||||
describe('MyComponent', () => {
|
||||
let fixture: ComponentFixture<MyComponent>;
|
||||
let component: MyComponent;
|
||||
|
||||
beforeEach(async () => {
|
||||
await TestBed.configureTestingModule({
|
||||
imports: [MyComponent, CommonModule],
|
||||
providers: [{ provide: MyService, useValue: mockService }]
|
||||
}).compileComponents();
|
||||
|
||||
fixture = TestBed.createComponent(MyComponent);
|
||||
component = fixture.componentInstance;
|
||||
});
|
||||
|
||||
it('should display title', () => {
|
||||
component.title = 'Test';
|
||||
fixture.detectChanges();
|
||||
expect(fixture.nativeElement.querySelector('h1').textContent).toContain('Test');
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
3. **Convert Service Tests**
|
||||
```typescript
|
||||
// OLD (Spectator)
|
||||
const createService = createServiceFactory({
|
||||
service: MyService,
|
||||
mocks: [HttpClient]
|
||||
});
|
||||
|
||||
// NEW (Angular Testing Utilities)
|
||||
describe('MyService', () => {
|
||||
let service: MyService;
|
||||
let httpMock: HttpTestingController;
|
||||
|
||||
beforeEach(() => {
|
||||
TestBed.configureTestingModule({
|
||||
imports: [HttpClientTestingModule],
|
||||
providers: [MyService]
|
||||
});
|
||||
|
||||
service = TestBed.inject(MyService);
|
||||
httpMock = TestBed.inject(HttpTestingController);
|
||||
});
|
||||
|
||||
afterEach(() => {
|
||||
httpMock.verify();
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
4. **Update Mock Patterns**
|
||||
- Replace `jest.fn()` → `vi.fn()`
|
||||
- Replace `jest.spyOn()` → `vi.spyOn()`
|
||||
- Replace `jest.mock()` → `vi.mock()`
|
||||
- For complex mocks, use `ng-mocks` library if needed
|
||||
|
||||
5. **Update Matchers**
|
||||
- Replace Spectator matchers (`toHaveText`, `toExist`) with standard Jest/Vitest matchers
|
||||
- Use `expect().toBeTruthy()`, `expect().toContain()`, etc.
|
||||
|
||||
### Step 4: Verify E2E Attributes
|
||||
|
||||
Check component templates for E2E testing attributes:
|
||||
|
||||
1. **Scan Templates**
|
||||
Use Grep to find templates: `**/*.html`
|
||||
|
||||
2. **Validate Attributes**
|
||||
Ensure interactive elements have:
|
||||
- `data-what`: Semantic description (e.g., "submit-button")
|
||||
- `data-which`: Unique identifier (e.g., "form-primary")
|
||||
- Dynamic `data-*` for list items: `[attr.data-item-id]="item.id"`
|
||||
|
||||
3. **Add Missing Attributes**
|
||||
If missing, add them to components. See `dev:add-e2e-attrs` command or use that skill.
|
||||
|
||||
### Step 5: Run Tests and Validate
|
||||
|
||||
Execute tests to verify migration:
|
||||
|
||||
1. **Run Tests**
|
||||
```bash
|
||||
npx nx test [library-name] --skip-nx-cache
|
||||
```
|
||||
|
||||
2. **Run with Coverage**
|
||||
```bash
|
||||
npx nx test [library-name] --coverage.enabled=true --skip-nx-cache
|
||||
```
|
||||
|
||||
3. **Verify Output Files**
|
||||
Check that CI/CD integration files are created:
|
||||
- JUnit XML: `testresults/junit-[library-name].xml`
|
||||
- Cobertura XML: `coverage/libs/[path]/cobertura-coverage.xml`
|
||||
|
||||
4. **Address Failures**
|
||||
If tests fail:
|
||||
- Review test conversion (common issues: missing fixture.detectChanges(), incorrect selectors)
|
||||
- Check mock configurations
|
||||
- Verify imports are correct
|
||||
- Ensure async tests use proper patterns
|
||||
|
||||
### Step 6: Clean Up
|
||||
|
||||
Remove legacy configurations:
|
||||
|
||||
1. **Remove Jest Files**
|
||||
- Delete `jest.config.ts` or `jest.config.js` if present
|
||||
- Remove Jest-specific setup files
|
||||
|
||||
2. **Update Dependencies**
|
||||
- Note if Spectator can be removed (check if other libs still use it)
|
||||
- Note if Jest can be removed (check if other libs still use it)
|
||||
- Don't actually remove from package.json unless all libs migrated
|
||||
|
||||
3. **Update Documentation**
|
||||
Update library README.md with new test commands:
|
||||
```markdown
|
||||
## Testing
|
||||
|
||||
This library uses Vitest + Angular Testing Utilities.
|
||||
|
||||
```bash
|
||||
# Run tests
|
||||
npx nx test [library-name] --skip-nx-cache
|
||||
|
||||
# Run with coverage
|
||||
npx nx test [library-name] --coverage.enabled=true --skip-nx-cache
|
||||
```
|
||||
```
|
||||
|
||||
### Step 7: Generate Migration Report
|
||||
|
||||
Provide comprehensive migration summary:
|
||||
|
||||
```
|
||||
Test Migration Complete
|
||||
=======================
|
||||
|
||||
Library: [library-name]
|
||||
Framework: Jest + Spectator → Vitest + Angular Testing Utilities
|
||||
|
||||
📊 Migration Statistics
|
||||
-----------------------
|
||||
Test files migrated: XX
|
||||
Component tests: XX
|
||||
Service tests: XX
|
||||
Total test cases: XX
|
||||
|
||||
✅ Test Results
|
||||
---------------
|
||||
Passing: XX/XX (100%)
|
||||
Coverage: XX%
|
||||
|
||||
📝 Configuration
|
||||
----------------
|
||||
- project.json: ✅ Updated to @nx/vite:test
|
||||
- vite.config.mts: ✅ Created with JUnit + Cobertura
|
||||
- E2E attributes: ✅ Validated
|
||||
|
||||
📁 CI/CD Integration
|
||||
--------------------
|
||||
- JUnit XML: ✅ testresults/junit-[name].xml
|
||||
- Cobertura XML: ✅ coverage/libs/[path]/cobertura-coverage.xml
|
||||
|
||||
🧹 Cleanup
|
||||
----------
|
||||
- Jest config removed: ✅
|
||||
- README updated: ✅
|
||||
|
||||
💡 Next Steps
|
||||
-------------
|
||||
1. Verify tests in CI/CD pipeline
|
||||
2. Monitor for any edge cases
|
||||
3. Consider migrating related libraries
|
||||
|
||||
📚 Remaining Libraries
|
||||
----------------------
|
||||
Jest libraries remaining: XX/40
|
||||
Progress: XX% complete
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Migration Issues
|
||||
|
||||
**Issue 1: Tests fail after migration**
|
||||
- Check `fixture.detectChanges()` is called after setting inputs
|
||||
- Verify async tests use `async/await` properly
|
||||
- Check component imports are correct (standalone components)
|
||||
|
||||
**Issue 2: Mocks not working**
|
||||
- Verify `vi.fn()` syntax is correct
|
||||
- Check providers array in TestBed configuration
|
||||
- For complex mocks, consider using `ng-mocks`
|
||||
|
||||
**Issue 3: Coverage files not generated**
|
||||
- Verify path depth in vite.config.mts matches library location
|
||||
- Check reporters array includes `'cobertura'`
|
||||
- Ensure `provider: 'v8'` is set
|
||||
|
||||
**Issue 4: Type errors in vite.config.mts**
|
||||
- Add `// @ts-expect-error` comment before `defineConfig()`
|
||||
- This is expected due to Vitest reporter type complexity
|
||||
|
||||
## References
|
||||
|
||||
Use `docs-researcher` agent to access:
|
||||
- `docs/guidelines/testing.md` - Comprehensive migration guide with examples
|
||||
- `CLAUDE.md` - Testing Framework section for project conventions
|
||||
|
||||
**Key Documentation Sections:**
|
||||
- Vitest Configuration with JUnit and Cobertura
|
||||
- Angular Testing Utilities examples
|
||||
- Migration patterns and best practices
|
||||
- E2E attribute requirements
|
||||
199
.claude/skills/type-safety-engineer/SKILL.md
Normal file
199
.claude/skills/type-safety-engineer/SKILL.md
Normal file
@@ -0,0 +1,199 @@
|
||||
---
|
||||
name: type-safety-engineer
|
||||
description: This skill should be used when improving TypeScript type safety by removing `any` types, adding Zod schemas for runtime validation, creating type guards, and strengthening strictness. Use this skill when the user wants to enhance type safety, mentions "fix any types", "add Zod validation", or requests type improvements for better code quality.
|
||||
---
|
||||
|
||||
# Type Safety Engineer
|
||||
|
||||
## Overview
|
||||
|
||||
Enhance TypeScript type safety by eliminating `any` types, adding Zod schemas for runtime validation, creating type guards, and strengthening compiler strictness.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Invoke when user wants to:
|
||||
- Remove `any` types
|
||||
- Add runtime validation with Zod
|
||||
- Improve type safety
|
||||
- Mentioned "type safety" or "Zod schemas"
|
||||
|
||||
## Type Safety Workflow
|
||||
|
||||
### Step 1: Scan for Issues
|
||||
|
||||
```bash
|
||||
# Find explicit any
|
||||
grep -r ": any" libs/ --include="*.ts" | grep -v ".spec.ts"
|
||||
|
||||
# Find functions without return types
|
||||
grep -r "^.*function.*{$" libs/ --include="*.ts" | grep -v ": "
|
||||
|
||||
# TypeScript strict mode check
|
||||
npx tsc --noEmit --strict
|
||||
```
|
||||
|
||||
### Step 2: Categorize Issues
|
||||
|
||||
**🔴 Critical:**
|
||||
- `any` in API response handling
|
||||
- `any` in service methods
|
||||
- `any` in store state types
|
||||
|
||||
**⚠️ Important:**
|
||||
- Missing return types
|
||||
- Untyped parameters
|
||||
- Weak types (`object`, `Function`)
|
||||
|
||||
**ℹ️ Moderate:**
|
||||
- `any` in test files
|
||||
- Loose array types
|
||||
|
||||
### Step 3: Add Zod Schemas for API Responses
|
||||
|
||||
```typescript
|
||||
import { z } from 'zod';
|
||||
|
||||
// Define schema
|
||||
const OrderItemSchema = z.object({
|
||||
productId: z.string().uuid(),
|
||||
quantity: z.number().int().positive(),
|
||||
price: z.number().positive()
|
||||
});
|
||||
|
||||
const OrderResponseSchema = z.object({
|
||||
id: z.string().uuid(),
|
||||
status: z.enum(['pending', 'confirmed', 'shipped']),
|
||||
items: z.array(OrderItemSchema),
|
||||
createdAt: z.string().datetime()
|
||||
});
|
||||
|
||||
// Infer TypeScript type
|
||||
type OrderResponse = z.infer<typeof OrderResponseSchema>;
|
||||
|
||||
// Runtime validation
|
||||
const order = OrderResponseSchema.parse(apiResponse);
|
||||
```
|
||||
|
||||
### Step 4: Replace `any` with Specific Types
|
||||
|
||||
**Pattern 1: Unknown + Type Guards**
|
||||
```typescript
|
||||
// BEFORE
|
||||
function processData(data: any) {
|
||||
return data.value;
|
||||
}
|
||||
|
||||
// AFTER
|
||||
function processData(data: unknown): string {
|
||||
if (!isValidData(data)) {
|
||||
throw new Error('Invalid data');
|
||||
}
|
||||
return data.value;
|
||||
}
|
||||
|
||||
function isValidData(data: unknown): data is { value: string } {
|
||||
return typeof data === 'object' && data !== null && 'value' in data;
|
||||
}
|
||||
```
|
||||
|
||||
**Pattern 2: Generic Types**
|
||||
```typescript
|
||||
// BEFORE
|
||||
function findById(items: any[], id: string): any {
|
||||
return items.find(item => item.id === id);
|
||||
}
|
||||
|
||||
// AFTER
|
||||
function findById<T extends { id: string }>(items: T[], id: string): T | undefined {
|
||||
return items.find(item => item.id === id);
|
||||
}
|
||||
```
|
||||
|
||||
### Step 5: Add Type Guards for API Data
|
||||
|
||||
```typescript
|
||||
export function isOrderResponse(data: unknown): data is OrderResponse {
|
||||
try {
|
||||
OrderResponseSchema.parse(data);
|
||||
return true;
|
||||
} catch {
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
// Use in service
|
||||
getOrder(id: string): Observable<OrderResponse> {
|
||||
return this.http.get(`/api/orders/${id}`).pipe(
|
||||
map(response => {
|
||||
if (!isOrderResponse(response)) {
|
||||
throw new Error('Invalid API response');
|
||||
}
|
||||
return response;
|
||||
})
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### Step 6: Validate Changes
|
||||
|
||||
```bash
|
||||
npx tsc --noEmit --strict
|
||||
npx nx affected:test --skip-nx-cache
|
||||
npx nx affected:lint
|
||||
```
|
||||
|
||||
### Step 7: Generate Report
|
||||
|
||||
```
|
||||
Type Safety Improvements
|
||||
========================
|
||||
|
||||
Path: [analyzed path]
|
||||
|
||||
🔍 Issues Found
|
||||
---------------
|
||||
`any` usages: XX → 0
|
||||
Missing return types: XX → 0
|
||||
Untyped parameters: XX → 0
|
||||
|
||||
✅ Improvements
|
||||
---------------
|
||||
- Added Zod schemas: XX
|
||||
- Created type guards: XX
|
||||
- Fixed `any` types: XX
|
||||
- Added return types: XX
|
||||
|
||||
📈 Type Safety Score
|
||||
--------------------
|
||||
Before: XX%
|
||||
After: XX% (+XX%)
|
||||
|
||||
💡 Recommendations
|
||||
------------------
|
||||
1. Enable stricter TypeScript options
|
||||
2. Add validation to remaining APIs
|
||||
```
|
||||
|
||||
## Common Patterns
|
||||
|
||||
**API Response Validation:**
|
||||
```typescript
|
||||
const schema = z.object({...});
|
||||
type Type = z.infer<typeof schema>;
|
||||
|
||||
return this.http.get<unknown>(url).pipe(
|
||||
map(response => schema.parse(response))
|
||||
);
|
||||
```
|
||||
|
||||
**Event Handlers:**
|
||||
```typescript
|
||||
// BEFORE: onClick(event: any)
|
||||
// AFTER: onClick(event: MouseEvent)
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
- Use `docs-researcher` for latest Zod documentation
|
||||
- Zod: https://zod.dev
|
||||
- TypeScript strict mode: https://www.typescriptlang.org/tsconfig#strict
|
||||
6
.gitignore
vendored
6
.gitignore
vendored
@@ -58,7 +58,11 @@ libs/swagger/src/lib/*
|
||||
.nx/cache
|
||||
.nx/workspace-data
|
||||
.angular
|
||||
.claude
|
||||
# Claude configuration
|
||||
.claude/*
|
||||
!.claude/agents
|
||||
!.claude/commands
|
||||
!.claude/skills
|
||||
|
||||
|
||||
storybook-static
|
||||
|
||||
148
CLAUDE.md
148
CLAUDE.md
@@ -6,6 +6,16 @@
|
||||
> **Node.js:** ≥22.0.0
|
||||
> **npm:** ≥10.0.0
|
||||
|
||||
## 🔴 CRITICAL: Mandatory Agent Usage
|
||||
|
||||
**You MUST use these subagents for ALL research tasks:**
|
||||
- **`docs-researcher`**: For ALL documentation (packages, libraries, READMEs)
|
||||
- **`docs-researcher-advanced`**: Auto-escalate when docs-researcher fails
|
||||
- **`Explore`**: For ALL code pattern searches and multi-file analysis
|
||||
- **Direct tools (Read/Bash)**: ONLY for single specific files or commands
|
||||
|
||||
**Violations of this rule degrade performance and context quality. NO EXCEPTIONS.**
|
||||
|
||||
## Project Overview
|
||||
|
||||
This is a sophisticated Angular 20.1.2 monorepo managed by Nx 21.3.2. The main application is `isa-app`, a comprehensive inventory and returns management system for retail/e-commerce operations. The system handles complex workflows including order management (OMS), returns processing (remission), customer relationship management (CRM), product cataloging, and checkout/reward systems.
|
||||
@@ -32,7 +42,7 @@ This is a sophisticated Angular 20.1.2 monorepo managed by Nx 21.3.2. The main a
|
||||
- **Standalone Components**: All new components use Angular standalone architecture with explicit imports
|
||||
- **Feature Libraries**: Domain features organized as separate libraries (e.g., `oms-feature-return-search`, `remission-feature-remission-list`)
|
||||
- **Data Access Layer**: Separate data-access libraries for each domain with NgRx Signals stores
|
||||
- **Shared UI Components**: 18 dedicated UI component libraries with design system integration
|
||||
- **Shared UI Components**: 17 dedicated UI component libraries with design system integration
|
||||
- **Generated API Clients**: 10 auto-generated Swagger/OpenAPI clients with post-processing pipeline
|
||||
- **Path Aliases**: Comprehensive TypeScript path mapping (`@isa/domain/layer/feature`)
|
||||
- **Component Prefixes**: Domain-specific prefixes (OMS: `oms-feature-*`, Remission: `remi-*`, UI: `ui-*`)
|
||||
@@ -96,9 +106,9 @@ npx nx affected:test --skip-nx-cache
|
||||
> **Status:** Migration in Progress (Jest → Vitest)
|
||||
|
||||
### Current Setup (Migration in Progress)
|
||||
- **Jest**: 31 libraries (legacy/existing code)
|
||||
- **Vitest**: 10 libraries (new standard)
|
||||
- **No test executor**: 20 libraries (mostly feature/shared components)
|
||||
- **Jest**: 40 libraries (65.6% - legacy/existing code)
|
||||
- **Vitest**: 21 libraries (34.4% - new standard)
|
||||
- All formal libraries now have test executors configured
|
||||
|
||||
### Testing Strategy
|
||||
- **New libraries**: Use Vitest + Angular Testing Utilities (TestBed, ComponentFixture)
|
||||
@@ -135,7 +145,7 @@ npx nx affected:test --skip-nx-cache
|
||||
- **Brand Color System**: `isa-*` color palette with semantic naming
|
||||
- **Custom Tailwind Plugins** (7): button, typography, menu, label, input, section, select-bullet
|
||||
- **Typography System**: 14 custom utilities (`.isa-text-heading-1-bold`, `.isa-text-body-2-regular`, etc.)
|
||||
- **UI Component Libraries**: 18 specialized libraries with consistent APIs (see Library Reference)
|
||||
- **UI Component Libraries**: 17 specialized libraries with consistent APIs (see Library Reference)
|
||||
- **Storybook**: Component documentation and development at `npm run storybook`
|
||||
|
||||
### Responsive Design with Breakpoint Service
|
||||
@@ -252,115 +262,71 @@ isDesktop = breakpoint([Breakpoint.Desktop, Breakpoint.DekstopL, Breakpoint.Deks
|
||||
|
||||
### Researching and Investigating the Codebase
|
||||
|
||||
**🚨 CRITICAL: Always Research Before Implementation**
|
||||
**🔴 MANDATORY: You MUST use subagents for research. Direct file reading/searching is FORBIDDEN except for single specific files.**
|
||||
|
||||
**NEVER assume you know the answer - AI models are never up-to-date:**
|
||||
- Before working on ANY problem, research the needed information and documentation
|
||||
- Even if you think you know how something works, verify with current documentation
|
||||
- Use `docs-researcher` to check library READMEs, `/docs` files, and API documentation
|
||||
- Use `Explore` to verify how similar features are currently implemented
|
||||
- Your training data has a cutoff - the actual codebase is the source of truth
|
||||
#### Required Agent Usage
|
||||
|
||||
**🚨 CRITICAL: Keep Main Context Clean - Always Use Subagents**
|
||||
| Task Type | Required Agent | Escalation Path |
|
||||
|-----------|---------------|-----------------|
|
||||
| **Package/Library Documentation** | `docs-researcher` | → `docs-researcher-advanced` if not found |
|
||||
| **Internal Library READMEs** | `docs-researcher` | Keep context clean |
|
||||
| **Code Pattern Search** | `Explore` | Set thoroughness level |
|
||||
| **Implementation Analysis** | `Explore` | Multiple file analysis |
|
||||
| **Single Specific File** | Read tool directly | No agent needed |
|
||||
|
||||
**When to use `docs-researcher` subagent:**
|
||||
- Reading and analyzing library READMEs
|
||||
- Searching and extracting information from `/docs` directory
|
||||
- Analyzing library documentation when unclear
|
||||
- Understanding API documentation and usage patterns
|
||||
- Any documentation-heavy research task
|
||||
#### Documentation Research System (Two-Tier)
|
||||
|
||||
**When to use `Explore` subagent:**
|
||||
- Searching for patterns across the codebase
|
||||
- Finding similar implementations
|
||||
- Exploring component structures
|
||||
- Discovering how features are implemented
|
||||
- Any task requiring multiple file reads/searches
|
||||
1. **ALWAYS start with `docs-researcher`** (Haiku, 30-120s) for any documentation need
|
||||
2. **Auto-escalate to `docs-researcher-advanced`** (Sonnet, 2-7min) when:
|
||||
- Documentation not found
|
||||
- Conflicting sources
|
||||
- Need code inference
|
||||
- Complex architectural questions
|
||||
|
||||
**General Approach:**
|
||||
1. **ALWAYS research first** - Never assume you know the answer, verify with current documentation
|
||||
2. **Start with the Library Reference Guide** (see below) for quick library lookup
|
||||
3. **Use `docs-researcher` for ALL documentation research** - Keeps main context clean
|
||||
4. **Use `Explore` for codebase exploration** - Prevents context pollution during searches
|
||||
5. **Use Nx tools for architecture visualization** - `npx nx graph` to understand dependencies
|
||||
6. **Follow error messages** - TypeScript/runtime errors point to exact locations
|
||||
#### Enforcement Examples
|
||||
|
||||
**Finding Information by Type:**
|
||||
|
||||
| What are you looking for? | Where to search | How |
|
||||
|---------------------------|-----------------|-----|
|
||||
| **A specific library's purpose** | Library Reference Guide (below) | Look up by domain/name |
|
||||
| **How to use a library** | `libs/[domain]/[layer]/[feature]/README.md` | **Use `docs-researcher` subagent** |
|
||||
| **Project guidelines** | `/docs` directory | **Use `docs-researcher` subagent** |
|
||||
| **Project dependencies** | `npx nx graph` | Visualize which projects depend on which |
|
||||
| **Similar existing implementations** | Across codebase | **Use `Explore` subagent** to find patterns |
|
||||
| **Component structure** | Domain-specific feature folders | **Use `Explore` subagent** for deep dives |
|
||||
| **State management patterns** | `libs/[domain]/data-access/` | **Use `Explore` subagent** to find stores |
|
||||
| **API integration examples** | `generated/swagger/` + data-access | **Use `Explore` subagent** to find usage |
|
||||
| **Styling/Design tokens** | `tailwind.config.js` + `tailwind-plugins/` | **Use `Explore` subagent** for patterns |
|
||||
| **Error handling patterns** | `libs/common/data-access/` | **Use `Explore` subagent** to find operators |
|
||||
| **UI components** | `libs/ui/[component]/README.md` | **Use `docs-researcher` or Storybook** |
|
||||
|
||||
**Effective Subagent Usage:**
|
||||
|
||||
**Using `docs-researcher` subagent (for documentation):**
|
||||
```
|
||||
Task: Read and analyze README.md for @isa/[domain]/[layer]/[feature]
|
||||
Focus on: Purpose, main exports, usage patterns, dependencies, examples
|
||||
❌ WRONG: Read libs/ui/buttons/README.md
|
||||
✅ RIGHT: Task → docs-researcher → "Find documentation for @isa/ui/buttons"
|
||||
|
||||
Task: Search /docs for testing guidelines
|
||||
Focus on: Extract relevant sections about Jest/Vitest migration
|
||||
❌ WRONG: Grep for "signalStore" patterns
|
||||
✅ RIGHT: Task → Explore → "Find all signalStore implementations"
|
||||
|
||||
Task: Analyze library documentation when API is unclear
|
||||
Focus on: Clarify usage patterns, parameters, return types
|
||||
❌ WRONG: WebSearch for Zod documentation
|
||||
✅ RIGHT: Task → docs-researcher → "Find Zod validation documentation"
|
||||
```
|
||||
|
||||
**Using `Explore` subagent (for codebase):**
|
||||
```
|
||||
Task: Find all implementations of error handling patterns
|
||||
Thoroughness: "medium" or "very thorough" depending on complexity
|
||||
**Remember: Using subagents is NOT optional - it's mandatory for maintaining context efficiency and search quality.**
|
||||
|
||||
Task: Search for similar component structures in remission domain
|
||||
Thoroughness: "medium"
|
||||
#### Common Research Patterns
|
||||
|
||||
Task: Discover how NgRx Signals stores are used across data-access libraries
|
||||
Thoroughness: "very thorough"
|
||||
```
|
||||
| Information Need | Required Approach |
|
||||
|-----------------|-------------------|
|
||||
| **Library documentation** | `docs-researcher` → Check library-reference.md → Escalate if needed |
|
||||
| **Code patterns/examples** | `Explore` with "medium" or "very thorough" |
|
||||
| **Architecture understanding** | `npx nx graph` + `Explore` for implementation |
|
||||
| **Debugging/errors** | Direct tool use (Read specific error file, check console) |
|
||||
|
||||
**Using Nx tools (for architecture):**
|
||||
```
|
||||
- Run: npx nx graph --filter=[project-name]
|
||||
- Look at which projects this one depends on (imports from)
|
||||
- Look at which projects depend on it (things that import from it)
|
||||
- This shows you the dependency chain and data flow
|
||||
```
|
||||
|
||||
**Debugging Tips:**
|
||||
- **TypeScript errors**: Follow the error path - it points to the exact file and line
|
||||
- **Runtime errors**: Check browser console (F12) and network tab for API issues
|
||||
- **Test failures**: Use `--skip-nx-cache` to get fresh test output with full error details
|
||||
- **Module resolution**: Check `tsconfig.base.json` path aliases to understand import resolution
|
||||
- **State issues**: Use Angular DevTools browser extension to inspect NgRx state
|
||||
#### Debugging Tips
|
||||
- **TypeScript errors**: Follow error path to exact file:line
|
||||
- **Test failures**: Use `--skip-nx-cache` for fresh output
|
||||
- **Module resolution**: Check `tsconfig.base.json` path aliases
|
||||
- **State issues**: Use Angular DevTools browser extension
|
||||
|
||||
### Library Development Patterns
|
||||
- **Understanding Internal Libraries**: Before using any internal library from the `libs/` directory, always read its README.md file using the **`docs-researcher` subagent** to understand its purpose, API, and proper usage patterns
|
||||
- **Library Documentation**: All libraries have comprehensive README.md documentation. **To keep main context clean, ALWAYS use the `docs-researcher` subagent** to retrieve and analyze library documentation rather than reading files directly
|
||||
- **Library Documentation**: Use `docs-researcher` for ALL library READMEs (mandatory for context management)
|
||||
- **New Library Creation**: Use Nx generators with domain-specific naming (`[domain]-[layer]-[feature]`)
|
||||
- **Standalone Components**: All new components must be standalone with explicit imports - no more NgModules
|
||||
- **Testing Framework Selection**:
|
||||
- **New libraries**: Use Vitest + Angular Testing Utilities
|
||||
- **Existing libraries**: Continue with Jest + Spectator until migrated
|
||||
- **Path Aliases**: Always use `@isa/[domain]/[layer]/[feature]` - avoid relative imports across domain boundaries
|
||||
- **Standalone Components**: All new components must be standalone with explicit imports - no NgModules
|
||||
- **Testing Framework**: New = Vitest + Angular Testing Utilities, Legacy = Jest + Spectator
|
||||
- **Path Aliases**: Always use `@isa/[domain]/[layer]/[feature]` - avoid relative imports
|
||||
|
||||
#### Library Reference Guide
|
||||
|
||||
The monorepo contains **61 libraries** organized across 12 domains. For quick lookup of any library's purpose and location, see **[`docs/library-reference.md`](docs/library-reference.md)**.
|
||||
The monorepo contains **62 libraries** organized across 12 domains. For quick lookup, see **[`docs/library-reference.md`](docs/library-reference.md)**.
|
||||
|
||||
**Quick Overview by Domain:**
|
||||
- Availability (1) | Catalogue (1) | Checkout (6) | Common (3) | Core (5) | CRM (1) | Icons (1)
|
||||
- OMS (9) | Remission (8) | Shared Components (7) | UI Components (16) | Utilities (3)
|
||||
|
||||
**IMPORTANT: Always use the `docs-researcher` subagent** to retrieve and analyze library documentation from `libs/[domain]/[layer]/[feature]/README.md`. This keeps the main context clean and prevents pollution
|
||||
- OMS (9) | Remission (8) | Shared Components (7) | UI Components (17) | Utilities (3)
|
||||
|
||||
### API Integration Workflow
|
||||
- **Swagger Generation**: Run `npm run generate:swagger` to regenerate all 10 API clients when backend changes
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -59,6 +59,8 @@ This document outlines the guidelines and best practices for writing unit tests
|
||||
|
||||
- Test files must end with `.spec.ts`.
|
||||
- **Migration to Vitest**: New libraries should use **Vitest** as the primary test runner. Existing libraries continue to use **Jest** until migrated.
|
||||
- **Current Status (as of 2025-10-22):** 40 libraries use Jest (65.6%), 21 libraries use Vitest (34.4%)
|
||||
- All formal libraries now have test executors configured (migration progressing well)
|
||||
- **Testing Framework Migration**: New tests should use **Angular Testing Utilities** (TestBed, ComponentFixture, etc.). Existing tests using **Spectator** remain until migrated.
|
||||
- Employ **ng-mocks** for mocking complex dependencies like child components.
|
||||
|
||||
|
||||
@@ -1,7 +1,135 @@
|
||||
# checkout-feature-reward-order-confirmation
|
||||
|
||||
This library was generated with [Nx](https://nx.dev).
|
||||
## Overview
|
||||
|
||||
## Running unit tests
|
||||
The `@isa/checkout/feature/reward-order-confirmation` library provides the **reward order confirmation screen** displayed after customers complete a loyalty reward redemption purchase. It shows a comprehensive summary of completed reward orders, including shipping/billing addresses, product details, loyalty points used, and delivery method information.
|
||||
|
||||
Run `nx test checkout-feature-reward-order-confirmation` to execute the unit tests.
|
||||
**Type:** Routed feature library with lazy-loaded components
|
||||
|
||||
## Features
|
||||
|
||||
- **Multi-Order Support**: Display multiple orders from a single shopping cart session
|
||||
- **Order Type Awareness**: Conditional display based on delivery method (Delivery, Pickup, In-Store)
|
||||
- **Address Deduplication**: Smart handling of duplicate addresses across multiple orders
|
||||
- **Loyalty Points Display**: Shows loyalty points (Lesepunkte) used for each reward item
|
||||
- **Product Information**: Comprehensive product details including name, contributors, EAN, and quantity
|
||||
- **Destination Information**: Delivery/pickup destination details
|
||||
|
||||
## Main Components
|
||||
|
||||
### RewardOrderConfirmationComponent (Main Container)
|
||||
- **Selector:** `checkout-reward-order-confirmation`
|
||||
- **Route:** `/:orderIds` (accepts multiple order IDs separated by `+`)
|
||||
- Orchestrates the entire confirmation view
|
||||
- Manages state via `OrderConfiramtionStore`
|
||||
|
||||
### OrderConfirmationHeaderComponent
|
||||
- **Selector:** `checkout-order-confirmation-header`
|
||||
- Displays header: "Prämienausgabe abgeschlossen" (Reward distribution completed)
|
||||
|
||||
### OrderConfirmationAddressesComponent
|
||||
- **Selector:** `checkout-order-confirmation-addresses`
|
||||
- Displays billing addresses, shipping addresses, and pickup branch information
|
||||
- Conditionally shows sections based on order type
|
||||
|
||||
### OrderConfirmationItemListComponent
|
||||
- **Selector:** `checkout-order-confirmation-item-list`
|
||||
- Displays order type badge with icon (Delivery/Pickup/In-Store)
|
||||
- Renders list of order items for each order
|
||||
|
||||
### OrderConfirmationItemListItemComponent
|
||||
- **Selector:** `checkout-order-confirmation-item-list-item`
|
||||
- Displays individual product information, quantity, loyalty points, and destination info
|
||||
|
||||
### ConfirmationListItemActionCardComponent
|
||||
- **Selector:** `checkout-confirmation-list-item-action-card`
|
||||
- Placeholder component for future action functionality
|
||||
|
||||
## State Management
|
||||
|
||||
**OrderConfiramtionStore** (NgRx Signals)
|
||||
|
||||
**State:**
|
||||
- `tabId`: Current tab identifier
|
||||
- `orderIds`: Array of order IDs to display
|
||||
|
||||
**Computed Properties:**
|
||||
- `orders`: Filtered display orders from OMS metadata service
|
||||
- `shoppingCart`: Associated completed shopping cart
|
||||
- `payers`: Deduplicated billing addressees
|
||||
- `shippingAddresses`: Deduplicated shipping addressees
|
||||
- `targetBranches`: Deduplicated pickup branches
|
||||
- `hasDeliveryOrderTypeFeature`: Boolean indicating delivery orders
|
||||
- `hasTargetBranchFeature`: Boolean indicating pickup/in-store orders
|
||||
|
||||
## Usage
|
||||
|
||||
### Routing Integration
|
||||
|
||||
```typescript
|
||||
// In parent routing module
|
||||
{
|
||||
path: 'reward-confirmation',
|
||||
loadChildren: () => import('@isa/checkout/feature/reward-order-confirmation')
|
||||
.then(m => m.routes)
|
||||
}
|
||||
```
|
||||
|
||||
### URL Structure
|
||||
|
||||
```
|
||||
/reward-confirmation/123+456+789
|
||||
```
|
||||
|
||||
This displays confirmation for orders with IDs 123, 456, and 789.
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Data Access:**
|
||||
- `@isa/oms/data-access` - Order metadata and models
|
||||
- `@isa/checkout/data-access` - Checkout metadata and order type utilities
|
||||
- `@isa/crm/data-access` - Address deduplication utilities
|
||||
|
||||
**Core:**
|
||||
- `@isa/core/tabs` - Tab context management
|
||||
|
||||
**Shared Components:**
|
||||
- `@isa/shared/address` - Address rendering
|
||||
- `@isa/checkout/shared/product-info` - Product and destination information
|
||||
|
||||
**UI:**
|
||||
- `@isa/icons` - Delivery method icons
|
||||
|
||||
## Data Flow
|
||||
|
||||
1. Route parameter (`orderIds`) is parsed into array of integers
|
||||
2. Store receives `tabId` from `TabService` and `orderIds` from route
|
||||
3. Store fetches orders from `OmsMetadataService` filtered by IDs
|
||||
4. Store fetches completed shopping cart from `CheckoutMetadataService`
|
||||
5. Components consume computed properties from store (addresses, order items, points)
|
||||
|
||||
## Order Type Support
|
||||
|
||||
The library supports three delivery methods with specific icons:
|
||||
|
||||
- **Delivery** (`isaDeliveryVersand`): Shows shipping addresses
|
||||
- **Pickup** (`isaDeliveryRuecklage2`): Shows pickup branch
|
||||
- **In-Store** (`isaDeliveryRuecklage1`): Shows store branch
|
||||
|
||||
## Testing
|
||||
|
||||
Run tests with Vitest:
|
||||
|
||||
```bash
|
||||
npx nx test checkout-feature-reward-order-confirmation --skip-nx-cache
|
||||
```
|
||||
|
||||
**Test Framework:** Vitest
|
||||
**Coverage Output:** `coverage/libs/checkout/feature/reward-order-confirmation`
|
||||
|
||||
## Architecture Notes
|
||||
|
||||
- **Component Prefix:** `checkout`
|
||||
- **Change Detection:** All components use `OnPush` strategy
|
||||
- **Standalone Architecture:** All components are standalone with explicit imports
|
||||
- **Project Name:** `checkout-feature-reward-order-confirmation`
|
||||
|
||||
@@ -1,11 +1,185 @@
|
||||
# icons
|
||||
|
||||
This library was generated with [Nx](https://nx.dev).
|
||||
## Overview
|
||||
|
||||
## Building
|
||||
The `@isa/icons` library is a centralized icon repository for the ISA Frontend monorepo. It provides **75 inline SVG icons** as string constants, organized by functional categories. All icons are exported as ready-to-use SVG markup strings that can be embedded directly in Angular templates.
|
||||
|
||||
Run `nx build icons` to build the library.
|
||||
## Icon Categories
|
||||
|
||||
## Running unit tests
|
||||
The library contains **9 distinct categories** of icons:
|
||||
|
||||
Run `nx test icons` to execute the unit tests via [Jest](https://jestjs.io).
|
||||
| Category | Count | Purpose | Examples |
|
||||
|----------|-------|---------|----------|
|
||||
| **Navigation** | 23 | Main navigation, UI controls, menu items | `isaNavigationSidemenu`, `isaNavigationCart`, `isaNavigationKunden` |
|
||||
| **Action** | 15 | User actions, buttons, interactive elements | `isaActionChevron`, `isaActionPlus`, `isaActionSearch`, `isaActionEdit` |
|
||||
| **Reviews** | 13 | Small-sized icons for reviews/ratings UI | `isaReviewsStarSmall`, `isaReviewsChevronSmall`, `isaReviewsCheckSmall` |
|
||||
| **Artikel** | 8 | Product format indicators | `isaArtikelTaschenbuch`, `isaArtikelCd`, `isaArtikelEbook`, `isaArtikelGame` |
|
||||
| **Delivery** | 7 | Delivery/fulfillment methods | `isaDeliveryWarenausgabe`, `isaDeliveryVersand`, `isaDeliveryDownload` |
|
||||
| **Other** | 3 | Miscellaneous UI elements | `isaOtherHeart`, `isaOtherGift`, `isaOtherInfo` |
|
||||
| **Sort** | 2 | Sorting indicators | `isaSortByUpMedium`, `isaSortByDownMedium` |
|
||||
| **Loading** | 2 | Loading/spinner animations | `isaLoading`, `isaLoadingSmall` |
|
||||
| **Filiale** | 2 | Store/branch location icons | `isaFiliale`, `isaFilialeLocation` |
|
||||
|
||||
## Icon Format & Technical Details
|
||||
|
||||
- **Format:** Inline SVG markup strings
|
||||
- **Size:** Most icons are 24×24px, with "Small" variants at 12×12px
|
||||
- **Style:** All icons use `fill="currentColor"` or `stroke="currentColor"` for easy color customization via CSS
|
||||
- **Naming Convention:** `isa[Category][Name]` (e.g., `isaActionChevron`, `isaNavigationCart`)
|
||||
|
||||
## Usage
|
||||
|
||||
### Import Individual Icons
|
||||
|
||||
```typescript
|
||||
import { isaActionSearch, isaNavigationCart } from '@isa/icons';
|
||||
|
||||
@Component({
|
||||
selector: 'app-my-component',
|
||||
template: `
|
||||
<div [innerHTML]="searchIcon"></div>
|
||||
<div [innerHTML]="cartIcon"></div>
|
||||
`,
|
||||
standalone: true,
|
||||
})
|
||||
export class MyComponent {
|
||||
searchIcon = isaActionSearch;
|
||||
cartIcon = isaNavigationCart;
|
||||
}
|
||||
```
|
||||
|
||||
### Import Icon Group
|
||||
|
||||
```typescript
|
||||
import { ProductFormatIconGroup } from '@isa/icons';
|
||||
|
||||
@Component({
|
||||
selector: 'app-product-display',
|
||||
template: `<div [innerHTML]="getProductIcon(product.format)"></div>`,
|
||||
standalone: true,
|
||||
})
|
||||
export class ProductDisplayComponent {
|
||||
getProductIcon(format: string): string {
|
||||
return ProductFormatIconGroup[format] || ProductFormatIconGroup['ka'];
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Import All Icons
|
||||
|
||||
```typescript
|
||||
import { IsaIcons } from '@isa/icons';
|
||||
|
||||
const searchIcon = IsaIcons.isaActionSearch;
|
||||
const cartIcon = IsaIcons.isaNavigationCart;
|
||||
```
|
||||
|
||||
## Color Customization
|
||||
|
||||
All icons use `currentColor`, allowing easy theming via CSS color inheritance:
|
||||
|
||||
```html
|
||||
<!-- Icon inherits text color from parent -->
|
||||
<div class="text-isa-accent-500" [innerHTML]="isaActionSearch"></div>
|
||||
|
||||
<!-- Icon inherits from inline style -->
|
||||
<div style="color: #FF5733;" [innerHTML]="isaNavigationCart"></div>
|
||||
```
|
||||
|
||||
## Icon Groups
|
||||
|
||||
### ProductFormatIconGroup
|
||||
|
||||
Maps product format codes to appropriate icons:
|
||||
|
||||
```typescript
|
||||
export const ProductFormatIconGroup = {
|
||||
tb: icons.isaArtikelTaschenbuch, // Taschenbuch (paperback)
|
||||
hc: icons.isaArtikelKartoniert, // Kartoniert (hardcover)
|
||||
au: icons.isaArtikelCd, // Audio CD
|
||||
ka: icons.isaArtikelSonstige, // Sonstige (other)
|
||||
sw: icons.isaArtikelCd, // Software CD
|
||||
nb: icons.isaArtikelGame, // Game
|
||||
};
|
||||
```
|
||||
|
||||
**Usage:**
|
||||
```typescript
|
||||
const icon = ProductFormatIconGroup['tb']; // Gets paperback icon
|
||||
```
|
||||
|
||||
## Available Icons
|
||||
|
||||
### Navigation Icons (23)
|
||||
- `isaNavigationSidemenu`, `isaNavigationCart`, `isaNavigationKunden`, `isaNavigationFilialen`
|
||||
- `isaNavigationRuecklage`, `isaNavigationRemission`, `isaNavigationWareneingang`, `isaNavigationWws`
|
||||
- `isaNavigationOrder`, `isaNavigationFile`, `isaNavigationDownload`, `isaNavigationPrint`
|
||||
- `isaNavigationCalendar`, `isaNavigationScan`, `isaNavigationSettings`, `isaNavigationHelp`
|
||||
- `isaNavigationLogout`, `isaNavigationHome`, `isaNavigationBack`, `isaNavigationForward`
|
||||
- `isaNavigationClose`, `isaNavigationMenu`, `isaNavigationMore`
|
||||
|
||||
### Action Icons (15)
|
||||
- `isaActionChevron` / `isaActionChevronDown`, `isaActionChevronUp`, `isaActionChevronLeft`, `isaActionChevronRight`
|
||||
- `isaActionPlus`, `isaActionMinus`, `isaActionSearch`, `isaActionEdit`, `isaActionDelete`
|
||||
- `isaActionSave`, `isaActionCancel`, `isaActionRefresh`, `isaActionFilter`, `isaActionExport`
|
||||
|
||||
### Reviews Icons (13)
|
||||
- `isaReviewsStarSmall`, `isaReviewsStarHalfSmall`, `isaReviewsStarEmptySmall`
|
||||
- `isaReviewsChevronSmall`, `isaReviewsCheckSmall`, `isaReviewsCloseSmall`
|
||||
- And 7 more small variants...
|
||||
|
||||
### Product Format Icons (8)
|
||||
- `isaArtikelTaschenbuch`, `isaArtikelKartoniert`, `isaArtikelCd`, `isaArtikelDvd`
|
||||
- `isaArtikelEbook`, `isaArtikelGame`, `isaArtikelSonstige`, `isaArtikelVinyl`
|
||||
|
||||
### Delivery Method Icons (7)
|
||||
- `isaDeliveryWarenausgabe`, `isaDeliveryVersand`, `isaDeliveryDownload`
|
||||
- `isaDeliveryRuecklage1`, `isaDeliveryRuecklage2`, `isaDeliveryAbholfach`
|
||||
- `isaDeliveryExpress`
|
||||
|
||||
## Size Variants
|
||||
|
||||
The library provides size variants for specific use cases:
|
||||
|
||||
- **Standard:** 24×24px (most icons)
|
||||
- **Small:** 12×12px (icons with `Small` suffix, e.g., `isaReviewsStarSmall`)
|
||||
|
||||
## Security Considerations
|
||||
|
||||
When using icons with `[innerHTML]`, Angular's DomSanitizer automatically handles security. However, if you bypass sanitization, ensure icons come from trusted sources.
|
||||
|
||||
## Performance Notes
|
||||
|
||||
- **Bundle Size:** All 75 icons are included in consuming bundles when imported
|
||||
- **Inline SVGs:** Avoid HTTP requests but increase bundle size
|
||||
- **Tree Shaking:** Only import the icons you need to minimize bundle impact
|
||||
|
||||
## E2E Testing
|
||||
|
||||
When using icons in clickable elements, ensure proper `data-what` and `data-which` attributes on parent elements:
|
||||
|
||||
```html
|
||||
<button
|
||||
data-what="button"
|
||||
data-which="search-action"
|
||||
(click)="search()"
|
||||
>
|
||||
<span [innerHTML]="isaActionSearch"></span>
|
||||
Search
|
||||
</button>
|
||||
```
|
||||
|
||||
## Running Tests
|
||||
|
||||
Run unit tests with Jest:
|
||||
|
||||
```bash
|
||||
npx nx test icons
|
||||
```
|
||||
|
||||
## Related Libraries
|
||||
|
||||
The icons library integrates with:
|
||||
- **UI Component Libraries:** Used extensively in `@isa/ui/*` components
|
||||
- **Feature Libraries:** Referenced in domain features for contextual icons
|
||||
- **Shared Components:** Used in `@isa/shared/*` for product displays and navigation
|
||||
|
||||
@@ -2,7 +2,15 @@
|
||||
|
||||
## Overview
|
||||
|
||||
The Scanner library provides barcode scanning capabilities for the ISA application using the [Scandit SDK](https://www.scandit.com/). It offers a complete solution for mobile barcode scanning with support for various barcode formats, ready-state detection, and seamless form integration.
|
||||
The `@isa/shared/scanner` library provides enterprise-grade barcode scanning capabilities for the ISA application using the [Scandit SDK](https://www.scandit.com/). It offers a complete, production-ready solution for mobile barcode scanning with comprehensive support for multiple symbologies, platform detection (iOS/Android), ready-state management, and seamless integration with Angular forms and reactive patterns.
|
||||
|
||||
**Key Use Cases:**
|
||||
- Barcode scanning for product lookup and inventory management
|
||||
- Order processing and verification
|
||||
- Returns and remission workflows
|
||||
- Asset tracking and identification
|
||||
|
||||
**Type:** Shared component library with services, directives, and ready-to-use UI components
|
||||
|
||||
## Features
|
||||
|
||||
|
||||
@@ -2,7 +2,16 @@
|
||||
|
||||
## Overview
|
||||
|
||||
Provides utilities for storing, restoring, and observing scroll position across navigation or component view changes.
|
||||
The `@isa/utils/scroll-position` library provides a comprehensive set of utilities for managing scroll position persistence and viewport visibility detection across route navigation and component lifecycle changes. It enables seamless user experience by automatically preserving and restoring scroll positions when users navigate between views, particularly useful in list/detail navigation patterns.
|
||||
|
||||
**Key Features:**
|
||||
- **Automatic Scroll Restoration**: Preserve and restore scroll position across route navigation
|
||||
- **Session Storage Integration**: Persists scroll positions in session storage for reliability
|
||||
- **Route-Level Control**: Enable/disable restoration per route via route data configuration
|
||||
- **Viewport Detection**: Observe when elements enter or leave the viewport for lazy loading and infinite scroll
|
||||
- **Configurable Delays**: Control timing of scroll restoration with optional delays
|
||||
|
||||
**Type:** Utility library with functions, injectables, and directives
|
||||
|
||||
## Features
|
||||
|
||||
|
||||
Reference in New Issue
Block a user