Claude Skills by sazardev

Use whenever creating, renaming, or editing any file under docs/ in this repo, or when asked to compile/build the book PDF. Enforces the exact .mdx frontmatter, ID scheme, and heading-depth rules required by the go-pretty-pdf tool (https://github.com/sazardev/go-pretty-pdf) so the whole book keeps compiling.

Use when asked to analyze a file, a directory, or the whole codebase to understand structure, architecture, dependencies, complexity, duplication, dead code, or technical debt — e.g. "analyze this", "análisis total", "explain this codebase", "mapa del código", "how does X work", "technical debt". Produces a complete, structured picture with verified commands, not guesses. Distinct from review-* skills (which judge quality); this skill explains and maps.

Use when asked to audit or harden security in this repo — e.g. "security audit", "auditoría de seguridad", "revisa la seguridad", "is this secure", "hardening", "vulnerabilities". Audits code, config, workflows, and secrets exposure. Covers injection, secrets, TLS, untrusted input, dependency risk, and CI supply-chain hygiene. Runs when the user asks about security, not just for code reviews.

Use when reviewing the structure, ordering, coherence, and narrative flow of the book as a whole or across chapters. Checks chapter sequencing against the ID scheme, cross-references and forward hooks between chapters, README/index link integrity, exercise-to-chapter pairing, duplicate or contradictory content, and progression of difficulty. Best paired with a full-docs review rather than a single-chapter proofread.

Use when writing, expanding, rewriting, or drafting any chapter (.mdx) or Go exercise for this book. Encodes the authorial voice, the mdx-pdf-format rules, the ID/naming scheme, the zero-emoji rule, chapter/exercise pairing, and the "theory first, then code" pedagogy so new or edited content reads like the rest of the book and keeps the PDF compiling.

Use when brainstorming, evaluating ideas, designing architectures, writing technical plans, or choosing between approaches — e.g. "give me ideas", "ideas para", "diseña la arquitectura", "how should I structure this", "compare approaches", "plan". Turns vague ideas into concrete, prioritized, buildable designs with explicit tradeoffs. Use before writing code, not after.

Use when proofreading, copy-editing, or verifying English in any docs/**/*.mdx chapter or code comment in this repo. Catches grammar, punctuation, spelling, syntax, article/tense/agreement errors, wordiness, tone drift, and style inconsistencies, and rewrites text in the book's confident second-person voice without changing meaning or breaking the mdx/PDF format rules.

Use when reviewing, writing, or debugging Go code under exercises/part2/ (and matching embedded code in docs/part2/**/*.mdx). Thinks hard about correctness, idiomatic Go, error handling, resource cleanup, concurrency, and — crucially — what the tests would catch: edge cases, races, leaks, timeouts, and port conflicts. Knows the repo's module-mode quirk (GO111MODULE=off) and which dirs carry go.mod.

Use when asked to map or analyze flows, pipelines, processes, or sequences of events in this repo — e.g. "mapa el flujo", "flow", "pipeline", "ciclo de vida", "trace the request", "how does the build/release flow work", "diagrama del flujo". Maps data flows, request lifecycles, CI/CD pipelines, and state transitions with verified file:line evidence. Distinct from analyze-code (which maps code structure); this skill maps movement over time.

Use when reviewing, debugging, or improving frontend code in this repo (website/ HTML, CSS, JS, service workers, PWA assets) or when asked to "review frontend", "revisa el html/css", "review JS", or "audita el frontend". Reviews for correctness, browser compatibility, accessibility, performance, security (XSS), responsive behavior, and PWA/service-worker correctness, and ends with a "what a user/reviewer would catch" pass.

Use when reviewing, debugging, or giving feedback on Go code in this repo (exercises/part2, website/tools, or any *.go file) or when asked for a "code review", "review this Go", "revisa este código Go", or "crítica de código". Reviews for correctness, idiomatic Go, error handling, resource cleanup, concurrency, performance, and security, and always ends with a test-thinking pass (what a test would catch). For exercises/part2, prefer the go-exercise-reviewer skill which knows the module-mode q...

Use when reviewing, debugging, or hardening Shell/Bash scripts in this repo (.github/workflows/*.yml steps, website build scripts, or any *.sh file) or when asked to "review bash", "revisa el script", "shellcheck", or "revisa el pipeline shell". Reviews for robustness, error handling, quoting, portability, injection, and CI-friendliness, and ends with what a CI failure or a hostile input would catch.