一键导入
lvt-analyze
Analyze LiveTemplate app structure - examine schema, resources, relationships, complexity, and provide insights
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Analyze LiveTemplate app structure - examine schema, resources, relationships, complexity, and provide insights
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when deploying LiveTemplate applications to production - covers Docker containerization, Fly.io deployment, Kubernetes setup, database persistence, and production best practices
Transform app to production-ready - adds authentication, deployment config, environment setup, and best practices
Use when deploying LiveTemplate applications to production - covers Docker containerization, Fly.io deployment, Kubernetes setup, database persistence, and production best practices
Rapid end-to-end workflow - creates app, adds resources, sets up development environment in one flow
Generate test apps, capture screenshots, analyze UI for issues, and recursively fix problems in kit templates
Use when adding database migrations to LiveTemplate apps - guides both auto-generated migrations (from lvt gen resource) and custom migrations (indexes, constraints, data transformations)
| name | lvt-analyze |
| description | Analyze LiveTemplate app structure - examine schema, resources, relationships, complexity, and provide insights |
| category | maintenance |
| version | 1.0.0 |
| keywords | ["lvt","livetemplate","lt"] |
Comprehensive analysis of LiveTemplate application structure. Examines database schema, resources, relationships, code organization, and provides actionable insights.
This skill typically runs in existing LiveTemplate projects (.lvtrc exists).
✅ Context Established By:
.lvtrc exists (most common scenario)lvt-assistant agentKeyword matching (case-insensitive): lvt, livetemplate, lt
With Context: ✅ Generic prompts related to this skill's purpose
Without Context (needs keywords): ✅ Must mention "lvt", "livetemplate", or "lt" ❌ Generic requests without keywords
When to use:
Examples:
Use lvt:resource-inspect to examine:
Output format:
=== Schema Analysis ===
Resources: 5 tables found
Core Resources:
- users (7 fields) - User accounts and profiles
- posts (6 fields) - Blog posts with content
- comments (5 fields) - User comments on posts
Supporting Tables:
- sessions (4 fields) - User session management
- categories (3 fields) - Post categorization
Complexity: Medium (5 tables, 25 total fields)
Detect and document:
Output format:
=== Relationships ===
One-to-Many:
- posts → comments (via post_id)
- users → posts (via user_id)
- users → sessions (via user_id)
Many-to-Many:
- (none detected)
Potential Missing Relationships:
- posts could relate to categories
- comments could relate to users
Foreign Key Analysis:
✅ All foreign keys use CASCADE delete
✅ Relationships properly indexed
Analyze each resource:
Output format:
=== Resource Complexity ===
Simple Resources:
- categories (3 fields) - Basic lookup table
- sessions (4 fields) - Session tracking
Medium Resources:
- comments (5 fields) - Standard CRUD
- posts (6 fields) - Content management
Complex Resources:
- users (7 fields) - Auth + profile data
Average Complexity: 5 fields per resource
Check file structure:
=== Code Organization ===
App Structure:
✅ app/ - Handler organization
✅ database/ - Database layer
✅ shared/ - Shared utilities
Resources with Full Stack:
- posts (handler, template, tests)
- comments (handler, template, tests)
- users (auth system)
Views:
- home (landing page)
- about (static page)
Missing:
⚠️ No E2E tests for posts
⚠️ No custom middleware
Analyze database structure:
Output format:
=== Database Health ===
Migrations: 5 applied
Latest: 20251104_create_comments.sql
Index Coverage:
✅ Primary keys on all tables
✅ Foreign keys indexed
⚠️ High-volume table 'posts' missing index on created_at
Performance Recommendations:
- Add index on posts(created_at) for date sorting
- Add index on comments(post_id, created_at) for pagination
Schema Consistency:
✅ All timestamps use DATETIME
✅ Consistent naming (snake_case)
✅ ID fields use INTEGER PRIMARY KEY
Identify features in use:
Output format:
=== Features Detected ===
Authentication:
✅ Password authentication
✅ Magic link authentication
✅ Email confirmation
✅ Session management
✅ CSRF protection
CRUD Operations:
✅ posts - Full CRUD
✅ comments - Full CRUD
✅ categories - Full CRUD
Advanced Features:
✅ Pagination (infinite scroll)
⚠️ No search functionality
⚠️ No sorting controls
⚠️ No filters
# Application Analysis Report
## Overview
- **App Name:** [name]
- **Resources:** [count] tables
- **Complexity:** [simple/medium/complex]
- **Features:** [auth, CRUD, pagination, etc.]
## Schema Summary
[List all resources with field counts]
## Relationships
[Document all foreign keys and relationships]
## Complexity Analysis
[Breakdown by resource]
## Database Health
- **Migrations:** [count]
- **Index Coverage:** [percentage]
- **Performance:** [issues/recommendations]
## Feature Coverage
[Which features are implemented]
## Recommendations
[Ordered list of suggestions]
## Next Steps
[Actionable items for improvement]
=== App Analysis ===
Overview:
- 3 core resources (posts, comments, users)
- Medium complexity (18 total fields)
- Basic CRUD + Auth
Strengths:
✅ Clean schema with proper relationships
✅ Full authentication system
✅ Consistent naming conventions
Opportunities:
⚠️ Add categories for better organization
⚠️ Add indexes for better performance
⚠️ Add search functionality
Recommendation: Add categories and post_categories junction table
=== App Analysis ===
Overview:
- 6 core resources (products, orders, customers, etc.)
- Complex (45 total fields)
- Full e-commerce features
Strengths:
✅ Complete order workflow
✅ Customer management
✅ Product catalog
Opportunities:
⚠️ Missing inventory tracking
⚠️ No product reviews
⚠️ Cart abandonment not tracked
Recommendation: Add reviews resource and inventory fields
Analysis is complete when: