todomcp

An ambient lens that tilts technology choices toward the newest viable option so the work keeps up with the ever-changing times without leaving the known good route. It biases the default toward the latest stable release (including just-released majors), newly-stable language and platform features, modern tooling, and current AI models/capabilities, and allows pre-release channels (beta/RC/canary, and nightly only with a documented reason) when a concrete need justifies the climb. It sits beneath software-engineering-excellence: maintainability stays the tiebreaker, every adoption is verified live, pinned, reversible, free of known blockers, and green on the full validation gate, and decided choices and AGENTS.md Hard Constraints are never silently swapped. Use when selecting a dependency, framework, runtime, language feature, tool, or AI model; when picking or upgrading a version; or whenever deciding how current a technology choice should be.

Creates a well-structured GitHub issue from a tagline or short description in any repository, investigating for duplicates, reading VISION.md when present, and invoking the grill skill (grill-with-docs / grill-me) as a mandatory gate before drafting, using the project's issue template and label conventions, and capturing UI/UX context (screenshots, design references, accessibility, responsive, theme) when the change is user-facing. Use when the user runs /create-issue or asks to file a GitHub issue.

Runs a documentation-backed decision loop before implementation planning or issue drafting, using current source, docs, and ADR evidence to ask one sharp question at a time, record resolved terms in CONTEXT.md when present, and create ADRs only for hard-to-reverse decisions with real trade-offs. Use when the user invokes /grill-with-docs or when another workflow requires the grill gate before implementation planning or issue creation.

Turns a raw idea or feature request (no GitHub issue) into a confirmed mini-spec by asking follow-up questions about scope, desired outcome, and success criteria, then implements it with the same rigor as /implement-issue: reads AGENTS.md/area context, VISION.md when present, and applicable stack/conventions skills, runs a full-context investigation, invokes the grill skill when registered, presents exactly three options, and stops for the user's choice before coding unless automatic mode was requested, updates the branch against origin's default branch, implements the chosen option, searches project context for DEFINITION_OF_READY.md before implementation, runs verification (UI/UX checks plus the project's full check gate), reviews against the spec's success criteria and project-context DEFINITION_OF_DONE.md before handoff, runs a /review code review, and always hands off via /create-pr. Use when the user runs /implement-idea or wants to build something that is not an existing issue.

Validates a GitHub issue against the current codebase, reading the nearest AGENTS.md/CLAUDE.md, VISION.md when present, area context, and any applicable stack/conventions skills first. Runs a full-context investigation (real project commands, whole code path, no shortcuts), handles already-fixed issues by closing or adding regression tests, invokes the grill skill when registered, then presents implementation options and stops for the user's choice before coding unless automatic mode was requested. Updates the branch against origin's default branch, implements the chosen option, searches project context for DEFINITION_OF_READY.md before implementation, runs verification (UI/UX checks plus the project's full check gate), reviews against the issue's acceptance criteria and project-context DEFINITION_OF_DONE.md before handoff, runs a /review code review, and always hands off via /create-pr. Use when the user runs /implement-issue with an issue number.

Language-agnostic repo structure conventions used across the user's projects in any language — the user-facing README.md structure (name, logo, description, install, usage, optional background, contribution, references), the docs/ template (application, architecture, code-style, quick-start, tooling, deployment), the AGENTS.md template with a Hard Constraints section (symlinked to CLAUDE.md), nested area AGENTS.md for multi-area repos, optional CONTRIBUTING.md, the canonical VISION.md, DEFINITION_OF_READY.md, and DEFINITION_OF_DONE.md governance files, the pre-commit hook contract with Lefthook as the default and explicit alternatives, scripts directory in the project's own language, co-located tests, the .agents/skills folder symlinked to .claude/skills, and changelog generation with git-cliff. Stack-specific tools (test runners, linters, generators) live in the matching stack skill. Use when scaffolding or restructuring any repo, writing AGENTS.md or docs, or laying out folders.

Ambient engineering-quality skill that MUST be selected for any code edit, implementation, debugging pass, review fix, refactor, architecture change, test-harness change, or substantial technical investigation in any stack. Use this before acting on engineering work, especially after user correction or when scope, tooling, validation, or architecture might drift. Defines the standard for good and excellent engineering work, sitting above execution/workflow skills: grounding in reality, full-scope completeness, reuse over duplication, real validation, right-sized value, and maintainability as the governor. It prevents the agent from improvising its own definition of good, quietly narrowing scope, shipping only the happy path, duplicating code that already exists, swapping a decided approach, over-correcting after feedback, or claiming work is done without verifying it. Apply it even when no instruction asks for "quality" or "best practices" — it is the default standard for engineering work, not an add-on.