Execute broad changes one coherent, independently verifiable stage at a time. Use when work spans multiple independently reviewable changes, or when contracts, producer-consumer migrations, generated artefacts, or release packaging create an ordered multi-stage rollout; skip small single-purpose changes.

2026-07-105

git-commit

timmo001/dotfiles

Commit workflow using the dot git-commit gateway in the maintainer's concise one-line style. Use only after the user explicitly requests a commit or push, including /commit or /commit-push. Never infer repeat authorisation from an earlier commit or push; never run raw git commit.

2026-07-105

git-context

timmo001/dotfiles

Patterns for working with git branches, remotes, diffs against the default branch, and rebases. Use when resolving rebase conflicts, continuing interactive rebases, amending commits, or any git operation that would open an interactive editor.

2026-07-105

research

timmo001/dotfiles

Investigate a topic against primary sources and return cited findings, comparing credible maintainer and contributor perspectives when judgement is involved. Use when the user wants a topic researched, docs, API, or spec facts gathered, an external library or GitHub behaviour verified, competing views compared, or reading legwork delegated to a background agent.

2026-07-105

ask-questions-if-underspecified

timmo001/dotfiles

Ask minimal clarifying questions only when ambiguity materially changes implementation. Use for routine underspecification; do not use for user-requested light or full grilling, plan stress-testing, or broad design interviews.

2026-07-105

grill-questions

timmo001/dotfiles

Stress-test a plan or proposed change through focused one-question-at-a-time grilling, with light and full intensity. Use when the user says grill, grill me, grill me lightly, ask me a couple of questions, stress-test this plan, or wants question-led scrutiny before planning.

2026-07-105

name	lit-rendering
description	Lit rendering and picker callback-shape guidance for editing and reviewing Lit components.

Lit Rendering

Use this skill when reviewing or editing Lit rendering logic:

Preserve runtime behavior and public API shape unless the user asked otherwise.
Prefer render-local derived values for UI-only structures (sections, options, grouped labels, display rows).
Compute derived render data once per render and reuse it across template call sites.
Do not create render-local booleans, labels, classes, or wrapper variables unless they are reused, clarify a complex branch, or prevent repeated expensive/side-effectful work. For example, avoid const params = this._params, const data = this._data, or const selected = this._selected when direct this._xyz access is just as clear and typechecks.
Use memoizeOne only for pure transforms with explicit, narrow inputs.
Do not memoize using broad inputs (this, large mutable objects) when narrower inputs are available.
Do not widen signatures with pass-through values when class/context access already exists.
Do not add passthrough fields used only to thread values through helper calls.
Do not add @state fields or willUpdate only to cache render-derived picker data.
Use lifecycle hooks for real update-phase behavior, not as a substitute for render-local composition.
When replacing a component's built-in header with a custom conditional header, preserve the original header/title behavior on every branch that does not render the custom header.
Do not add unnecessary comments or abstractions.