Skip to content

index.md

Latest commit

 

History

History
65 lines (48 loc) · 3.14 KB

index.md

File metadata and controls

65 lines (48 loc) · 3.14 KB
Raw

Agent Guidelines

TanStack.com marketing site built with TanStack Start.

Core principles for every task

Before writing code, walk this ladder. Stop at the first answer that works.

  1. Does this need to exist? → no: skip it (YAGNI)
  2. Already in this codebase? → reuse it, don't rewrite
  3. Stdlib does it? → use it
  4. Native platform feature? → use it
  5. Installed dependency? → use it
  6. One line? → one line
  7. Only then: the minimum that works

Inspired by https://github.com/DietrichGebert/ponytail

Abstraction & repetition

  • KISS — keep it simple, stupid. Boring code beats clever code.
  • WET > DRY — write everything twice (or more) before abstracting. Three similar usages with diverging needs is the cue to extract; two is not.
  • Premature DRY couples unrelated code through a shared abstraction that ends up fighting both callers. Duplication is cheaper than the wrong abstraction.

What this means in practice

  • Don't add error handling, fallbacks, or validation for cases that can't happen.
  • Don't introduce helpers, wrappers, or config knobs "for later."
  • Don't refactor surrounding code while fixing a bug.
  • When tempted to abstract: count the call sites and check they actually want the same behavior. If not, leave the duplication.

Essentials

  • Package manager: pnpm
  • Run pnpm test before commits not after every tiny edit
  • Don't run builds or tests after every change. This is a visual site; assume changes work unless reported otherwise.
  • Rely on tsc or your built-in LSP integration (hopefully you have this)
  • Typesafety is paramount. Never cast types; fix at source instead. See typescript.md.

Topic Guides

Writing and documentation

Use tanner-writing-style for public front-page headings and marketing copy, and editorial-restraint for clarity and grounded claims, when those skills are available. Front-page copy should be personable, punchy, and informal. Lead with the benefit and preserve supplied sales emphasis while polishing awkward phrasing. Concrete grounding does not require API names in every headline or subhead; examples and linked documentation can carry that detail.

Keep API references and technical guides precise and approachable. Preserve identifiers and explain actual behavior and relevant limitations without imposing the marketing voice on reference documentation.

Read relevant implementation, contracts, and examples before changing product claims. Keep capabilities, measurements, guarantees, and comparisons accurate. If a consequential claim is unsupported, offer a stronger accurate alternative briefly and continue within the requested scope. Subjective praise and useful promotional hooks do not need to become dry technical prose.