potetos-for-everyone 0.1.0

package/skills/tdd/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: tdd
+description: Write a minimal failing test before implementation, make it pass with the simplest code, and refactor cleanly. Use when implementing bug fixes or features with clear verification targets.
+---
+# Test-Driven Development (TDD)
+
+1. Understand the exact requirement or bug and identify the narrowest executable check.
+2. Write the failing test first. Ensure it fails for the expected reason, not a setup or syntax error.
+3. Implement the minimal production code needed to make the failing test pass. Avoid speculative features.
+4. Re-run the test to confirm green.
+5. Refactor: clean up names, remove duplication, and simplify structure while keeping tests green.
+6. Verify adjacent tests and broader contracts to ensure no regressions.

package/skills/teach/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: teach
+description: Teach a subsystem or change so the reader can reason about it, combining how and why evidence. Use for real understanding rather than summary.
+---
+# Teach
+
+1. Run the substance of `how` and, when historical rationale matters, `why`.
+2. Start with the smallest mental model that predicts behavior.
+3. Add one layer at a time: actors/data, control flow, invariants, edge cases, then rationale/tradeoffs.
+4. Use tiny diagrams and concrete examples that can be checked against the code.
+5. End with a few prediction questions or "what would happen if" cases that test understanding, with answers only when useful.

package/skills/technical-writing/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: technical-writing
+description: Write maintainable technical docs, RFCs, READMEs, PR descriptions, and commit messages. Use for durable engineering prose.
+---
+# Technical Writing
+
+1. Identify the reader and the action/decision the document should enable.
+2. Put prerequisites and outcome before implementation history.
+3. Use task-oriented sections for procedures, concept-oriented sections for mental models, and reference tables only for lookup material.
+4. Keep terminology stable and sentences concrete. Define unavoidable jargon once.
+5. Examples must be runnable or explicitly illustrative. Never fabricate commands, links, benchmarks, or compatibility claims.
+6. For change documents, include impact, design/behavior, verification, migration/rollback if relevant, and open risks.

package/skills/typescript-best-practices/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: typescript-best-practices
+description: Apply disciplined TypeScript modeling and boundary parsing. Use when reading or editing TypeScript.
+---
+# TypeScript Best Practices
+
+- Parse unknown external data at the boundary; keep `unknown` until validated.
+- Prefer discriminated unions for mutually exclusive states and exhaustive handling for closed variants.
+- Give domain meaning to primitives when accidental mixing would be costly.
+- Avoid widening useful literal information and avoid `any` as an escape hatch.
+- Let callers consume one coherent return shape instead of correlated optional fields.
+- Use generics only when they express a real relationship between inputs and outputs.
+- Keep async/error states explicit at the public boundary.
+- Test behavior through exported APIs, not private helper choreography.

package/skills/unslop/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: unslop
+description: Cut AI tells, filler prose, superficial -ing phrases, and bloated commentary from writing and code. Use for all written deliverables and code cleanup.
+---
+# Unslop
+
+1. Scan text and code comments for AI tells: vague attributions, superficial -ing clauses, throat-clearing intros, and repetitive summaries.
+2. Remove filler, passive voice, and conversational bloat.
+3. State facts, changes, and instructions directly and concisely.
+4. Retain technical precision, file links, concrete numbers, and reproduction steps.
+5. Audit the final text: ensure every sentence delivers direct information.

package/skills/why/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: why
+description: Recover why a system or decision exists by triangulating source history and connected evidence. Use for rationale archaeology and historical questions.
+---
+# Why
+
+Recover rationale without inventing intent.
+
+1. State the exact decision whose rationale matters.
+2. Discover available evidence sources. Prefer source history, code review/PRs, issues, design docs, chat, observability, and analytics in roughly that order of directness for the claim at hand.
+3. If `search`/connected systems and `delegate` exist, query independent evidence categories in parallel. Otherwise search sequentially.
+4. Separate contemporaneous evidence from later interpretation. A current comment is not proof of an old motive.
+5. Triangulate at least two sources for strong intent claims when possible.
+6. Return: decision, strongest evidence, inferred rationale, alternatives considered if evidenced, what changed since, and unresolved uncertainty.