Read-only error and consistency check of this skills repository. Use PROACTIVELY when the user asks to "check the repo", validate skills, verify SKILL.md files against the official Agent Skills format, hunt for manifest/catalogue/plugin drift or broken symlinks, or wants a pre-commit sanity pass after adding or…
Routes work on trained-model systems to the right sub-skill: LLM apps (prompting, RAG/retrieval, agents and tool use, evals and LLM judges, guardrails, fine-tuning) or classical ML projects (framing, baselines, model choice, missing data, deployment, retraining).
Guides choosing a repository's architecture — topology (monolith, modular monolith, microservices, serverless) or code organization (layered, by-domain, hexagonal, clean/onion). Use when picking or restructuring either, not for generic project setup.
Routes software-architecture work to the right sub-skill: choosing topology or code organization (monolith vs microservices, layered/hexagonal/clean), service boundaries and inter-service communication, DDD modeling, component decomposition, C4 diagrams, coupling/cohesion analysis, and CI architecture rules.
Drafts a C4 model of a software system with the user and renders it as Mermaid at Context, Container, Component, Landscape, Dynamic, and Deployment level (not Code). Use when asked to draw or document a system as C4 diagrams.
Analyzes or rewrites a message, feedback, or conversation with Schulz von Thun's four-sides model and Rogers-style active listening. Use for feedback rewrites or message diagnosis; educational, not therapy.
Assesses existing code for module cohesion and LCOM, codebase-wide coupling metrics and zones, or the balance of one dependency (Khononov). Use when measuring cohesion, coupling, or dependency balance.
Applies Domain-Driven Design: subdomain classification, context mapping, legacy integration (ACL), tactical pattern choice, and conventions for aggregates, value objects, events, and event sourcing. Use for DDD design or review.
Guides writing or revising technical docs for a named reader — README, tutorial, how-to, API reference, docstrings, runbook, package docs, or vignettes. Use when drafting or updating documentation for a specific audience.
Designs and implements architecture fitness functions — automated CI checks that fail the build when a characteristic such as modularity, layering, coupling, security, or resilience erodes. Use when making CI enforce architecture rules.
Produces a self-contained HTML file for deliverables the reader will keep, share, or manipulate; not for ordinary answers. Use when spatial layout, comparison, or interaction carries meaning.
Guides experienced trainees in hypertrophy programming, auto-regulation, and plateau diagnosis. Use when setting training volume or effort, adjusting a stalled lift, managing injury risk, or returning after injury.
Engineers LLM applications: fixing bad output (prompting, RAG, finetuning), evals and LLM judges, agents and tools, guardrails, and production monitoring. Use when building or debugging an app on top of an LLM.
Decomposes a NEW system or feature into named logical components; not for measuring an existing decomposition. Use when asking what components a new system needs.
Guides microservice interaction design and review — boundaries, coupling, communication style, contract versioning, sagas, and resiliency patterns from Newman's Building Microservices. Use when designing or reviewing how services communicate.
Guides a classical ML project — framing, baselines, model choice, missing data, deployment, retraining. Use when training a model on your own data, not when building an LLM app.
Plans one multi-step project with GTD's Natural Planning Model (purpose, outcome, brainstorm, organize, next actions). Use when a project feels stuck, vague, or overwhelming; not for inbox triage or picking today's task.
Structures explanations of tools, methods, concepts, rules, and proposals by leading with the concrete problem. Use when explaining a solution; not for whole-document structure (use documentation).
Finds where refactoring is worth starting in an unfamiliar codebase by ranking files by git churn (hotspots) and explaining the ranking. Use when deciding which code to refactor first or where to start cleaning up a legacy repository.
Generate a standup / status update from recent development activity — yesterday/today/blockers, turning rough notes or connected-tool activity into a shareable update.
Drafts a weekly update, executive summary, escalation, or launch announcement for readers outside the working group. Use when preparing status or launch communication for leadership, partners, or customers.
Scout one third-party open-source repository for open issues that suit a small, clean contribution, and write repro, root-cause analysis, fix diff, test, and a submit checklist to a local folder only.
★not rated 2
changed 4d agoC47 tokens
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: