timmo

Plugin timmo from marketplace timmo001-skills in timmo001/skills. Commands read from the repo's manifest — yesterday.

Skills (55)

• agentic-workflows

  Design, create, update, debug, audit, or upgrade GitHub Agentic Workflows with the `gh aw` extension. Use when work involves workflow Markdown, compiled `.lock.yml` files, agent engines, MCP tools, safe outputs, work queues, scheduled memory consolidation, local SDLC issue bootstrap, or `gh aw` comm

• asking-questions

  Decide when to ask the user a question and how to present it. Use before any clarifying question, choice, or confirmation, whether through the Plannotator Inbox or in chat, and to decide whether to hold questions until findings are presented or divert to grilling; do not use to run light or full gri

• bro

  Re-pitch the immediately preceding response with enough context to follow, using plain, concise, unambiguous language. Use ONLY when the user explicitly invokes /bro or says the previous response did not land.

• browser-access

  Decide whether browser access is needed and keep authorised checks narrow. Use for frontend or UI diagnosis, before proposing or using Playwright, Chrome DevTools or other browser automation, and when the user explicitly requests browser interaction.

• change-review-handoff

  Hand a finished, verified code change to the user as a Plannotator review with a next-steps question. Use before reporting an implementation, fix, refactor or cleanup done.

• changeset-scope

  Keep all scoped code work contained to the user-defined changeset. Use for implementation, fixes, diagnosis, refactoring, cleanup, and review when explicit instructions, named files, diffs, branches, pull requests, or injected work scopes define the boundary.

• check-skill-updates

  Check imported skills for upstream changes and review safe updates. Use when an import's origin in skills.yml may have changed, when a tool a skill depends on has a new release, or when refreshing installed skills from their source repositories.

• chill

  Stop overengineering and reinventing the wheel. Use when the user says a change has become overly complicated, out of scope, or is rebuilding something an existing tool or library already does.

• ci-loop

  Run a watch, triage, fix and push loop on a directly pushed branch, such as the default branch, until every GitHub Actions run on its latest commit passes. Use as an OpenCode `/goal` objective (`/goal @ci-loop`) or when asked to keep fixing CI on a branch pushed without a pull request.

• cleanup-unnecessary-variables

  Safe removal of unnecessary variables during code review and refactoring. Use when simplifying code, inlining temporary or single-use variables, or removing redundant aliases, while preserving runtime behaviour, evaluation order, and variables kept for readability or debugging.

• code-review

  Review a pull request, branch, work-in-progress changes, or diff for concrete defects, unmet requirements, and repository convention violations. Keep findings scoped, evidenced, and proportionate.

• decision-models

  Make typed, calibrated decisions about text, JSON or images with decision models, locally through Ollaya or Ollama or hosted as Cloudflare Clef on Workers AI: classify (choice), rate (score) or check a yes/no statement (noul), with probabilities you can threshold. Use it to triage tickets and emails

• diagnose

  Investigate bugs using source, observed failures, and proportionate verification. Use for regressions, intermittent failures, incorrect behaviour, or performance problems whose cause needs investigation.

• effect-principles

  Apply the Effect way of reasoning in codebases that do not use Effect, in any programming language. Use when editing or reviewing non-Effect code so dependencies, failures, state, boundaries, resources, time, and workflows stay explicit without adding Effect-shaped architecture or broader scope.

• evidence-first

  Check uncertain claims against their source before answering, while following the user's firm choices and limits. Use when the user is tentative or possibly wrong, when giving advice, or when they set a firm preference or scope limit. Load once per conversation.

• git-context

  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.

• github-development-rulesets

  Create GitHub Development rulesets from the bundled JSON baseline, compare and migrate existing rulesets, or update required CI checks. Use when setting up a Development ruleset, choosing among existing rulesets, or reconciling their policy and emitted check names.

• github-repository-setup

  Create or induct GitHub repositories with the preferred settings, licence, watching, CI and a Development ruleset. Use for gh repo create, dot repo induct, repository defaults or first-push setup.

• grilling

  Grill the user about a plan, decision, or idea in dependency-ready rounds. Use when the user wants to stress-test their thinking or uses a grill trigger phrase.

• handoff

  Save concise continuation context when work moves to another session or the user requests a handoff.

• herdr-workflows

  Local safeguards for Herdr linked worktrees and session recovery. Use alongside the herdr skill when creating or cleaning up a Herdr worktree, moving its changes back to the host checkout, diagnosing socket routing, or recovering the default session.

• home-assistant-frontend

  Home Assistant frontend skill routing and personal engineering overlays. Use only when editing or reviewing code inside a Home Assistant frontend (home-assistant/frontend) checkout or a Home Assistant custom card or dashboard repository, so the frontend's `ha-frontend-*` skills stay authoritative an

• home-assistant-lit-rendering

  Home Assistant Lit rendering extensions for HA components and context-aware picker callback shape. Use with lit-rendering only when editing or reviewing Lit render logic inside a Home Assistant frontend (home-assistant/frontend) checkout or a Home Assistant custom card or dashboard repository.

• human-step-guide

  Prepare a concise guide when progress is blocked by a genuinely human-only action. Use for approvals, physical actions, credential entry, or dashboard steps the agent cannot perform; do not use for work available tools can complete.

• import-external-skill

  Import skills from external repositories into this Agent Skills repository. Use when pulling in a public skill, reviewing an external skill set, or adapting upstream content into an existing skill.

• inbox-reporting

  Keep the user in the loop through the Plannotator Inbox during long autonomous work, with a status update for every step, directions as gated Plannotator reviews and questions as Inbox questions, so they can follow and steer without the terminal. Use ONLY as an explicitly invoked OpenCode `/goal` ob

• issue-loop

  Work through a GitHub issue and every issue related to it until they are done, committing each change and pushing at each working point, with the issue tracker, any project board and the Plannotator Inbox checklist kept current and the user's steering folded in as it arrives. Use ONLY as an explicit

• lit-rendering

  Lit rendering and picker callback-shape guidance. Use when editing or reviewing Lit component render logic, derived render data, memoization, or picker callbacks.

• maintain-docs

  Bring docstrings, comments, docs sites and external docs repositories up to date with recent code changes. Use when asked to update, check or catch up documentation.

• npm-jsr-first-publish

  Prepare a brand-new npm and JSR package for its first release from GitHub Actions. The bundled script publishes an npm 0.0.0 placeholder, adds the npm trusted publisher, and creates and links the JSR package. Use before a new package's first release, or when its release fails because the npm package

• opencode-effect

  Develop and migrate OpenCode V2 plugins, clients, SDK hosts, and HTTP API integrations. Use for the OpenCode plugin API, `@opencode/client`, `@opencode/sdk`, server API, Effect entrypoints, or V1-to-V2 API migration.

• pitchfork-dev-servers

  Start, stop, check and tail local dev servers through the project's workflow, pitchfork or a framework background mode, and set up `pitchfork.toml` with stable .localhost addresses. Use for dev or background servers, pitchfork tasks, port clashes or unresolved proxy URLs.

• pkexec-root

  Use pkexec first for commands that need root directly or indirectly.

• plan

  Produce implementation-ready plans from the current conversation and repository context. Use when entering native plan mode, invoking /plan, or when a task needs concrete implementation sequencing before edits begin; do not use for round-based grilling.

• release-oxlint-rules

  Create and publish a major, minor, or patch release of @timmo001/oxlint-rules. Use when asked to create, cut, prepare, or publish an oxlint-rules release, including its version bump and npm and JSR publication.

• remote-change-diff

  Show a proposed change to a live system outside Git as a diff for approval before applying it, then snapshot, apply, read back and keep a rollback record. Use before every write to an external server, service or device, such as Home Assistant automations, scripts, helpers, entity or device settings

• remove-single-use-functions

  Safe inlining and removal of single-use functions during code review and refactoring. Use when a local, non-exported helper has exactly one real call site and inlining preserves behaviour and readability.

• research

  Investigate a topic against primary sources and return cited findings. Use when the user asks why, wants evidence or validation, needs docs, API, spec or library behaviour verified, or compares competing views.

• retro

  Run a retrospective on one or more agent sessions and propose improvements to the agent's environment, including skills, steering files, automated checks, and tooling. Use ONLY when the user invokes /retro or explicitly asks for a retrospective or a review of past sessions.

• review-stages

  Review mode for long autonomous work where each stage gets a gated Plannotator code review before it is pushed, with feedback fixed and re-reviewed while independent work carries on. Use ONLY as an explicitly invoked OpenCode `/goal` objective alongside a loop skill, such as `/goal @issue-loop @inbo

• review-steering

  Review mode for long autonomous work whose design is already settled, with no review requests, sign-offs or design questions. Changes are pushed as they reach a working point, decisions are made from the given design and reported, and the user steers only when they choose to. Use ONLY as an explicit

• safe-process-signals

  Safe process killing and signal handling for agent/subprocess contexts. Use when running pkill, killall, kill, or any process termination command from a shell subprocess, automated script, or coding agent.

• session-coordination

  Split independent work into visible Herdr sessions and choose models and effort variants for each assignment. Use when tasks benefit from parallel workers or different model capabilities, when the user requests coordination or model selection, or when a coordinator agent is selected. Ask before laun

• shared-workflows

  Use, configure, maintain, or create reusable GitHub Actions workflows for personal and organisation repositories. Use when a task mentions shared workflows, reusable workflows, `workflow_call`, cross-repository workflow `uses:`, or the personal workflows repository; do not use for repository-specifi

• show-me

  Help the user understand the current topic visually with concise diagrams, code-shape sketches, and focused HTML artifacts. Use ONLY when the user explicitly asks to see, visualise, diagram, sketch, or be shown the preceding explanation.

• skill-prefixes

  Name skills with an owner prefix so they do not collide with shared, imported or other repositories' skills. Use when creating, renaming, importing or reviewing a skill name, especially for repository-local or tool-owned skills.

• staged-implementation

  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 cha

• task-focus

  Keep the original task on track when the user raises a side thought, side question, tentative branch idea, or explicit change of task. Use before diverting work, switching branches, or choosing between a BTW session, a fresh session, and the current conversation, especially with a large context wind

• task-runners

  Run only the checks a change needs, in parallel, and write task config that skips up-to-date work. Use when running lints, type checks, tests or builds, editing task runner config or CI steps, or when a run is slow.

• testing

  Choose tests for their concrete regression value, avoid low-value coverage, and verify changes by exercising the real built behaviour. Use during implementation, fixes, planning, diagnosis, and code review when choosing verification, adding or changing tests, considering a missing-test finding, or w

• to-questionnaire

  Turn a decision the user cannot answer alone into a channel-aware questionnaire draft for one other person. Use when missing knowledge belongs to a colleague, maintainer, or domain expert and the user needs questions for GitHub, Slack, Discord, or a document.

• types-enforce-ts

  TypeScript type-safety guidance. Use when editing or reviewing `.ts`, `.tsx`, `.mts`, or `.cts` files.

• wrangler

  Use the project's Wrangler CLI for Cloudflare development, configuration, and deployment in projects with a wrangler.jsonc, wrangler.json, or wrangler.toml file. Load before running Wrangler or changing its configuration; retrieve exact flags and binding shapes from current docs and installed schema

• writing-dot-skills

  Craft for authoring Agent Skills that select reliably and stay lean. Use when creating or revising a skill's description, workflow, references, scripts, or structure.

• writing-style

  Write commits, PR and issue text, docs, code comments and user-facing strings in the owner's concise, human UK English voice. Use when writing, editing or reviewing these, drafting or creating issues, making text sound natural, or attaching images or videos to a PR, issue or discussion.