swe-writeups

Plugin swe-writeups from marketplace msradam-skills in msradam/skills. Commands read from the repo's manifest — 1 month ago.

Skills (18)

• api-design-audit

  Review a public API, interface, or function signature against Joshua Bloch's API design principles — easy to use correctly, hard to misuse, minimal surface area, and consistent. Use when designing a new public interface/library/function signature, or reviewing one someone else proposed.

• code-documentation-audit

  Audit or write inline code documentation (docstrings, doc comments, reference/API docs) against PEP 257's docstring conventions and the Divio documentation system's four document types. Use when writing docstrings, reviewing whether documentation is complete, or deciding what kind of document (tutor

• code-review-audit

  Apply Google's Engineering Practices standards for how a code review should be conducted and communicated — what to actually check for, how to phrase feedback so it lands well, and when a nit should block a merge versus not. Use when reviewing a PR/diff/CL, or writing review comments, especially to

• comment-audit

  Audit and fix code comments — flag comments that restate the code instead of explaining why, stale comments that no longer match the code, comments used to excuse unclear code instead of fixing it, and undocumented TODOs. Use when asked to review, audit, clean up, or write comments, or when comments

• commit-message-audit

  Write or fix git commit messages against Chris Beams' seven-rule standard — proper subject/body separation, imperative mood, line-wrapping, and explaining why a change was made rather than what changed. Use when drafting a commit message, reviewing one before committing, or cleaning up commit histor

• delight-audit

  Judge whether an interface earns delight, using NN/g's distinction between surface delight (embellishment) and deep delight (which requires the product to be functional, reliable and usable first), plus Amber Case's calm technology principles for products that should sit in the periphery rather than

• error-handling-audit

  Audit error handling for swallowed/ignored errors, lost context, duplicated handling logic, and errors logged and re-thrown at the same time. Use when writing code that can fail, or reviewing try/catch, error returns, or exception handling.

• lint-a11y

  Run deterministic accessibility and performance checks against a running page using pa11y (axe + HTML_CodeSniffer rules) and Lighthouse — actual tool output, not design opinion. Use when asked to check accessibility, run an a11y audit, verify WCAG conformance, or measure page performance.

• lint-go

  Run deterministic static analysis on Go code using go vet (built into the toolchain) and golangci-lint (the standard meta-linter aggregating staticcheck, errcheck, ineffassign, unused, and more) — actual tool output, not stylistic opinion. Use when asked to lint, check, or clean up Go code, before c

• lint-python

  Run deterministic static analysis on Python code using ruff (linting + formatting) and mypy (type checking) — actual tool output, not stylistic opinion. Use when asked to lint, check, or clean up Python code, before committing Python changes, or when Python code quality needs verifying.

• lint-typescript

  Run deterministic static analysis on TypeScript code using tsc (type checking) and eslint with typescript-eslint (linting) — actual tool output, not stylistic opinion. Use when asked to lint, check, or clean up TypeScript/JavaScript code, before committing changes, or when code quality needs verifyi

• logging-audit

  Audit logging calls against Dave Cheney's argument for collapsing severity levels to just Debug (developer-facing) and Info (operator-facing, always visible) — flag level sprawl, error-level logs at points that are just informational, and fatal exits buried deep in library code. Use when adding logg

• marketing-copy-audit

  Audit or write product marketing copy (landing pages, product descriptions, pitches) by first checking whether the underlying positioning is clear — competitive alternatives, differentiated capabilities, value, target market, and market category — since unclear positioning is what makes copy read as

• naming-audit

  Audit identifier names (variables, functions, classes) for pronounceability, searchability, consistent vocabulary, and meaningless differentiation like data1/data2. Use when reviewing code for readability, naming a new identifier, or asked whether a name is good.

• product-critique

  Brutally honest adversarial critique of a product, plan, or startup idea, structured around Marty Cagan's four big risks (value, usability, feasibility, business viability) plus a "is this a real problem" pass. Use when asked to critique, red-team, stress-test, poke holes in, or give honest feedback

• readme-audit

  Audit or write a README against the "cognitive funneling" principle — broad to specific ordering so a skimming reader gets the gist in seconds and only drills in as far as they need. Use when writing a new README, reviewing an existing one, or asked whether a README is clear/complete.

• refactoring-smells

  Detect named code smells (long function, duplicated code, large class, long parameter list, feature envy, primitive obsession, speculative generality, dead code) and apply the matching named refactoring from Martin Fowler's catalog. Use when asked to clean up, refactor, or simplify existing code, or

• test-pyramid-audit

  Audit a test suite's shape against Martin Fowler's test pyramid — flag over-reliance on slow, brittle end-to-end/UI tests when a cheaper unit test would catch the same regression, and recommend or write the missing lower-level test. Use when reviewing test coverage, adding tests for a bug fix, or as

Similar plugins