Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:50:24 +08:00
commit f172746dc6
52 changed files with 17406 additions and 0 deletions

View 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.*

View 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.*

View 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!*

View 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.*

View 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.*

View 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