shipshitdev/how
skills/how/SKILL.md
Walk through how a subsystem works. Use for "how does X work", code walkthroughs before changing something, and placement or ownership questions. Explains architecture, runtime flow, and onboarding mental models. Can critique architecture. Use why for motivation.
$ install --global
skillsauthnpx skillsauth add shipshitdev/library howInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Aug 31, 2026, 2:40 AM240.8s4 files scanned
SKILL.md
- name:
- how
- description:
- Walk through how a subsystem works. Use for "how does X work", code walkthroughs before changing something, and placement or ownership questions. Explains architecture, runtime flow, and onboarding mental models. Can critique architecture. Use why for motivation.
- license:
- MIT
- version:
- 1.0.0
- tags:
- architecture, walkthrough, onboarding, critique
- author:
- Ship Shit Dev
- source:
- https://github.com/cursor/plugins/blob/main/pstack/skills/how/SKILL.md
- upstream_repo:
- cursor/plugins
- upstream_ref:
- main
- upstream_commit:
- bdf7aa355337
- last_synced:
- 2026-08-26
How
Explore the codebase to answer "how does X work?" Produce an architectural explanation at the level of a senior engineer onboarding onto a subsystem.
Two modes:
- Explain (default). Explore and produce a clear explanation.
- Critique. Explain first, then spawn independent critics.
Companion to why. This skill answers what the code does. why answers
what forces led to its shape.
Contract
Inputs:
- A how-question: subsystem, feature flow, architectural overview, or runtime trace
Outputs:
- The structured explanation below
- In Critique mode, a lead verdict over critic findings
Creates/Modifies:
- None
External Side Effects:
- None. Read-only exploration.
Confirmation Required:
- None
Delegates To:
- None. May spawn read-only explorer, explainer, and critic subagents.
Explain mode
Step 1. Understand the question
Parse the ask. If ambiguous, state the best-guess interpretation and proceed. Do not ask. Let the user redirect.
Simple (one module, a narrow function): skip explorer agents. The explainer explores and explains in one pass.
Complex (multiple files or services, a cross-cutting feature): spawn 2-4 parallel explorers, then one explainer. When in doubt, lean simple.
Step 2a. Explore (complex only)
Decompose into 2-4 distinct slices so explorers do not duplicate work. Spawn all explorers in one message on the fast cheap tier, read-only. Each explorer gets references/explorer-prompt.md plus its slice. Each traces input to output without hand-waving.
Step 2b. Direct explain (simple)
Spawn one read-only explainer on the strongest judgment tier. It explores and writes the explanation. Use references/explainer-prompt.md.
Step 3. Synthesize (complex only)
Once explorers return, spawn one explainer on the strongest judgment tier with all findings. It reconciles overlap and contradictions.
Step 4. Present
Present the explainer's output. Light edits for clarity are fine. Do not substantially rewrite.
Output format
Overview. 1-2 paragraphs. What it is, what it does, why it exists.
Key Concepts. The types, services, or abstractions needed to follow the rest.
How It Works. The flow: trigger, steps, data, decision points. Prose, not pseudocode. Cite files and functions.
Where Things Live. A brief map of the relevant files.
Gotchas. Non-obvious edges and historical scars.
Critique mode
Triggered when the user asks for architectural issues, not just understanding.
- Run the full explain flow.
- Spawn one architectural critic per available judgment family, all in one message, read-only, on mixed capability tiers. Each gets the explanation, file paths, references/critic-prompt.md, and references/critique-rubric.md.
- Lead judgment. Categorize findings: Act on, Consider, Noted, Dismissed. Present the explanation first, then the critique.
Related Skills
shipshitdev/weekly-review
development
VerifiedTrustedCommunity
Coordinates a weekly engineering review of board accuracy, recent code changes, operational health, and scoped cleanup. Use for a recurring repository health review or a review of the last several days.
35SKILL.mdUpdated Sep 6, 2026
shipshitdev/project-board
testing
VerifiedTrustedCommunity
Audits project board configuration and prepares explicitly requested setup, copy, or normalization changes while preserving the existing workflow and provider boundaries. Use when inspecting a board's fields, columns, scope, or configuration.
35SKILL.mdUpdated Sep 6, 2026
shipshitdev/board-sync
testing
VerifiedTrustedCommunity
Reconciles a project board with current work and delivery evidence, reports incomplete coverage and metadata gaps, and applies only approved provider-supported field changes. Use when auditing board drift, reviewing blocked work, or assessing upcoming delivery.
35SKILL.mdUpdated Sep 6, 2026
shipshitdev/grok-review
tools
VerifiedTrustedCommunity
Independent second-opinion code review through the Grok CLI. Builds a self-contained review prompt from the exact diff, runs one headless Grok invocation on the CLI's own default model and effort, then verifies every returned finding against the code before reporting. Use when asked to review with Grok, get a second opinion on a branch, worktree, or PR from another CLI, or cross-check a review with an independent engine.
35SKILL.mdUpdated Aug 31, 2026