All public WinterSolve commands must use the clean prefix:
wintersolve <workflow> [options]
Examples:
wintersolve brain .
wintersolve scan .
wintersolve explain src/wintersolve/cli.pyDo not document public workflows as script paths. Script paths are only development fallbacks.
Inspect a repository and produce a health report.
wintersolve scan .Useful for:
- Understanding project structure
- Detecting languages and stack markers
- Finding missing open-source files
- Spotting test and documentation gaps
Build a full project intelligence report.
wintersolve brain .Markdown output:
wintersolve brain . --format markdownJSON output for tools:
wintersolve brain . --format json --output wintersolve-report.jsonUseful for:
- Understanding a repository quickly
- Mapping architecture and important project areas
- Detecting commands, risks, and missing project hygiene
- Checking security and privacy posture
- Creating contributor onboarding notes
Explain a file using offline static analysis.
wintersolve explain src/wintersolve/cli.pyUseful for:
- Onboarding into unfamiliar files
- Finding symbols, imports, and file-level risks
- Getting a quick summary before editing
Analyze an error message, log, or stack trace.
wintersolve debug --text "ModuleNotFoundError: No module named demo"Or:
wintersolve debug --file error.logUseful for:
- Understanding common Python and Node.js errors
- Finding likely causes
- Creating next-step debugging checklists
Suggest documentation improvements.
wintersolve docs . --draft-readmeUseful for:
- Improving README structure
- Preparing open-source repositories
- Creating starter documentation drafts
Review local Git changes and produce a checklist.
wintersolve review .Useful for:
- Preparing pull requests
- Checking changed files for risk areas
- Creating review notes before asking others for feedback