Claude Skills by yeaight7

Use when creating or modifying dimensional dbt models in warehouse-backed analytics projects. Covers a four-layer warehouse architecture (sources/staging/core/marts), naming conventions, no-alias SQL rule, surrogate-key and missing-record patterns, incremental strategies, deduplication, and common project macros. Use when building fact tables, dimension tables, staging models, writing SQL, or designing tests.

Use when unused functions, classes, exports, or files need to be identified and safely deleted.

Use when package manifests carry unused or redundant third-party dependencies that slow builds, widen the security surface, or complicate updates.

Use when a release spans multiple systems or vendors, order of operations matters with rollback planned up front, or a failed step in one system could corrupt state in a downstream system.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when documentation may have rotted against the code -- files were renamed or moved, scripts or env vars changed, or readers report commands and paths from the docs that no longer work.

Use when reviewing ML training code to confirm a run could be reconstructed later -- hyperparameters, metrics, data references, and artifacts logged, not just printed to stdout.

Use when confronted with an unknown failure in CI or production, before committing to a deep debugging approach.

Use when tests pass and fail intermittently without code changes, or a test passes alone but fails in the full suite.

Address actionable GitHub pull request review feedback. Use when the user wants to inspect unresolved review threads, requested changes, or inline review comments on a PR, then implement selected fixes.

Use when a GitHub PR shows failing checks and a clean failure readout is needed before changing any code.

any input (code, docs, papers, images) → knowledge graph → clustered communities → HTML + JSON + audit report. Use when the user wants to build, inspect, or query a cross-file knowledge graph from code, docs, papers, images, or videos with upstream graphify.

Use when ending a session, handing a task back to the user, or approaching the context limit with work unfinished -- the next session or engineer must be able to resume the work instantly.

Use when a tricky bug, non-obvious workaround, hidden gotcha, or undocumented behavior took real debugging effort to discover and should be captured as a reusable learned skill.

Use when a hook is about to be enabled or modified -- a hook recipe proposed for activation, a pre/post-tool or lifecycle hook added to agent settings, a git pre-commit hook added to a repo, or a third-party hook snippet pasted in from outside.

Use when a bug fix or complex debugging session concludes and a blameless post-mortem summary is needed for human review.

Use when migrating APIs, libraries, or patterns across a large codebase and a single mega-commit would be too risky to review or merge.

Use when debugging complex runtime failures, distributed systems, or issues where a local debugger cannot be attached.

Use when an MCP server is about to be enabled, added to agent config, or upgraded -- a staged server config is a candidate for activation, a third-party server is proposed from a registry, or an existing entry changes transport, credentials, or tool surface.

Design high-quality MCP servers around workflows, narrow schemas, context-aware outputs, and actionable errors. Use when building or reviewing MCP tools for real agent tasks.

Use when a user needs to build or refresh persistent graph memory from a mixed corpus and the right path may include graphify, incremental update, or helper conversion before ingestion.

Use when deciding the lowest-cost context path for a mixed corpus, especially when choosing among direct reading, helper conversion, graph build, graph update, or graph query.

Use when a graph already exists and the user needs retrieval, tracing, explanation, or gap detection from graph memory before reopening the full corpus.

Use when a change may affect metrics, semantic models, dashboards, reporting, or stakeholder-facing KPIs and you need to know whether business meaning or downstream BI assets change.

Use when a bug must be isolated from a large application into a standalone, runnable script or single test case.

Use when reviewing ML preprocessing or feature pipelines for target leakage -- validation metrics look suspiciously good, transformers are fitted before splitting, or features may not exist at prediction time.

Use when writing or reviewing a model evaluation report -- accuracy is being quoted alone, or stakeholders need failure modes, segment performance, and business trade-offs made explicit.

Use when selecting a model for a new task or subagent, deciding whether to escalate after a failed attempt, or designing a multi-agent pipeline with mixed task complexity.

Use when naming conventions or file structure drift across a project and need to be made consistent without changing business logic.

Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when user says "no fluff", "be concise", "use less tokens", or similar.

Use when latency matters and several independent tasks can run at once -- a bounded implementation or investigation that needs waves of concurrent workers, not a persistent completion loop or stage-based orchestration.

Use when a task must run to verified completion rather than best effort -- the user says "don't stop", "must complete", "finish this", or "keep going until done", or the work spans multiple iterations and needs reviewer sign-off before being called done.

Use when a pull request needs one bounded review and CI triage cycle with explicit approval before edits or remote writes.

Use when a release candidate needs final checks before tagging, publishing, or production deployment.

Use when evaluating prompts, LLM outputs, red-team suites, or model behavior with local eval configs and safe provider/cost controls.

Use when a README cannot be followed verbatim -- setup or test commands fail or are vague, environment requirements are unstated, or a new engineer or agent cannot bootstrap the project quickly.

Use when receiving code review feedback, before implementing suggestions — requires technical verification and reasoned pushback, not performative agreement or blind implementation.

Use when creating or reviewing red-team eval plugins, attack templates, grader rubrics, safety fixtures, or model-risk test metadata.

Use when a bug was recently introduced but you don't know which commit caused it.

Use when reviewing or modifying ML training scripts that must produce identical results across runs or machines -- runs with the "same" config differ, or a past result must be reconstructed exactly.

Use when completing tasks, implementing major features, or before merging to verify work meets requirements.

Use when an implementation request is vague or underspecified and needs structured clarification before coding -- the user says "interview me", "ask me everything", "don't assume", or wants to avoid "that's not what I meant" outcomes from autonomous execution.

Use when mining PR review comments and text diffs for reusable writing, documentation, tone, and editorial improvement patterns.

Use when reviewing a PR or your own change plan and you need to decide how much scrutiny it deserves -- the diff touches auth, payments, crypto, migrations, or core shared code, or you are unsure where to focus limited review attention.

Use when code needs restructuring without changing observable behavior.

Use when about to add a new helper, utility, or abstraction, a task sounds like a solved problem, a new external dependency is being considered, or custom code is proposed without checking what already exists.

Use when about to commit, push, or publish -- staged changes touch config or environment files, generated artifacts (relay sessions, logs, build output) are being added, or the session handled credentials even indirectly.

Use when a change touches dbt semantic models, metrics, saved queries, or other semantic-layer YAML -- especially when an existing metric's expression, aggregation, filters, or dimensions are modified.

Create or refactor high-quality skills with lean frontmatter, progressive disclosure, and optional bundled helpers. Use when authoring reusable agent workflows.

Use when designing, running, debugging, or hardening deterministic eval suites for agent skills, prompts, tool workflows, or MCP-backed cases.