Initial commit
This commit is contained in:
351
skills/initializing-project/DETECTION.md
Normal file
351
skills/initializing-project/DETECTION.md
Normal file
@@ -0,0 +1,351 @@
|
||||
# Detection & Analysis
|
||||
|
||||
This file contains detailed patterns for project analysis, framework detection, and agent orchestration.
|
||||
|
||||
## Phase 1: Agent-Orchestrated Discovery
|
||||
|
||||
I coordinate specialized agents for parallel analysis:
|
||||
|
||||
### Agent Execution Strategy
|
||||
|
||||
```yaml
|
||||
Parallel Agent Execution:
|
||||
Framework & Dependencies:
|
||||
agent: researcher
|
||||
timeout: 10 seconds
|
||||
analyzes:
|
||||
- Primary programming language and framework
|
||||
- Dependencies from package.json/requirements.txt/Cargo.toml/go.mod
|
||||
- Test framework and current coverage
|
||||
- Build tools and scripts
|
||||
output: "Structured YAML with framework, dependencies, and tools"
|
||||
|
||||
Architecture Patterns:
|
||||
agent: architect
|
||||
timeout: 10 seconds
|
||||
analyzes:
|
||||
- Architecture patterns (MVC, DDD, VSA, Clean Architecture)
|
||||
- Component relationships and boundaries
|
||||
- API design patterns
|
||||
- Database architecture
|
||||
- Technical debt and complexity hotspots
|
||||
output: "Structured analysis with patterns, strengths, and concerns"
|
||||
|
||||
Security Assessment:
|
||||
agent: security
|
||||
timeout: 10 seconds
|
||||
analyzes:
|
||||
- Security patterns and anti-patterns
|
||||
- Common vulnerabilities
|
||||
- Authentication/authorization approach
|
||||
- Data handling and encryption
|
||||
- Dependency security
|
||||
output: "Security assessment with risks and recommendations"
|
||||
```
|
||||
|
||||
### Result Consolidation
|
||||
|
||||
After all agents complete, consolidate findings:
|
||||
|
||||
```yaml
|
||||
consolidated_analysis:
|
||||
framework: "[from researcher agent]"
|
||||
language: "[detected primary language]"
|
||||
architecture: "[from architect agent]"
|
||||
security: "[from security agent]"
|
||||
complexity: "[calculated score 0.0-1.0]"
|
||||
phase: "[new|growth|legacy based on analysis]"
|
||||
```
|
||||
|
||||
## Phase 2.1: Language Detection
|
||||
|
||||
Detect the primary language from package files:
|
||||
|
||||
```yaml
|
||||
language_detection_patterns:
|
||||
Python:
|
||||
files: [requirements.txt, pyproject.toml, setup.py, Pipfile]
|
||||
confidence: high
|
||||
indicators:
|
||||
- "import statements in .py files"
|
||||
- "pip/poetry/pipenv config"
|
||||
|
||||
TypeScript:
|
||||
files: [package.json with "typescript" dependency, tsconfig.json]
|
||||
confidence: high
|
||||
indicators:
|
||||
- ".ts or .tsx files"
|
||||
- "typescript in devDependencies"
|
||||
|
||||
JavaScript:
|
||||
files: [package.json without typescript]
|
||||
confidence: medium
|
||||
indicators:
|
||||
- ".js or .jsx files"
|
||||
- "node_modules directory"
|
||||
|
||||
Rust:
|
||||
files: [Cargo.toml, Cargo.lock]
|
||||
confidence: high
|
||||
indicators:
|
||||
- ".rs files"
|
||||
- "cargo workspace config"
|
||||
|
||||
Go:
|
||||
files: [go.mod, go.sum]
|
||||
confidence: high
|
||||
indicators:
|
||||
- ".go files"
|
||||
- "go directive in go.mod"
|
||||
|
||||
Java:
|
||||
files: [pom.xml, build.gradle, build.gradle.kts]
|
||||
confidence: high
|
||||
indicators:
|
||||
- ".java files"
|
||||
- "maven/gradle config"
|
||||
|
||||
Ruby:
|
||||
files: [Gemfile, Gemfile.lock]
|
||||
confidence: high
|
||||
indicators:
|
||||
- ".rb files"
|
||||
- "bundler config"
|
||||
```
|
||||
|
||||
### Detection Algorithm
|
||||
|
||||
```
|
||||
1. Check for language-specific config files (highest confidence)
|
||||
2. Count files by extension in src/ directory
|
||||
3. Parse package managers to identify language
|
||||
4. Assign confidence score based on indicators
|
||||
5. Select language with highest confidence
|
||||
```
|
||||
|
||||
## Phase 2.2: Load Language Configuration
|
||||
|
||||
For the detected language, load defaults from `src/quaestor/core/languages.yaml`:
|
||||
|
||||
```yaml
|
||||
# Example for Python
|
||||
python:
|
||||
lint_command: "ruff check ."
|
||||
format_command: "ruff format ."
|
||||
test_command: "pytest"
|
||||
coverage_command: "pytest --cov"
|
||||
type_check_command: "mypy ."
|
||||
quick_check_command: "ruff check . && pytest -x"
|
||||
full_check_command: "ruff check . && ruff format --check . && mypy . && pytest"
|
||||
code_formatter: "ruff"
|
||||
testing_framework: "pytest"
|
||||
coverage_threshold_percent: ">= 80%"
|
||||
|
||||
# Example for TypeScript/JavaScript
|
||||
typescript:
|
||||
lint_command: "eslint ."
|
||||
format_command: "prettier --write ."
|
||||
test_command: "npm test"
|
||||
coverage_command: "npm run test:coverage"
|
||||
type_check_command: "tsc --noEmit"
|
||||
quick_check_command: "eslint . && npm test"
|
||||
full_check_command: "eslint . && prettier --check . && tsc --noEmit && npm test"
|
||||
code_formatter: "prettier"
|
||||
testing_framework: "jest"
|
||||
coverage_threshold_percent: ">= 80%"
|
||||
|
||||
# Example for Rust
|
||||
rust:
|
||||
lint_command: "cargo clippy"
|
||||
format_command: "cargo fmt"
|
||||
test_command: "cargo test"
|
||||
coverage_command: "cargo tarpaulin"
|
||||
type_check_command: "cargo check"
|
||||
quick_check_command: "cargo clippy && cargo test"
|
||||
full_check_command: "cargo clippy && cargo fmt --check && cargo test"
|
||||
code_formatter: "rustfmt"
|
||||
testing_framework: "cargo test"
|
||||
coverage_threshold_percent: ">= 75%"
|
||||
```
|
||||
|
||||
## Framework-Specific Intelligence
|
||||
|
||||
### React/Frontend Projects
|
||||
|
||||
```yaml
|
||||
react_detection:
|
||||
indicators:
|
||||
- "react" in package.json dependencies
|
||||
- ".jsx or .tsx files"
|
||||
- "src/components/" directory structure
|
||||
|
||||
analysis:
|
||||
state_management:
|
||||
patterns: [Redux, Context API, Zustand, Recoil, MobX]
|
||||
detection: "Search for store/context setup files"
|
||||
|
||||
component_patterns:
|
||||
types: [HOC, Hooks, Render Props, Class Components]
|
||||
detection: "Analyze component file structure"
|
||||
|
||||
architecture:
|
||||
types: [SPA, SSR, Static Site]
|
||||
detection: "Check for Next.js, Gatsby, or CRA setup"
|
||||
|
||||
quality_gates:
|
||||
defaults: "ESLint + Prettier + TypeScript"
|
||||
detection: "Parse .eslintrc and tsconfig.json"
|
||||
```
|
||||
|
||||
### Python/Backend Projects
|
||||
|
||||
```yaml
|
||||
python_detection:
|
||||
frameworks:
|
||||
Django:
|
||||
indicators: ["django" in requirements, manage.py, settings.py]
|
||||
architecture: "MTV (Model-Template-View)"
|
||||
|
||||
FastAPI:
|
||||
indicators: ["fastapi" in requirements, main.py with app = FastAPI()]
|
||||
architecture: "API-first, async-native"
|
||||
|
||||
Flask:
|
||||
indicators: ["flask" in requirements, app.py]
|
||||
architecture: "Microframework, flexible"
|
||||
|
||||
patterns:
|
||||
detection: [MVC, Repository, Service Layer, Domain-Driven Design]
|
||||
analysis: "Examine directory structure and import patterns"
|
||||
|
||||
testing:
|
||||
frameworks: [pytest, unittest, nose2]
|
||||
detection: "Check test files and conftest.py"
|
||||
|
||||
quality_gates:
|
||||
defaults: "ruff + mypy + pytest"
|
||||
detection: "Parse pyproject.toml and setup.cfg"
|
||||
```
|
||||
|
||||
### Rust Projects
|
||||
|
||||
```yaml
|
||||
rust_detection:
|
||||
frameworks:
|
||||
Axum:
|
||||
indicators: ["axum" in Cargo.toml, "use axum::"]
|
||||
architecture: "Async, Tower middleware"
|
||||
|
||||
Rocket:
|
||||
indicators: ["rocket" in Cargo.toml, "#[rocket::"]
|
||||
architecture: "Type-safe, batteries-included"
|
||||
|
||||
Actix:
|
||||
indicators: ["actix-web" in Cargo.toml, "use actix_web::"]
|
||||
architecture: "Actor-based, high performance"
|
||||
|
||||
patterns:
|
||||
detection: [Hexagonal, Clean Architecture, Layered]
|
||||
analysis: "Examine module structure and trait boundaries"
|
||||
|
||||
testing:
|
||||
default: "cargo test with built-in test framework"
|
||||
detection: "#[test] and #[cfg(test)] attributes"
|
||||
|
||||
quality_gates:
|
||||
defaults: "clippy + rustfmt + cargo test"
|
||||
detection: "Cargo.toml and clippy.toml"
|
||||
```
|
||||
|
||||
## Project Phase Detection
|
||||
|
||||
Analyze git history and project metrics to determine project phase:
|
||||
|
||||
```yaml
|
||||
phase_detection:
|
||||
Startup (0-6 months):
|
||||
indicators:
|
||||
- Commit count: < 200
|
||||
- Contributors: 1-3
|
||||
- Files: < 100
|
||||
- Test coverage: < 60%
|
||||
focus: "MVP Foundation, Core Features, User Feedback"
|
||||
|
||||
Growth (6-18 months):
|
||||
indicators:
|
||||
- Commit count: 200-1000
|
||||
- Contributors: 3-10
|
||||
- Files: 100-500
|
||||
- Test coverage: 60-80%
|
||||
focus: "Performance, Feature Expansion, Production Hardening"
|
||||
|
||||
Enterprise (18+ months):
|
||||
indicators:
|
||||
- Commit count: > 1000
|
||||
- Contributors: > 10
|
||||
- Files: > 500
|
||||
- Test coverage: > 80%
|
||||
focus: "Architecture Evolution, Scalability, Platform Maturation"
|
||||
```
|
||||
|
||||
## Error Handling & Graceful Degradation
|
||||
|
||||
```yaml
|
||||
error_handling:
|
||||
researcher_agent_fails:
|
||||
fallback:
|
||||
- Use basic file detection (package.json, requirements.txt)
|
||||
- Count files by extension
|
||||
- Parse package manager files directly
|
||||
log: "Framework detection limited - manual review recommended"
|
||||
continue: true
|
||||
|
||||
architect_agent_fails:
|
||||
fallback:
|
||||
- Use simplified pattern detection based on folder structure
|
||||
- Check for common patterns (models/, views/, controllers/)
|
||||
- Infer from file naming conventions
|
||||
log: "Architecture analysis incomplete - patterns may be missed"
|
||||
continue: true
|
||||
|
||||
security_agent_fails:
|
||||
fallback:
|
||||
- Flag for manual security review
|
||||
- Skip security-specific recommendations
|
||||
- Use generic security best practices
|
||||
log: "Security assessment skipped - manual review required"
|
||||
continue: true
|
||||
|
||||
timeout_handling:
|
||||
total_time_limit: 30 seconds
|
||||
individual_agent_timeout: 10 seconds
|
||||
strategy: "Kill agent on timeout, use partial results if available"
|
||||
|
||||
missing_config_files:
|
||||
strategy: "Use sensible defaults for detected language"
|
||||
log: "Using default configuration for [language]"
|
||||
continue: true
|
||||
```
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
```yaml
|
||||
optimization:
|
||||
parallel_execution:
|
||||
- Run all 3 agents simultaneously using Task tool
|
||||
- Agents are independent, no sequential dependencies
|
||||
- Reduces total analysis time from 30s to ~10s
|
||||
|
||||
caching:
|
||||
- Cache language detection results during session
|
||||
- Cache parsed package manager files
|
||||
- Avoid redundant file system scans
|
||||
|
||||
early_termination:
|
||||
- If all agents complete in < 5s, proceed immediately
|
||||
- Don't wait for full timeout period
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*This file provides comprehensive detection patterns and agent orchestration strategies for intelligent project analysis.*
|
||||
485
skills/initializing-project/EXAMPLES.md
Normal file
485
skills/initializing-project/EXAMPLES.md
Normal file
@@ -0,0 +1,485 @@
|
||||
# Complete Initialization Examples
|
||||
|
||||
This file provides complete end-to-end examples of project initialization for different project types.
|
||||
|
||||
## Example 1: Python FastAPI Project
|
||||
|
||||
### User Request
|
||||
```
|
||||
User: "Initialize Quaestor in this Python project"
|
||||
```
|
||||
|
||||
### My Response - Phase 1 & 2 (Analysis)
|
||||
```
|
||||
🔍 Analyzing your project...
|
||||
|
||||
Spawning specialized agents for analysis:
|
||||
- researcher: Analyzing dependencies and framework
|
||||
- architect: Evaluating architecture patterns
|
||||
- security: Assessing security posture
|
||||
|
||||
[Agents complete in ~8 seconds]
|
||||
```
|
||||
|
||||
### My Response - Phase 3 (Validation)
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: FastAPI with SQLAlchemy
|
||||
- Architecture: Hexagonal (Ports & Adapters)
|
||||
- Complexity: 0.65/1.0 (moderate)
|
||||
- Phase: Growth (6-18 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: pytest with 75% coverage
|
||||
- Linting: ruff with pyproject.toml config
|
||||
- Type checking: mypy in strict mode
|
||||
- CI/CD: GitHub Actions detected
|
||||
- Security: No major vulnerabilities detected
|
||||
|
||||
**Files Analyzed:**
|
||||
- pyproject.toml: FastAPI, SQLAlchemy, pytest dependencies
|
||||
- src/domain/: Clean domain layer detected
|
||||
- src/infrastructure/: Repository pattern found
|
||||
- tests/: Good test coverage structure
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer for the initial setup?
|
||||
```
|
||||
|
||||
### User Response
|
||||
```
|
||||
User: "Proceed with detected setup"
|
||||
```
|
||||
|
||||
### My Response - Phase 4 (Completion)
|
||||
```
|
||||
✅ Initialization complete!
|
||||
|
||||
**Generated Documentation:**
|
||||
- .quaestor/AGENT.md (AI behavioral rules)
|
||||
- .quaestor/ARCHITECTURE.md (with Python quality standards)
|
||||
- CLAUDE.md (main entry point)
|
||||
|
||||
**Directory Structure:**
|
||||
- .quaestor/specs/draft/
|
||||
- .quaestor/specs/active/
|
||||
- .quaestor/specs/completed/
|
||||
- .quaestor/specs/archived/
|
||||
|
||||
**Next Steps:**
|
||||
1. Review .quaestor/ARCHITECTURE.md Section 3 to customize commands
|
||||
2. Create your first specification: "Create a spec for..."
|
||||
3. Start development with Research → Plan → Implement workflow
|
||||
```
|
||||
|
||||
### Generated ARCHITECTURE.md (Section 3 excerpt)
|
||||
```markdown
|
||||
## 3. CODE QUALITY STANDARDS
|
||||
|
||||
### Linting and Formatting
|
||||
- **Linter**: `ruff check .`
|
||||
- **Formatter**: `ruff format .`
|
||||
- **Code Formatter**: ruff
|
||||
- **Quick Check**: `ruff check . && pytest -x`
|
||||
- **Full Validation**: `ruff check . && ruff format --check . && mypy . && pytest`
|
||||
|
||||
### Testing Requirements
|
||||
- **Test Runner**: `pytest`
|
||||
- **Coverage**: `pytest --cov`
|
||||
- **Coverage Threshold**: >= 80%
|
||||
- **Testing Framework**: pytest
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 2: React TypeScript Project with Modifications
|
||||
|
||||
### User Request
|
||||
```
|
||||
User: "Set up Quaestor with intelligent project analysis"
|
||||
```
|
||||
|
||||
### My Response - Phase 1 & 2 (Analysis)
|
||||
```
|
||||
🔍 Analyzing your project...
|
||||
|
||||
Spawning specialized agents:
|
||||
- researcher: Framework and dependency analysis
|
||||
- architect: Architecture pattern evaluation
|
||||
- security: Security assessment
|
||||
|
||||
[Analysis complete in ~9 seconds]
|
||||
```
|
||||
|
||||
### My Response - Phase 3 (Validation)
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: React with TypeScript
|
||||
- Architecture: Component-based with Redux state management
|
||||
- Complexity: 0.70/1.0 (high)
|
||||
- Phase: Growth (6-18 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: Jest with React Testing Library, 82% coverage
|
||||
- Linting: ESLint with Airbnb config
|
||||
- Type checking: TypeScript strict mode
|
||||
- CI/CD: GitHub Actions detected
|
||||
- Security: 2 outdated dependencies (non-critical)
|
||||
|
||||
**Files Analyzed:**
|
||||
- package.json: React 18.2, TypeScript 5.0, Jest, ESLint
|
||||
- src/components/: Hooks-based component architecture
|
||||
- src/store/: Redux Toolkit slices and sagas
|
||||
- tests/: Comprehensive test suite
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer for the initial setup?
|
||||
```
|
||||
|
||||
### User Response (Modification Path)
|
||||
```
|
||||
User: "Modify detected patterns"
|
||||
```
|
||||
|
||||
### My Follow-up
|
||||
```
|
||||
What would you like to adjust?
|
||||
|
||||
Options to modify:
|
||||
- Coverage threshold (currently >= 80%)
|
||||
- Linting rules
|
||||
- Architecture pattern description
|
||||
- Project phase classification
|
||||
- Quality standards
|
||||
```
|
||||
|
||||
### User Modification
|
||||
```
|
||||
User: "Change coverage requirement to 90% and add stricter ESLint rules"
|
||||
```
|
||||
|
||||
### My Confirmation
|
||||
```
|
||||
Updated:
|
||||
- Coverage threshold: >= 90%
|
||||
- ESLint: Added stricter rules to config
|
||||
|
||||
Anything else to modify?
|
||||
```
|
||||
|
||||
### User Confirmation
|
||||
```
|
||||
User: "No, proceed"
|
||||
```
|
||||
|
||||
### My Response - Phase 4 (Completion)
|
||||
```
|
||||
✅ Initialization complete with your customizations!
|
||||
|
||||
**Generated Documentation:**
|
||||
- .quaestor/AGENT.md
|
||||
- .quaestor/ARCHITECTURE.md (with TypeScript quality standards + your customizations)
|
||||
- CLAUDE.md
|
||||
|
||||
**Customizations Applied:**
|
||||
- Coverage threshold set to >= 90%
|
||||
- Stricter ESLint configuration documented
|
||||
|
||||
**Next Steps:**
|
||||
1. Review .quaestor/ARCHITECTURE.md - your customizations are in Section 3
|
||||
2. Run your first quality check: `npm run lint && npm test`
|
||||
3. Create specifications and start development
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 3: Rust Axum Project with Custom Architecture
|
||||
|
||||
### User Request
|
||||
```
|
||||
User: "Analyze my project structure and initialize Quaestor"
|
||||
```
|
||||
|
||||
### My Response - Phase 3 (Validation)
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: Axum with Tokio and SQLx
|
||||
- Architecture: Layered with clear module boundaries
|
||||
- Complexity: 0.55/1.0 (moderate)
|
||||
- Phase: Startup (0-6 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: cargo test with 68% coverage
|
||||
- Linting: clippy with custom rules
|
||||
- Type checking: Rust's built-in type system
|
||||
- CI/CD: No CI detected
|
||||
- Security: All dependencies up to date
|
||||
|
||||
**Files Analyzed:**
|
||||
- Cargo.toml: axum 0.7, tokio 1.35, sqlx 0.7
|
||||
- src/lib.rs: Well-structured module hierarchy
|
||||
- src/handlers/: Clean separation of concerns
|
||||
- tests/: Integration tests present
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer?
|
||||
```
|
||||
|
||||
### User Response (Custom Architecture Path)
|
||||
```
|
||||
User: "Custom architecture description"
|
||||
```
|
||||
|
||||
### My Follow-up
|
||||
```
|
||||
Please describe your project architecture. I'll use your description instead of the detected patterns.
|
||||
|
||||
What I'd like to know:
|
||||
- Architecture pattern (if different from "Layered")
|
||||
- Key components and responsibilities
|
||||
- Design principles you're following
|
||||
- Quality standards and testing strategy
|
||||
```
|
||||
|
||||
### User Description
|
||||
```
|
||||
User: "We use Hexagonal Architecture with Domain-Driven Design. The domain layer is completely isolated, application layer orchestrates use cases, and infrastructure layer handles persistence and external APIs. We follow CQRS for complex operations and aim for 85% test coverage with property-based testing."
|
||||
```
|
||||
|
||||
### My Confirmation
|
||||
```
|
||||
Got it! I'll document your architecture as:
|
||||
|
||||
- **Pattern**: Hexagonal Architecture with Domain-Driven Design
|
||||
- **Layers**: Domain (isolated), Application (orchestration), Infrastructure (adapters)
|
||||
- **Patterns**: CQRS for complex operations
|
||||
- **Testing**: 85% coverage with property-based testing
|
||||
|
||||
Does this accurately represent your architecture?
|
||||
```
|
||||
|
||||
### User Confirmation
|
||||
```
|
||||
User: "Yes, perfect"
|
||||
```
|
||||
|
||||
### My Response - Phase 4 (Completion)
|
||||
```
|
||||
✅ Initialization complete with your custom architecture!
|
||||
|
||||
**Generated Documentation:**
|
||||
- .quaestor/AGENT.md
|
||||
- .quaestor/ARCHITECTURE.md (with your Hexagonal/DDD architecture)
|
||||
- CLAUDE.md
|
||||
|
||||
**Your Architecture:**
|
||||
- Pattern: Hexagonal Architecture with Domain-Driven Design
|
||||
- CQRS pattern documented
|
||||
- 85% coverage target configured
|
||||
- Property-based testing noted
|
||||
|
||||
**Next Steps:**
|
||||
1. Review .quaestor/ARCHITECTURE.md Section 2 - your architecture is documented
|
||||
2. Your custom testing strategy is in Section 5
|
||||
3. Start implementing specifications with your architecture patterns
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 4: Minimal Setup for New Project
|
||||
|
||||
### User Request
|
||||
```
|
||||
User: "Initialize Quaestor in this project"
|
||||
```
|
||||
|
||||
### Context
|
||||
User has an empty/new project with minimal files.
|
||||
|
||||
### My Response - Phase 3 (Validation)
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: Unable to detect (minimal files found)
|
||||
- Architecture: Unknown (new project)
|
||||
- Complexity: 0.0/1.0 (new project)
|
||||
- Phase: Startup (0-6 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- No existing quality tools detected
|
||||
- No tests found
|
||||
- No CI/CD configured
|
||||
|
||||
**Files Analyzed:**
|
||||
- No significant project files found
|
||||
- This appears to be a new project
|
||||
|
||||
**Recommendation:** Consider using minimal setup and configuring quality standards manually as your project develops.
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup (basic defaults)
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup (recommended for new projects)
|
||||
|
||||
What would you prefer?
|
||||
```
|
||||
|
||||
### User Response
|
||||
```
|
||||
User: "Start with minimal setup"
|
||||
```
|
||||
|
||||
### My Response - Phase 4 (Completion)
|
||||
```
|
||||
✅ Minimal setup complete!
|
||||
|
||||
**Generated Documentation:**
|
||||
- .quaestor/AGENT.md (standard workflow rules)
|
||||
- .quaestor/ARCHITECTURE.md (template - customize as you develop)
|
||||
- CLAUDE.md
|
||||
|
||||
**What to do next:**
|
||||
1. Edit .quaestor/ARCHITECTURE.md as your project takes shape:
|
||||
- Fill in Section 1: Project Configuration
|
||||
- Define Section 2: Architecture Overview
|
||||
- Configure Section 3: Code Quality Standards (add commands as you adopt tools)
|
||||
|
||||
2. Install quality tools for your language/framework:
|
||||
- Python: `pip install ruff mypy pytest`
|
||||
- TypeScript: `npm install -D eslint prettier jest`
|
||||
- Rust: Already has clippy, rustfmt, cargo test
|
||||
|
||||
3. Return anytime to re-analyze:
|
||||
- "Analyze my project" to update configuration
|
||||
- All skills remain available via plugin/CLI
|
||||
|
||||
**Minimal Structure Created:**
|
||||
- .quaestor/specs/draft/
|
||||
- .quaestor/specs/active/
|
||||
- .quaestor/specs/completed/
|
||||
- .quaestor/specs/archived/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 5: Error Handling - Agent Failure
|
||||
|
||||
### Scenario
|
||||
One or more agents fail during analysis.
|
||||
|
||||
### My Response (Graceful Degradation)
|
||||
```
|
||||
🔍 Analyzing your project...
|
||||
|
||||
Spawning specialized agents:
|
||||
- researcher: ✓ Complete (Python FastAPI detected)
|
||||
- architect: ⚠ Timeout (10s limit reached)
|
||||
- security: ✓ Complete (No major issues)
|
||||
|
||||
Note: Architecture analysis incomplete. Using basic pattern detection.
|
||||
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: FastAPI with SQLAlchemy
|
||||
- Architecture: Basic pattern detection (architect agent timed out)
|
||||
- Detected: Repository pattern in infrastructure/
|
||||
- Detected: Domain models in domain/
|
||||
- Recommendation: Review and customize architecture section
|
||||
- Complexity: 0.50/1.0 (estimated from available metrics)
|
||||
- Phase: Growth (6-18 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: pytest detected
|
||||
- Linting: ruff detected
|
||||
- Type checking: mypy in pyproject.toml
|
||||
- Security: No major vulnerabilities
|
||||
|
||||
**Files Analyzed:**
|
||||
- pyproject.toml: Dependencies analyzed
|
||||
- src/: Basic structure reviewed
|
||||
- tests/: Test suite found
|
||||
|
||||
⚠ **Note**: Architecture analysis was incomplete. The generated ARCHITECTURE.md will have a basic template in Section 2. Please review and customize it based on your actual architecture.
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup (with basic architecture template)
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description (recommended due to incomplete analysis)
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer?
|
||||
```
|
||||
|
||||
This shows graceful degradation when agents fail - I continue with available data and clearly communicate limitations.
|
||||
|
||||
---
|
||||
|
||||
## Common Workflows Summary
|
||||
|
||||
### Quick Accept (Most Common)
|
||||
```
|
||||
1. User: "Initialize Quaestor"
|
||||
2. Me: [Analysis + Validation with all detected info]
|
||||
3. User: "Proceed"
|
||||
4. Me: [Complete setup]
|
||||
```
|
||||
|
||||
### Modification Path
|
||||
```
|
||||
1. User: "Initialize Quaestor"
|
||||
2. Me: [Analysis + Validation]
|
||||
3. User: "Modify detected patterns"
|
||||
4. Me: "What to adjust?"
|
||||
5. User: [Specific changes]
|
||||
6. Me: [Confirmation]
|
||||
7. User: "Proceed"
|
||||
8. Me: [Complete with modifications]
|
||||
```
|
||||
|
||||
### Custom Architecture Path
|
||||
```
|
||||
1. User: "Initialize Quaestor"
|
||||
2. Me: [Analysis + Validation]
|
||||
3. User: "Custom architecture description"
|
||||
4. Me: "Please describe your architecture"
|
||||
5. User: [Detailed architecture explanation]
|
||||
6. Me: [Confirmation of understanding]
|
||||
7. User: "Yes"
|
||||
8. Me: [Complete with custom architecture]
|
||||
```
|
||||
|
||||
### Minimal Setup Path
|
||||
```
|
||||
1. User: "Initialize Quaestor" (in empty/new project)
|
||||
2. Me: [Analysis shows minimal project]
|
||||
3. User: "Minimal setup"
|
||||
4. Me: [Create basic templates for user to customize]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*These examples demonstrate the complete initialization workflow across different project types and user interaction patterns.*
|
||||
104
skills/initializing-project/SKILL.md
Normal file
104
skills/initializing-project/SKILL.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: Initializing Project
|
||||
description: Intelligent project analysis with auto-framework detection and adaptive setup. Use when user wants to initialize Quaestor, setup a new project, or analyze existing project structure.
|
||||
allowed-tools: [Read, Bash, Glob, Grep, Edit, Write, Task, TodoWrite]
|
||||
---
|
||||
|
||||
# Initializing Project
|
||||
|
||||
I help you intelligently initialize Quaestor in your project with automatic framework detection, architecture analysis, and customized documentation generation.
|
||||
|
||||
## When to Use Me
|
||||
|
||||
- User says "initialize project", "setup quaestor", "analyze my project structure"
|
||||
- Starting Quaestor in a new or existing project
|
||||
- Migrating existing project to Quaestor
|
||||
- Need intelligent project analysis and setup
|
||||
- User asks "how do I set up quaestor?"
|
||||
|
||||
## Supporting Files
|
||||
|
||||
This skill uses several supporting files for detailed workflows:
|
||||
|
||||
- **@DETECTION.md** - Language and framework detection patterns, agent orchestration
|
||||
- **@TEMPLATES.md** - Document templates, variable mappings, skills installation
|
||||
- **@VALIDATION.md** - Mandatory user validation workflow
|
||||
- **@EXAMPLES.md** - Full initialization examples for different project types
|
||||
|
||||
## My Process
|
||||
|
||||
I follow a 4-phase workflow to intelligently initialize your project:
|
||||
|
||||
### Phase 1: Project Analysis 🔍
|
||||
|
||||
I coordinate specialized agents (researcher, architect, security) to analyze your project in parallel. They examine:
|
||||
- Framework and dependencies
|
||||
- Architecture patterns and design
|
||||
- Security posture and vulnerabilities
|
||||
- Project complexity and phase
|
||||
|
||||
**See @DETECTION.md for detailed agent orchestration and detection patterns**
|
||||
|
||||
### Phase 2: Document Generation ⚡
|
||||
|
||||
I detect your project's language, load language-specific configurations, and generate customized documentation:
|
||||
- AGENT.md (AI behavioral rules)
|
||||
- ARCHITECTURE.md (with your language's quality standards)
|
||||
- CLAUDE.md (main entry point)
|
||||
|
||||
**See @TEMPLATES.md for document templates and variable mappings**
|
||||
|
||||
### Phase 3: User Validation ✅ **[MANDATORY]**
|
||||
|
||||
I present my analysis and **MUST** get your approval before proceeding. You'll see:
|
||||
- Detected framework and architecture
|
||||
- Quality standards and tools
|
||||
- Options to proceed, modify, customize, or use minimal setup
|
||||
|
||||
**See @VALIDATION.md for the complete validation workflow**
|
||||
|
||||
### Phase 4: Setup Completion 🚀
|
||||
|
||||
After your approval, I create the directory structure, generate all documentation, install skills, and provide next steps.
|
||||
|
||||
## Error Handling
|
||||
|
||||
I handle failures gracefully:
|
||||
- **Agent failures**: Fall back to basic detection, continue with available data
|
||||
- **Time limits**: 30s total, 10s per agent
|
||||
- **Missing data**: Use sensible defaults and flag for manual review
|
||||
|
||||
**See @DETECTION.md for detailed error handling strategies**
|
||||
|
||||
## Next Steps After Initialization
|
||||
|
||||
After successful initialization:
|
||||
|
||||
### 1. Review and Customize Documentation
|
||||
- `.quaestor/AGENT.md` - AI behavioral rules
|
||||
- `.quaestor/ARCHITECTURE.md` - Architecture and quality standards (edit Section 3 to customize commands)
|
||||
|
||||
### 2. Start Development
|
||||
- Create specifications: "Create a spec for [feature]" or use spec-writing skill
|
||||
- Check progress: "What's the current project status?"
|
||||
- Implement: "Implement spec-feature-001" or use `/impl` command
|
||||
- Review: "Review my changes and create a PR" or use `/review` command
|
||||
|
||||
### 3. Available Skills
|
||||
All Quaestor skills are available via the plugin or CLI installation. Skills are loaded from the plugin/package and accessed directly by Claude Code.
|
||||
|
||||
**See @TEMPLATES.md for customization details and @EXAMPLES.md for complete workflows**
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- ✅ Framework and architecture accurately detected
|
||||
- ✅ USER VALIDATION COMPLETED (mandatory)
|
||||
- ✅ ARCHITECTURE.md generated with language-specific quality standards
|
||||
- ✅ Directory structure created
|
||||
- ✅ Project ready for specification-driven development
|
||||
|
||||
**See @EXAMPLES.md for complete initialization walkthroughs**
|
||||
|
||||
---
|
||||
|
||||
*I provide intelligent project initialization with automatic framework detection, architecture analysis, and customized documentation generation. Just tell me to initialize your project, and I'll handle the rest!*
|
||||
280
skills/initializing-project/TEMPLATES.md
Normal file
280
skills/initializing-project/TEMPLATES.md
Normal file
@@ -0,0 +1,280 @@
|
||||
# Document Templates & Generation
|
||||
|
||||
This file describes the document generation process, template variables, and skills installation.
|
||||
|
||||
## Generated Documents Overview
|
||||
|
||||
```yaml
|
||||
generated_documents:
|
||||
AGENT.md:
|
||||
location: ".quaestor/AGENT.md"
|
||||
source: "src/quaestor/agent.md"
|
||||
processing: "Copy template as-is"
|
||||
purpose: "AI behavioral rules and workflow enforcement"
|
||||
|
||||
ARCHITECTURE.md:
|
||||
location: ".quaestor/ARCHITECTURE.md"
|
||||
source: "src/quaestor/architecture.md"
|
||||
processing: "Jinja2 template with variable substitution"
|
||||
purpose: "Project architecture, patterns, and quality standards"
|
||||
|
||||
CLAUDE.md:
|
||||
location: "CLAUDE.md" (project root)
|
||||
source: "src/quaestor/include.md"
|
||||
processing: "Merge with existing or create new"
|
||||
purpose: "Main entry point with Quaestor configuration"
|
||||
```
|
||||
|
||||
## ARCHITECTURE.md Template Variables
|
||||
|
||||
ARCHITECTURE.md uses Jinja2 templating with variables populated from detected language config:
|
||||
|
||||
### Section 1: Project Configuration
|
||||
|
||||
```yaml
|
||||
template_variables:
|
||||
project_name: "[Detected from directory name or git config]"
|
||||
project_type: "[Detected from framework: web-api, web-app, library, cli, etc.]"
|
||||
language_display_name: "[Human-readable: Python, TypeScript, Rust]"
|
||||
primary_language: "[Code: python, typescript, rust]"
|
||||
config_system_version: "2.0"
|
||||
strict_mode: "[true if complexity > 0.7, else false]"
|
||||
|
||||
build_tool: "[Detected: cargo, npm, pip, gradle]"
|
||||
package_manager: "[Detected: cargo, npm/yarn, pip/poetry, maven]"
|
||||
language_server: "[Optional: pyright, rust-analyzer, tsserver]"
|
||||
virtual_env: "[Optional: venv, conda, nvm]"
|
||||
dependency_management: "[Detected from package files]"
|
||||
```
|
||||
|
||||
### Section 3: Code Quality Standards
|
||||
|
||||
These variables are populated from `src/quaestor/core/languages.yaml`:
|
||||
|
||||
```yaml
|
||||
quality_standards:
|
||||
lint_command: "{{ lint_command }}" # e.g., "ruff check ."
|
||||
format_command: "{{ format_command }}" # e.g., "ruff format ."
|
||||
test_command: "{{ test_command }}" # e.g., "pytest"
|
||||
coverage_command: "{{ coverage_command }}" # e.g., "pytest --cov"
|
||||
type_check_command: "{{ type_check_command }}" # e.g., "mypy ."
|
||||
|
||||
quick_check_command: "{{ quick_check_command }}"
|
||||
# e.g., "ruff check . && pytest -x"
|
||||
|
||||
full_check_command: "{{ full_check_command }}"
|
||||
# e.g., "ruff check . && ruff format --check . && mypy . && pytest"
|
||||
|
||||
code_formatter: "{{ code_formatter }}" # e.g., "ruff"
|
||||
testing_framework: "{{ testing_framework }}" # e.g., "pytest"
|
||||
coverage_threshold_percent: "{{ coverage_threshold_percent }}" # e.g., ">= 80%"
|
||||
```
|
||||
|
||||
### Section 6: Security & Performance
|
||||
|
||||
```yaml
|
||||
security_performance:
|
||||
has_security_scanner: "{{ has_security_scanner }}" # "true" or "false"
|
||||
security_scan_command: "{{ security_scan_command }}" # e.g., "bandit -r ."
|
||||
security_scanner: "{{ security_scanner }}" # e.g., "bandit"
|
||||
|
||||
has_profiler: "{{ has_profiler }}" # "true" or "false"
|
||||
profile_command: "{{ profile_command }}" # e.g., "py-spy top"
|
||||
performance_budget: "{{ performance_budget }}" # e.g., "< 200ms p95"
|
||||
```
|
||||
|
||||
### Section 8: Quality Thresholds
|
||||
|
||||
```yaml
|
||||
quality_thresholds:
|
||||
coverage_threshold_percent: "{{ coverage_threshold_percent }}"
|
||||
max_duplication: "{{ max_duplication }}" # e.g., "3%"
|
||||
max_debt_hours: "{{ max_debt_hours }}" # e.g., "40 hours"
|
||||
max_bugs_per_kloc: "{{ max_bugs_per_kloc }}" # e.g., "0.5"
|
||||
|
||||
current_coverage: "{{ current_coverage }}" # e.g., "0% (not yet measured)"
|
||||
current_duplication: "{{ current_duplication }}" # e.g., "N/A"
|
||||
current_debt: "{{ current_debt }}" # e.g., "N/A"
|
||||
current_bug_density: "{{ current_bug_density }}" # e.g., "N/A"
|
||||
main_config_available: "{{ main_config_available }}" # true or false
|
||||
```
|
||||
|
||||
### Section 10: Project Standards
|
||||
|
||||
```yaml
|
||||
project_standards:
|
||||
max_build_time: "{{ max_build_time }}" # e.g., "< 5 minutes"
|
||||
max_bundle_size: "{{ max_bundle_size }}" # e.g., "< 250KB gzipped"
|
||||
memory_threshold: "{{ memory_threshold }}" # e.g., "< 512MB"
|
||||
retry_configuration: "{{ retry_configuration }}" # e.g., "3 retries with exponential backoff"
|
||||
fallback_behavior: "{{ fallback_behavior }}" # e.g., "Fail gracefully with user message"
|
||||
rule_enforcement: "{{ rule_enforcement }}" # e.g., "Enforced on commit (pre-commit hooks)"
|
||||
pre_edit_script: "{{ pre_edit_script }}" # e.g., "ruff check"
|
||||
post_edit_script: "{{ post_edit_script }}" # e.g., "ruff format"
|
||||
```
|
||||
|
||||
## Variable Population Process
|
||||
|
||||
### Step 1: Detect Language
|
||||
Use patterns from @DETECTION.md to identify primary language.
|
||||
|
||||
### Step 2: Load Language Config
|
||||
```python
|
||||
# Read src/quaestor/core/languages.yaml
|
||||
# Extract section for detected language
|
||||
# Example:
|
||||
config = yaml.load("src/quaestor/core/languages.yaml")
|
||||
lang_config = config[detected_language] # e.g., config["python"]
|
||||
```
|
||||
|
||||
### Step 3: Populate Template
|
||||
```python
|
||||
# Use Jinja2 to render template
|
||||
from jinja2 import Template
|
||||
|
||||
template = Template(open("src/quaestor/architecture.md").read())
|
||||
rendered = template.render(**lang_config, **project_metadata)
|
||||
```
|
||||
|
||||
### Step 4: Write Output
|
||||
```python
|
||||
# Write to .quaestor/ARCHITECTURE.md
|
||||
output_path = ".quaestor/ARCHITECTURE.md"
|
||||
with open(output_path, "w") as f:
|
||||
f.write(rendered)
|
||||
```
|
||||
|
||||
## Language-Specific Template Examples
|
||||
|
||||
### Python Project
|
||||
```markdown
|
||||
## 3. CODE QUALITY STANDARDS
|
||||
|
||||
### Linting and Formatting
|
||||
- **Linter**: `ruff check .`
|
||||
- **Formatter**: `ruff format .`
|
||||
- **Code Formatter**: ruff
|
||||
- **Quick Check**: `ruff check . && pytest -x`
|
||||
- **Full Validation**: `ruff check . && ruff format --check . && mypy . && pytest`
|
||||
|
||||
### Testing Requirements
|
||||
- **Test Runner**: `pytest`
|
||||
- **Coverage**: `pytest --cov`
|
||||
- **Coverage Threshold**: >= 80%
|
||||
- **Testing Framework**: pytest
|
||||
```
|
||||
|
||||
### TypeScript Project
|
||||
```markdown
|
||||
## 3. CODE QUALITY STANDARDS
|
||||
|
||||
### Linting and Formatting
|
||||
- **Linter**: `eslint .`
|
||||
- **Formatter**: `prettier --write .`
|
||||
- **Code Formatter**: prettier
|
||||
- **Quick Check**: `eslint . && npm test`
|
||||
- **Full Validation**: `eslint . && prettier --check . && tsc --noEmit && npm test`
|
||||
|
||||
### Testing Requirements
|
||||
- **Test Runner**: `npm test`
|
||||
- **Coverage**: `npm run test:coverage`
|
||||
- **Coverage Threshold**: >= 80%
|
||||
- **Testing Framework**: jest
|
||||
```
|
||||
|
||||
### Rust Project
|
||||
```markdown
|
||||
## 3. CODE QUALITY STANDARDS
|
||||
|
||||
### Linting and Formatting
|
||||
- **Linter**: `cargo clippy`
|
||||
- **Formatter**: `cargo fmt`
|
||||
- **Code Formatter**: rustfmt
|
||||
- **Quick Check**: `cargo clippy && cargo test`
|
||||
- **Full Validation**: `cargo clippy && cargo fmt --check && cargo test`
|
||||
|
||||
### Testing Requirements
|
||||
- **Test Runner**: `cargo test`
|
||||
- **Coverage**: `cargo tarpaulin`
|
||||
- **Coverage Threshold**: >= 75%
|
||||
- **Testing Framework**: cargo test
|
||||
```
|
||||
|
||||
## Skills Availability
|
||||
|
||||
All Quaestor skills are available via:
|
||||
- **Plugin installation**: Skills loaded from the plugin package
|
||||
- **CLI installation** (`uvx quaestor`): Skills loaded from the installed package
|
||||
|
||||
Skills are NOT copied to the project directory. They remain in the plugin/package and are accessed directly by Claude Code.
|
||||
|
||||
## CLAUDE.md Merging
|
||||
|
||||
### Merge Strategy
|
||||
|
||||
```yaml
|
||||
claude_md_handling:
|
||||
if_exists:
|
||||
strategy: "Merge Quaestor config with existing content"
|
||||
process:
|
||||
- Check for existing QUAESTOR CONFIG markers
|
||||
- If found: Replace old config with new
|
||||
- If not found: Prepend Quaestor config to existing content
|
||||
preserve: "All user custom content"
|
||||
|
||||
if_not_exists:
|
||||
strategy: "Create new CLAUDE.md from template"
|
||||
content: "src/quaestor/include.md"
|
||||
```
|
||||
|
||||
### CLAUDE.md Template
|
||||
|
||||
```markdown
|
||||
<!-- QUAESTOR CONFIG START -->
|
||||
[!IMPORTANT]
|
||||
**Claude:** This project uses Quaestor for AI context management.
|
||||
Please read the following files in order:
|
||||
@.quaestor/AGENT.md - AI behavioral rules and workflow enforcement
|
||||
@.quaestor/ARCHITECTURE.md - Project architecture, standards, and quality guidelines
|
||||
@.quaestor/specs/active/ - Active specifications and implementation details
|
||||
<!-- QUAESTOR CONFIG END -->
|
||||
|
||||
<!-- Your custom content below -->
|
||||
```
|
||||
|
||||
## Customization After Generation
|
||||
|
||||
Users can customize the generated ARCHITECTURE.md:
|
||||
|
||||
### Common Customizations
|
||||
|
||||
```markdown
|
||||
# Example: Customize test command for specific project needs
|
||||
|
||||
# Before (default)
|
||||
- **Test Runner**: `pytest`
|
||||
|
||||
# After (customized for project)
|
||||
- **Test Runner**: `pytest -xvs --cov=src --cov-report=html`
|
||||
|
||||
# Example: Add project-specific linting rules
|
||||
|
||||
# Before (default)
|
||||
- **Linter**: `ruff check .`
|
||||
|
||||
# After (customized)
|
||||
- **Linter**: `ruff check . --select E,F,W,I,N --ignore E501`
|
||||
```
|
||||
|
||||
### Where to Customize
|
||||
|
||||
1. Open `.quaestor/ARCHITECTURE.md`
|
||||
2. Navigate to **Section 3: CODE QUALITY STANDARDS**
|
||||
3. Edit command values directly
|
||||
4. Save file - changes take effect immediately
|
||||
|
||||
**Important**: Users should edit `.quaestor/ARCHITECTURE.md` directly, not the template files in `src/quaestor/`.
|
||||
|
||||
---
|
||||
|
||||
*This file provides complete documentation templates and variable mappings for intelligent document generation.*
|
||||
367
skills/initializing-project/VALIDATION.md
Normal file
367
skills/initializing-project/VALIDATION.md
Normal file
@@ -0,0 +1,367 @@
|
||||
# User Validation Workflow
|
||||
|
||||
This file describes the mandatory user validation process that must occur before project initialization completes.
|
||||
|
||||
## Phase 3: User Validation ✅ **[MANDATORY]**
|
||||
|
||||
⚠️ **CRITICAL ENFORCEMENT RULE:**
|
||||
|
||||
```yaml
|
||||
before_phase_4:
|
||||
MUST_PRESENT_ANALYSIS:
|
||||
- framework_detection_results
|
||||
- architecture_pattern_analysis
|
||||
- quality_standards_detected
|
||||
- project_phase_determination
|
||||
|
||||
MUST_GET_USER_CHOICE:
|
||||
options:
|
||||
- "✅ Proceed with detected setup"
|
||||
- "🔄 Modify detected patterns"
|
||||
- "📝 Custom architecture description"
|
||||
- "🚫 Start with minimal setup"
|
||||
|
||||
VIOLATION_CONSEQUENCES:
|
||||
- if_skipped: "IMMEDIATE STOP - Restart from Phase 3"
|
||||
- required_response: "I must validate this analysis with you before proceeding"
|
||||
```
|
||||
|
||||
## Validation Template
|
||||
|
||||
I **MUST** present this analysis to the user:
|
||||
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: [detected_framework]
|
||||
- Architecture: [detected_pattern]
|
||||
- Complexity: [score]/1.0
|
||||
- Phase: [project_phase]
|
||||
|
||||
**Quality Standards:**
|
||||
[detected_tools_and_standards]
|
||||
|
||||
**Files Analyzed:**
|
||||
[list_of_key_files_examined]
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer for the initial setup?
|
||||
```
|
||||
|
||||
## Validation Components
|
||||
|
||||
### 1. Detected Configuration
|
||||
|
||||
Present the consolidated analysis from Phase 1:
|
||||
|
||||
```yaml
|
||||
configuration_display:
|
||||
framework:
|
||||
format: "[Framework Name] with [Key Libraries]"
|
||||
examples:
|
||||
- "FastAPI with SQLAlchemy"
|
||||
- "React with TypeScript and Redux"
|
||||
- "Axum with Tokio and SQLx"
|
||||
|
||||
architecture:
|
||||
format: "[Pattern Name] ([Key Characteristics])"
|
||||
examples:
|
||||
- "Hexagonal (Ports & Adapters)"
|
||||
- "Component-based with Redux state management"
|
||||
- "Clean Architecture with DDD"
|
||||
|
||||
complexity:
|
||||
format: "[score]/1.0 ([complexity_level])"
|
||||
levels:
|
||||
- "0.0-0.3: Low"
|
||||
- "0.3-0.6: Moderate"
|
||||
- "0.6-0.8: High"
|
||||
- "0.8-1.0: Very High"
|
||||
|
||||
phase:
|
||||
format: "[phase_name] ([duration])"
|
||||
phases:
|
||||
- "Startup (0-6 months)"
|
||||
- "Growth (6-18 months)"
|
||||
- "Enterprise (18+ months)"
|
||||
- "Legacy (maintenance mode)"
|
||||
```
|
||||
|
||||
### 2. Quality Standards
|
||||
|
||||
Present the detected tools and standards:
|
||||
|
||||
```yaml
|
||||
quality_standards_display:
|
||||
testing:
|
||||
format: "[framework] with [coverage]% coverage"
|
||||
examples:
|
||||
- "pytest with 75% coverage"
|
||||
- "jest with React Testing Library"
|
||||
- "cargo test with 80% coverage"
|
||||
|
||||
linting:
|
||||
format: "[linter] with [config_file] config"
|
||||
examples:
|
||||
- "ruff with pyproject.toml config"
|
||||
- "ESLint with Airbnb config"
|
||||
- "clippy with custom clippy.toml"
|
||||
|
||||
type_checking:
|
||||
format: "[type_checker] in [mode] mode"
|
||||
examples:
|
||||
- "mypy in strict mode"
|
||||
- "TypeScript strict mode"
|
||||
- "Rust's built-in type system"
|
||||
|
||||
ci_cd:
|
||||
format: "[ci_system] detected"
|
||||
examples:
|
||||
- "GitHub Actions detected"
|
||||
- "GitLab CI configured"
|
||||
- "No CI detected"
|
||||
|
||||
security:
|
||||
format: "[status]"
|
||||
examples:
|
||||
- "No major vulnerabilities detected"
|
||||
- "2 outdated dependencies found"
|
||||
- "Security scan recommended"
|
||||
```
|
||||
|
||||
### 3. Files Analyzed
|
||||
|
||||
Show what was examined to build confidence:
|
||||
|
||||
```yaml
|
||||
files_display:
|
||||
format: "- [file_path]: [what_was_found]"
|
||||
examples:
|
||||
- "pyproject.toml: FastAPI, SQLAlchemy, pytest dependencies"
|
||||
- "src/domain/: Clean domain layer detected"
|
||||
- "src/infrastructure/: Repository pattern found"
|
||||
- "tests/: Good test coverage structure"
|
||||
- "package.json: React 18, TypeScript 5, Jest"
|
||||
- "src/components/: Hooks-based components"
|
||||
- "Cargo.toml: axum, tokio, sqlx dependencies"
|
||||
- "src/lib.rs: Layered module structure"
|
||||
```
|
||||
|
||||
## User Response Handling
|
||||
|
||||
### Option 1: ✅ Proceed with detected setup
|
||||
|
||||
```yaml
|
||||
proceed:
|
||||
user_says: "Proceed with detected setup" | "Looks good" | "Yes" | "Continue"
|
||||
action: "Move to Phase 4 with all detected settings"
|
||||
no_changes: true
|
||||
```
|
||||
|
||||
### Option 2: 🔄 Modify detected patterns
|
||||
|
||||
```yaml
|
||||
modify:
|
||||
user_says: "Modify detected patterns" | "Change something" | "Adjust"
|
||||
follow_up_questions:
|
||||
- "What would you like to change?"
|
||||
- "Which aspect needs adjustment? (framework/architecture/quality standards)"
|
||||
|
||||
common_modifications:
|
||||
- Change complexity threshold
|
||||
- Adjust test coverage requirements
|
||||
- Modify linting rules
|
||||
- Update architecture pattern choice
|
||||
- Change project phase classification
|
||||
|
||||
example_dialogue:
|
||||
user: "Modify detected patterns"
|
||||
me: "What would you like to adjust?"
|
||||
user: "Change coverage requirement to 90%"
|
||||
me: "Updated coverage threshold to 90%. Anything else?"
|
||||
user: "No, proceed"
|
||||
me: "[Move to Phase 4 with modifications]"
|
||||
```
|
||||
|
||||
### Option 3: 📝 Custom architecture description
|
||||
|
||||
```yaml
|
||||
custom:
|
||||
user_says: "Custom architecture" | "I'll describe it" | "Let me explain"
|
||||
follow_up: "Please describe your project architecture"
|
||||
|
||||
collect_information:
|
||||
- Architecture pattern (if different from detected)
|
||||
- Key components and their responsibilities
|
||||
- Technology choices and rationale
|
||||
- Quality standards and thresholds
|
||||
- Testing strategy
|
||||
|
||||
example_dialogue:
|
||||
user: "Custom architecture description"
|
||||
me: "Please describe your architecture approach"
|
||||
user: "We use Clean Architecture with CQRS, event sourcing for writes..."
|
||||
me: "Got it. I'll use your custom architecture description. Proceed?"
|
||||
user: "Yes"
|
||||
me: "[Move to Phase 4 with custom architecture]"
|
||||
```
|
||||
|
||||
### Option 4: 🚫 Start with minimal setup
|
||||
|
||||
```yaml
|
||||
minimal:
|
||||
user_says: "Minimal setup" | "Keep it simple" | "Basic only"
|
||||
action: "Create minimal configuration without detected patterns"
|
||||
|
||||
minimal_setup_includes:
|
||||
- Basic AGENT.md (standard workflow rules)
|
||||
- Basic ARCHITECTURE.md template (user fills in later)
|
||||
- CLAUDE.md entry point
|
||||
- Directory structure
|
||||
- No language-specific customization
|
||||
- No framework detection applied
|
||||
|
||||
example_dialogue:
|
||||
user: "Start with minimal setup"
|
||||
me: "I'll create a minimal setup without framework-specific customization."
|
||||
me: "[Move to Phase 4 with minimal config]"
|
||||
```
|
||||
|
||||
## Validation Examples
|
||||
|
||||
### Example 1: Python FastAPI Project
|
||||
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: FastAPI with SQLAlchemy
|
||||
- Architecture: Hexagonal (Ports & Adapters)
|
||||
- Complexity: 0.65/1.0 (moderate)
|
||||
- Phase: Growth (6-18 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: pytest with 75% coverage
|
||||
- Linting: ruff with pyproject.toml config
|
||||
- Type checking: mypy in strict mode
|
||||
- CI/CD: GitHub Actions detected
|
||||
- Security: No major vulnerabilities detected
|
||||
|
||||
**Files Analyzed:**
|
||||
- pyproject.toml: FastAPI, SQLAlchemy, pytest dependencies
|
||||
- src/domain/: Clean domain layer detected
|
||||
- src/infrastructure/: Repository pattern found
|
||||
- tests/: Good test coverage structure
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer for the initial setup?
|
||||
```
|
||||
|
||||
### Example 2: React TypeScript Project
|
||||
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: React with TypeScript
|
||||
- Architecture: Component-based with Redux state management
|
||||
- Complexity: 0.70/1.0 (high)
|
||||
- Phase: Growth (6-18 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: Jest with React Testing Library
|
||||
- Linting: ESLint with Airbnb config
|
||||
- Type checking: TypeScript strict mode
|
||||
- CI/CD: GitHub Actions detected
|
||||
- Security: 2 outdated dependencies (non-critical)
|
||||
|
||||
**Files Analyzed:**
|
||||
- package.json: React 18.2, TypeScript 5.0, Jest, ESLint
|
||||
- src/components/: Hooks-based component architecture
|
||||
- src/store/: Redux Toolkit slices and sagas
|
||||
- tests/: 82% test coverage
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer for the initial setup?
|
||||
```
|
||||
|
||||
### Example 3: Rust Axum Project
|
||||
|
||||
```
|
||||
## Project Analysis Validation ✋
|
||||
|
||||
**Detected Configuration:**
|
||||
- Framework: Axum with Tokio and SQLx
|
||||
- Architecture: Layered with clear module boundaries
|
||||
- Complexity: 0.55/1.0 (moderate)
|
||||
- Phase: Startup (0-6 months)
|
||||
|
||||
**Quality Standards:**
|
||||
- Testing: cargo test with 68% coverage
|
||||
- Linting: clippy with custom rules
|
||||
- Type checking: Rust's built-in system
|
||||
- CI/CD: No CI detected
|
||||
- Security: All dependencies up to date
|
||||
|
||||
**Files Analyzed:**
|
||||
- Cargo.toml: axum 0.7, tokio 1.35, sqlx 0.7
|
||||
- src/lib.rs: Well-structured module hierarchy
|
||||
- src/handlers/: Clean separation of concerns
|
||||
- tests/: Integration tests present
|
||||
|
||||
## Your Options:
|
||||
- ✅ Proceed with detected setup
|
||||
- 🔄 Modify detected patterns
|
||||
- 📝 Custom architecture description
|
||||
- 🚫 Start with minimal setup
|
||||
|
||||
What would you prefer for the initial setup?
|
||||
```
|
||||
|
||||
## Enforcement Rules
|
||||
|
||||
### ❌ NEVER Skip Validation
|
||||
|
||||
```yaml
|
||||
prohibited_actions:
|
||||
- Proceeding to Phase 4 without user approval
|
||||
- Assuming user wants default configuration
|
||||
- Auto-selecting "Proceed" option
|
||||
- Skipping validation "to save time"
|
||||
|
||||
required_behavior:
|
||||
- ALWAYS present full analysis
|
||||
- ALWAYS wait for explicit user choice
|
||||
- ALWAYS confirm understanding of user's choice
|
||||
- ALWAYS document which option was chosen
|
||||
```
|
||||
|
||||
### ✅ Required Confirmation
|
||||
|
||||
Before moving to Phase 4, I must have:
|
||||
1. Presented complete analysis to user
|
||||
2. Shown all 4 options
|
||||
3. Received explicit user selection
|
||||
4. Confirmed understanding of selection
|
||||
|
||||
Only then can I proceed to Phase 4.
|
||||
|
||||
---
|
||||
|
||||
*This validation workflow ensures users have full control and understanding of their project setup before any files are generated.*
|
||||
226
skills/initializing-project/languages.yaml
Normal file
226
skills/initializing-project/languages.yaml
Normal file
@@ -0,0 +1,226 @@
|
||||
# Language-specific configurations for Quaestor templates
|
||||
# This file defines tooling, commands, and conventions for different programming languages
|
||||
|
||||
python:
|
||||
primary_language: python
|
||||
lint_command: "ruff check ."
|
||||
format_command: "ruff format ."
|
||||
test_command: pytest
|
||||
coverage_command: "pytest --cov"
|
||||
type_check_command: "mypy ."
|
||||
security_scan_command: "bandit -r src/"
|
||||
profile_command: "python -m cProfile"
|
||||
coverage_threshold: 80
|
||||
type_checking: true
|
||||
performance_target_ms: 200
|
||||
commit_prefix: feat
|
||||
quick_check_command: "ruff check . && pytest -x"
|
||||
full_check_command: "ruff check . && ruff format --check . && mypy . && pytest"
|
||||
precommit_install_command: "pre-commit install"
|
||||
doc_style_example: |
|
||||
def example_function(param: str) -> str:
|
||||
"""
|
||||
Brief description of what the function does.
|
||||
|
||||
Args:
|
||||
param: Description of the parameter
|
||||
|
||||
Returns:
|
||||
Description of return value
|
||||
|
||||
Raises:
|
||||
ValueError: When param is invalid
|
||||
"""
|
||||
pass
|
||||
|
||||
javascript:
|
||||
primary_language: javascript
|
||||
lint_command: "npx eslint ."
|
||||
format_command: "npx prettier --write ."
|
||||
test_command: "npm test"
|
||||
coverage_command: "npm test -- --coverage"
|
||||
type_check_command: "npx tsc --noEmit"
|
||||
security_scan_command: "npm audit"
|
||||
profile_command: "node --prof"
|
||||
coverage_threshold: 80
|
||||
type_checking: false
|
||||
performance_target_ms: 100
|
||||
commit_prefix: feat
|
||||
quick_check_command: "npm run lint && npm test -- --bail"
|
||||
full_check_command: "npm run lint && npm run prettier:check && npm test"
|
||||
precommit_install_command: "husky install"
|
||||
doc_style_example: |
|
||||
/**
|
||||
* Brief description of what the function does.
|
||||
*
|
||||
* @param {string} param - Description of the parameter
|
||||
* @returns {string} Description of return value
|
||||
* @throws {Error} When param is invalid
|
||||
*/
|
||||
function exampleFunction(param) {
|
||||
// Implementation
|
||||
}
|
||||
|
||||
typescript:
|
||||
primary_language: typescript
|
||||
lint_command: "npx eslint . --ext .ts,.tsx"
|
||||
format_command: "npx prettier --write ."
|
||||
test_command: "npm test"
|
||||
coverage_command: "npm test -- --coverage"
|
||||
type_check_command: "npx tsc --noEmit"
|
||||
security_scan_command: "npm audit"
|
||||
profile_command: "node --prof"
|
||||
coverage_threshold: 80
|
||||
type_checking: true
|
||||
performance_target_ms: 100
|
||||
commit_prefix: feat
|
||||
quick_check_command: "npm run lint && npm run type-check && npm test -- --bail"
|
||||
full_check_command: "npm run lint && npm run prettier:check && npm run type-check && npm test"
|
||||
precommit_install_command: "husky install"
|
||||
doc_style_example: |
|
||||
/**
|
||||
* Brief description of what the function does.
|
||||
*
|
||||
* @param param - Description of the parameter
|
||||
* @returns Description of return value
|
||||
* @throws {Error} When param is invalid
|
||||
*/
|
||||
function exampleFunction(param: string): string {
|
||||
// Implementation
|
||||
}
|
||||
|
||||
rust:
|
||||
primary_language: rust
|
||||
lint_command: "cargo clippy -- -D warnings"
|
||||
format_command: "cargo fmt"
|
||||
test_command: "cargo test"
|
||||
coverage_command: "cargo tarpaulin"
|
||||
type_check_command: "cargo check"
|
||||
security_scan_command: "cargo audit"
|
||||
profile_command: "cargo bench"
|
||||
coverage_threshold: 80
|
||||
type_checking: true
|
||||
performance_target_ms: 50
|
||||
commit_prefix: feat
|
||||
quick_check_command: "cargo check && cargo clippy && cargo test -- --fail-fast"
|
||||
full_check_command: "cargo fmt -- --check && cargo clippy -- -D warnings && cargo test"
|
||||
precommit_install_command: "pre-commit install"
|
||||
doc_style_example: |
|
||||
/// Brief description of what the function does.
|
||||
///
|
||||
/// # Arguments
|
||||
///
|
||||
/// * `param` - Description of the parameter
|
||||
///
|
||||
/// # Returns
|
||||
///
|
||||
/// Description of return value
|
||||
///
|
||||
/// # Errors
|
||||
///
|
||||
/// Returns `Error` when param is invalid
|
||||
pub fn example_function(param: &str) -> Result<String, Error> {
|
||||
// Implementation
|
||||
}
|
||||
|
||||
go:
|
||||
primary_language: go
|
||||
lint_command: "golangci-lint run"
|
||||
format_command: "go fmt ./..."
|
||||
test_command: "go test ./..."
|
||||
coverage_command: "go test -cover ./..."
|
||||
type_check_command: "go vet ./..."
|
||||
security_scan_command: "gosec ./..."
|
||||
profile_command: "go test -cpuprofile=cpu.prof"
|
||||
coverage_threshold: 80
|
||||
type_checking: true
|
||||
performance_target_ms: 50
|
||||
commit_prefix: feat
|
||||
quick_check_command: "go vet ./... && go test -short ./..."
|
||||
full_check_command: "go fmt ./... && go vet ./... && golangci-lint run && go test ./..."
|
||||
precommit_install_command: "pre-commit install"
|
||||
doc_style_example: |
|
||||
// ExampleFunction does a brief description of what the function does.
|
||||
//
|
||||
// Parameters:
|
||||
// - param: Description of the parameter
|
||||
//
|
||||
// Returns:
|
||||
// - string: Description of return value
|
||||
// - error: When param is invalid
|
||||
func ExampleFunction(param string) (string, error) {
|
||||
// Implementation
|
||||
}
|
||||
|
||||
java:
|
||||
primary_language: java
|
||||
lint_command: "mvn checkstyle:check"
|
||||
format_command: "mvn spotless:apply"
|
||||
test_command: "mvn test"
|
||||
coverage_command: "mvn jacoco:report"
|
||||
type_check_command: "mvn compile"
|
||||
security_scan_command: "mvn dependency-check:check"
|
||||
profile_command: "mvn test -Dtest.profile=true"
|
||||
coverage_threshold: 80
|
||||
type_checking: true
|
||||
performance_target_ms: 100
|
||||
commit_prefix: feat
|
||||
quick_check_command: "mvn compile && mvn test -Dtest=*UnitTest"
|
||||
full_check_command: "mvn checkstyle:check && mvn compile && mvn test"
|
||||
precommit_install_command: "pre-commit install"
|
||||
doc_style_example: |
|
||||
/**
|
||||
* Brief description of what the method does.
|
||||
*
|
||||
* @param param Description of the parameter
|
||||
* @return Description of return value
|
||||
* @throws IllegalArgumentException When param is invalid
|
||||
*/
|
||||
public String exampleMethod(String param) {
|
||||
// Implementation
|
||||
}
|
||||
|
||||
ruby:
|
||||
primary_language: ruby
|
||||
lint_command: "rubocop"
|
||||
format_command: "rubocop --autocorrect"
|
||||
test_command: "bundle exec rspec"
|
||||
coverage_command: "bundle exec rspec --format progress"
|
||||
type_check_command: "bundle exec sorbet tc"
|
||||
security_scan_command: "bundle audit"
|
||||
profile_command: "ruby-prof"
|
||||
coverage_threshold: 80
|
||||
type_checking: false
|
||||
performance_target_ms: 150
|
||||
commit_prefix: feat
|
||||
quick_check_command: "rubocop && bundle exec rspec --fail-fast"
|
||||
full_check_command: "rubocop && bundle exec rspec && bundle audit"
|
||||
precommit_install_command: "pre-commit install"
|
||||
doc_style_example: |
|
||||
# Brief description of what the method does.
|
||||
#
|
||||
# @param param [String] Description of the parameter
|
||||
# @return [String] Description of return value
|
||||
# @raise [ArgumentError] When param is invalid
|
||||
def example_method(param)
|
||||
# Implementation
|
||||
end
|
||||
|
||||
# Default configuration for unknown project types
|
||||
unknown:
|
||||
primary_language: "unknown"
|
||||
lint_command: "# Configure your linter"
|
||||
format_command: "# Configure your formatter"
|
||||
test_command: "# Configure your test runner"
|
||||
coverage_command: "# Configure coverage tool"
|
||||
type_check_command: null
|
||||
security_scan_command: null
|
||||
profile_command: null
|
||||
coverage_threshold: null
|
||||
type_checking: false
|
||||
performance_target_ms: 200
|
||||
commit_prefix: chore
|
||||
quick_check_command: "make check"
|
||||
full_check_command: "make validate"
|
||||
precommit_install_command: "pre-commit install"
|
||||
doc_style_example: null
|
||||
Reference in New Issue
Block a user