Run a full audit of a GitHub user's personal repos. Inventories every repo, deep-analyzes each one for problem/goal/state/completion, clusters duplicates, drafts new READMEs for keeps, and emits PowerShell scripts that stage draft PRs and archives. Use when the user says "audit my GitHub", "audit my repos", "review my GitHub projects", "find duplicate repos", "consolidate my projects", "clean up my GitHub", "what should I archive", "deep-clean my repos", "I have too many incomplete projects", or otherwise describes wanting to triage a personal GitHub account with sprawl.
Draft a structured README for a single GitHub repo following a problem/goal/approach/features format. Use when the user says "draft a README for X", "regenerate the README for [repo]", "write a problem statement README", "give me a real README for this", "write a proper README", or wants README content for one specific repo (as opposed to a full multi-repo audit, which is the audit-repos skill). Pulls source-of-truth from the repo's own files — does not invent details.
Application security audit combining static analysis, STRIDE threat modeling, OWASP-aware code review, container/deployment review, and vulnerability intelligence from authoritative sources. USE FOR: security audit after implementation, threat modeling, OWASP compliance check, CVE intelligence gathering. DO NOT USE FOR: code quality review (use code-review), UI/UX review (use ui-ux-review), implementation (use impl-* skills).
Create architecture documents, design documents, and implementable task backlogs from an idea, feature, or system request. Produces system overview, component breakdown, deployment topology, API contracts, data model, ADRs, threat model, observability architecture, and backlog with acceptance criteria. USE FOR: architecture design, feature decomposition, backlog generation, system planning. DO NOT USE FOR: implementation (use impl-* skills), requirements clarification (use requirements-clarification), code review (use code-review).
Review a request, plan, PBI, ADR, architecture doc, proposal, or decision for hidden assumptions, unknowns, logical gaps, missing sections, stakeholder omissions, and risk. Produces severity-tagged findings with specific questions. USE FOR: reviewing plans, specs, proposals, design docs before work starts. DO NOT USE FOR: code review (use code-review), UI review (use ui-ux-review), turning vague requests into specs (use requirements-clarification).
Interrogate a product or business idea across problem-solution fit, target audience, market analysis, business model, and growth strategy. Produces a structured validation report with MVP definition and risk assessment. USE FOR: product idea validation, business model analysis, MVP scoping, market assessment. DO NOT USE FOR: technical architecture (use architecture-planning), requirements specification (use requirements-clarification), implementation (use impl-* skills).
Add or improve in-code documentation for public symbols using language-native formats (JSDoc, Python docstrings, C# XML docs, GoDoc, Javadoc, Rust doc comments). Produces IntelliSense-ready documentation with examples. USE FOR: documenting exported functions, classes, interfaces, types, modules. DO NOT USE FOR: non-code docs like README or config files (use docs-config-authoring), code review (use code-review), implementation (use impl-* skills).
Review changed code for completeness, correctness, conciseness, readability, regressions, missing tests, and standards compliance. Scores across four pillars and produces actionable findings with severity. USE FOR: code review after implementation, quality gate before merge, standards compliance check. DO NOT USE FOR: UI/UX design review (use ui-ux-review), security audit (use appsec-audit), requirements clarification (use requirements-clarification).