@athola

Authentication patterns for external services: API keys, OAuth, token management, verification. authentication, API keys, OAuth, token management, credentials.

Multi-LLM deliberation for strategic decisions via expert pressure-testing and consensus building. Use for critical, irreversible, or high-stakes architecture choices and conflicts. Skip for trivial or reversible decisions.

Generate or remediate documentation with human-quality writing and style adherence. Use when creating new documentation, rewriting AI-generated content, or applying style profiles. Do not use for slop detection only (use slop-detector) or learning styles (use style-learner).

Evaluate and improve Claude skill quality through auditing. Use when reviewing skill quality, preparing skills for production, or auditing existing skills. Do not use when creating new skills (use modular-skills) or writing prose (use writing-clearly-and-concisely). Use this skill before shipping any skill to production.

Record browser sessions using Playwright for web UI tutorials, converts video to GIF.

Combine media assets (GIFs, videos) into composite tutorials with vertical/horizontal layouts.

Asynchronous event-based communication to decouple producers/consumers for scalability and resilience. Triggers: event-driven, message queue, pub/sub, asynchronous, decoupling Use when: real-time workloads or multiple subsystems react to same events DO NOT use when: selecting paradigms (use architecture-paradigms first), simple request-response.

Coarse-grained service architecture for deployment independence without microservices complexity. service-based, SOA, coarse-grained services, domain services Use when: teams need deployment independence without microservices complexity DO NOT use when: fine-grained scaling needed - use microservices.

Consult this skill when designing client-server systems or API architectures. Use when traditional web/mobile applications with centralized services, clear separation between client and server responsibilities needed. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: peer-to-peer dominates - consider dedicated P2P patterns.

Functional Core, Imperative Shell: isolate deterministic logic from side effects for testability. Triggers: functional-core, imperative-shell, pure functions, side-effects, testability Use when: business logic is entangled with I/O or tests are brittle DO NOT use when: simple scripting without complex logic, or performance-critical hot paths where immutability overhead matters.

Single deployable with enforced module boundaries for team autonomy without distributed complexity. Triggers: modular-monolith, module boundaries, single deployment, team autonomy Use when: teams need autonomy without distributed overhead DO NOT use when: already using microservices or system is small.

Guide to effective Claude Code skill authoring using TDD methodology and persuasion principles. Use when creating new skills, improving compliance, or validating quality before deployment. Do not use for evaluating existing skills (use skills-eval) or analyzing architecture (use modular-skills). Follow the Iron Law: write a failing test before writing any skill.

TDD-style testing methodology for skills using fresh subagent instances to prevent priming bias and validate skill effectiveness. Use when validating skill improvements, testing skill effectiveness, preventing priming bias, measuring skill impact on behavior. Do not use when implementing skills (use skill-authoring instead), creating hooks (use hook-authoring instead).

Quota tracking, threshold monitoring, and graceful degradation for rate-limited API services. quota, rate limiting, usage limits, thresholds.

Use this skill at the START of every session. This is MANDATORY for quota management. location: plugin token_budget: 300. Use when session starts (mandatory), prompt sizes spike, tool calls increase, before long-running analyses or massive context loads. Do not use when context-optimization already handles the scenario. DO NOT use when: simple queries with minimal context.

Use this skill BEFORE building complex tool chains. Optimize proactively. location: plugin token_budget: 200. Use when >3 tools chained sequentially, large datasets (>10k rows), large files (>50KB), context usage >25%. Do not use when simple tool calls that do not chain. DO NOT use when: context pressure is low and tools are fast.

Retrospective workflow evaluation and improvement of skills, agents, commands, and hooks. workflow improvement, retrospective, workflow efficiency Use when: workflow felt slow, confusing, or needs optimization DO NOT use when: simple one-off fixes - use fix-pr or do-issue instead.

Use this skill BEFORE resource-intensive operations. Establish baselines proactively. location: plugin token_budget: 400. Use when session starts (auto-load with token-conservation), planning builds or training that could pin CPUs/GPUs for >1 minute, retrying failed resource-heavy commands. Do not use when simple operations with no resource impact. DO NOT use when: quick single-file operations.

Use this skill to quickly understand "what changed and what matters". Use when resuming work after absence, preparing handoff documentation, reviewing sprint progress, analyzing git history for context. Do not use when doing detailed diff analysis - use diff-analysis instead. DO NOT use when: full code review needed - use review-core instead.

Analyze individual skill complexity and get modularization recommendations. For ecosystem-wide evaluation, use /skills-eval instead.

Harden skills against rationalization and bypass behaviors

Use this skill for PR preparation. Use when preparing PRs for submission, running quality gates, drafting PR descriptions and templates. Do not use when reviewing existing PRs - use pr-review instead. DO NOT use when: just generating commit messages - use commit-messages.

Transform project briefs into testable specifications with acceptance criteria. Use for requirements translation, spec creation, pre-implementation. Skip if spec exists or still exploring.

Uses subagents for parallel execution with code review gates between batches. Use when addressing issues systematically, multiple related issues need fixing, tasks can be parallelized across subagents, quality gates needed between task batches. Do not use when single simple fix - just implement directly. DO NOT use when: issue needs clarification - comment first to clarify scope.

Use this skill at the BEGINNING of any detailed review for consistent structure. Use when starting any detailed review workflow, needing consistent structure for capturing context and findings, ensuring comparable review outputs. Do not use when quick catchup without formal review - use catchup. DO NOT use when: diff-focused analysis - use diff-analysis.

Use this skill for scope-focused PR reviews. Use when reviewing PRs, validating against requirements, triaging findings to backlog, preventing overengineering. Do not use when preparing PRs - use pr-prep instead. DO NOT use when: deep code review - use pensive:unified-review.

Generate terminal recordings using VHS tape files, produces GIF outputs.

Use this skill for API surface evaluation and design review. Use when reviewing API design, auditing consistency, governing documentation, researching API exemplars. Do not use when architecture review - use architecture-review. DO NOT use when: implementation bugs - use bug-review.

Use this skill for systematic bug hunting with evidence trails. Use when deep bug hunting needed, documenting defects, verifying fixes, systematic debugging required. Do not use when test coverage audit - use test-review instead. DO NOT use when: architecture issues - use architecture-review.

Use this skill BEFORE deploying hooks to production. Use when auditing existing hooks for security vulnerabilities, benchmarking hook performance, implementing hooks using Python SDK, understanding hook callback signatures, validating hooks against compliance standards. Do not use when deciding hook placement - use hook-scope-guide instead. DO NOT use when: writing hook rules from scratch - use hook-authoring instead. DO NOT use when: validating plugin structure - use validate-plugin instead.

Use this skill for general documentation updates with built-in quality gates. Use when updating documentation after code changes, enforcing writing guidelines, maintaining ADRs. Do not use when README-specific updates - use update-readme instead. DO NOT use when: complex multi-file consolidation - use doc-consolidation.

Post-process video files and generate optimized GIFs. Converts webm/mp4 to GIF with configurable quality settings.

Audit shell scripts for correctness, portability, and common pitfalls. Use when reviewing shell scripts, CI scripts, hook scripts, wrapper scripts. Do not use when creating new scripts - use attune:workflow-setup.

Gemini CLI delegation workflow implementing delegation-core for Google's Gemini models. Use when delegation-core selected Gemini, need Gemini's 1M+ token context window, batch processing required. Do not use when deciding which model to use (use delegation-core first), gemini CLI not installed.

Git platform detection and cross-platform command mapping for GitHub, GitLab, and Bitbucket. git platform, forge, github, gitlab, bitbucket, cross-platform Use when: executing forge operations (issues, PRs/MRs, CI, API calls) in any skill or command Do not use directly: consumed by sanctum and other plugins as infrastructure.

Coordinate Claude Code Agent Teams through filesystem-based protocol. Use when orchestrating multiple Claude agents on parallel tasks, need task dependency management, multi-agent code review or implementation. Do not use when single-agent work suffices, task is not parallelizable.

Use this skill for mathematical code verification. Use when reviewing math-heavy code, verifying algorithm correctness, checking numerical stability, aligning with mathematical standards. Do not use when general algorithm review - use architecture-review. DO NOT use when: performance optimization - use parseltongue:python-performance.

Use this skill for systematic change analysis with risk scoring. Use when analyzing specific changesets, assessing risk of changes, preparing release notes, categorizing changes by type and impact. Do not use when quick context catchup - use catchup instead. DO NOT use when: full PR review - use review-core with pensive skills.

Inline reversibility assessment for embedded War Room escalation from commands. Use at decision points to determine escalation need. Skip for standalone strategic decisions.

Learn and extract writing style patterns from exemplar text for consistent application. Use when creating a style guide from existing content, ensuring consistency across documents, learning a specific author's voice, customizing AI output style. Do not use when detecting AI slop - use slop-detector instead. just need to clean up existing content - use doc-generator with --remediate. Use this skill to build style profiles from exemplar text.

Browse the rule catalog and guide installation. Use when looking for ready-made rules, installing standard rules, browsing available categories. Do not use when writing custom rules - use writing-rules skill instead.

Detect and flag AI-generated content markers in documentation and prose. Use when reviewing documentation for AI markers, cleaning up LLM-generated content, or auditing prose quality. Do not use when generating new content (use doc-generator) or learning writing styles (use style-learner).

Configure GitHub Actions CI/CD workflows for automated testing, linting, and deployment. Use for CI/CD setup and quality automation. Skip if CI/CD configured or using different platform.

Provides structural context for downstream review and refactoring workflows. Use when before architecture reviews to understand file organization, exploring unfamiliar codebases to map structure, estimating scope for refactoring or migration. Do not use when general code exploration - use the Explore agent. DO NOT use when: searching for specific patterns - use Grep directly.

Run git-workspace-review first to capture repo context. Use when README requires structural refresh, adding features to documentation, aligning readme with exemplar standards, improving project presentation. Do not use when updating inline docs - use doc-updates. DO NOT use when: consolidating ephemeral reports - use doc-consolidation.

Create markdown-based behavioral rules preventing unwanted actions. create hookify rule, behavioral rule, prevent behavior, block command Use when: preventing dangerous commands, blocking debug commits, enforcing conventions DO NOT use when: hook scope (abstract:hook-scope-guide), SDK hooks (abstract:hook-authoring), evaluating hooks (abstract:hooks-eval).

Create clear, testable specifications with user stories and acceptance criteria. spec writing, feature specification, requirements, user stories Use when: creating new specifications or writing acceptance criteria DO NOT use when: converting specs to tasks - use task-planning.

automatically create GitHub issues for workflow improvements via /fix-workflow. Use when workflows fail, timeout, or show inefficient patterns. Do not use when normal workflow execution, simple command errors.

Configure three-layer pre-commit system with linting, type checking, and testing hooks. Use for quality gate setup and code standards. Skip if pre-commit is optimally configured.

Generate phased, dependency-ordered tasks from specs. Identifies parallelization opportunities. task planning, dependency ordering, phased breakdown, parallel tasks Use when: converting specifications to implementation tasks DO NOT use when: writing specs - use spec-writing. Not for execution - use speckit-implement.

Architect skills as modular blocks to control token usage and complexity. Use when creating skills >150 lines, breaking down monolithic skills, or planning new architecture. Do not use for evaluating existing skills (use skills-eval) or writing human-facing prose (use writing-clearly-and-concisely). Check this skill before starting any new skill development.

Consult this skill when formatting final review deliverables. Use when formatting final review outputs, ensuring consistent deliverable structure, making findings comparable across reviews. Do not use when capturing evidence during analysis - use proof-of-work. DO NOT use when: reviewing changes - use diff-analysis or review-core first.

Transform specifications into implementation plans with architecture design and dependency-ordered tasks. Use for spec-to-plan conversion, task breakdown, effort estimation. Skip if no spec exists.

balancing accuracy with token efficiency.

Use this skill for Makefile audit and optimization. Use when auditing Makefiles, reviewing build system, checking portability, eliminating recipe duplication. Do not use when creating new Makefiles - use abstract:make-dogfood. DO NOT use when: architecture review - use architecture-review.

Use this skill BEFORE writing any hook. Check even if unsure. Use when creating new hooks for tool validation, logging operations for audit, injecting context before prompts, enforcing project-specific workflows, preventing dangerous operations in production. Do not use when logic belongs in core skill - use Skills instead. DO NOT use when: complex multi-step workflows needed - use Agents instead. DO NOT use when: behavior better suited for custom tool.

Detect codebase bloat through progressive analysis: dead code, duplication, complexity, documentation bloat. Use when context usage high, quarterly maintenance, pre-release cleanup, before refactoring. Do not use when active feature development, time-sensitive bugs, codebase < 1000 lines.

Guidance on when to ask clarifying questions vs proceed with standard approaches. Reduces interaction rounds while preventing wrong assumptions.

Prevents sycophantic reasoning through checklist-based analysis, categorical integrity, and evidence-following to uncomfortable conclusions. Red Flags: "I agree that", "You are right", "Great point", "Absolutely", "That is a fair point", "I can see why", agreement without validation, softening conclusions, hedging without evidence, retracting under pressure. Use when analyzing conflicts, evaluating ethical claims, or noticing sycophantic thought patterns. Do not use for routine implementation or simple factual questions. CRITICAL: This skill overrides conversational tendencies toward politeness. Agreement requires validity and accuracy.

Consult this skill when implementing service registry patterns. Use when managing multiple external services, implementing health checks, centralizing service configuration, unified service execution. Do not use when single service integration without registry needs.

Orchestrate tutorial generation from VHS tapes and Playwright specs to dual-tone markdown with GIF recording. tutorial update, gif generation, tape recording, update tutorial, regenerate gifs, tutorial manifest Use when: regenerating tutorial GIFs, updating documentation demos, creating tutorials from tape files DO NOT use when: only updating text - use doc-updates.

Consult this skill when designing storage and documentation systems. Use when organizing knowledge storage, managing configuration lifecycle, creating structured documentation, establishing naming conventions. Do not use when simple storage without lifecycle or structure needs.

Consult this skill when building evaluation or scoring systems. Use when implementing evaluation systems, creating quality gates, designing scoring rubrics, building decision frameworks. Do not use when simple pass/fail without scoring needs.

Use this skill as foundation for git workflows. Use when verifying workspace state before other git operations, checking staged changes, preflight checks before commits or PRs. Do not use when full commit workflow - use commit-messages instead. DO NOT use when: full PR preparation - use pr-prep.

Capture and retrieve PR review knowledge in project memory palaces.

Guide project ideation through Socratic questioning and constraint analysis for actionable project briefs. Use for starting projects, exploring problems, comparing approaches, feasibility. Skip if requirements are clear.

Consult this skill when designing or evolving microservices architectures. Use when teams need high autonomy and independent releases, different capabilities have distinct scaling needs, strong DevOps/SRE maturity exists, polyglot tech stacks needed. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: small team with low organizational complexity. DO NOT use when: lack of DevOps maturity or limited platform engineering resources. DO NOT use when: strong transactional consistency required across operations.

Use this skill BEFORE starting complex tasks. Check context levels proactively. Use when context usage approaches 50% of window, tasks need decomposition, complex multi-step operations planned, context pressure is high. Do not use when simple single-step tasks with low context usage. DO NOT use when: already using mcp-code-execution for tool chains.

hype, and unnecessary framing. Includes termination and directness guidelines.

Workflow orchestrator for Spec Driven Development. Coordinates skills and tracks progress. speckit workflow, spec driven development, speckit commands.

Architecture-aware project initialization combining online research with archetype selection. project initialization, new project, architecture decision, project setup, which architecture, choose architecture, project architecture Use when: initializing a new project and need to select an appropriate architecture based on project type, team size, domain complexity, and current best practices DO NOT use when: architecture is already decided - use project-init instead.

Guidelines from the NASA Power of 10 rules for writing robust, verifiable code. Adapted for general software development with context-appropriate rigor. Use when writing critical code paths, reviewing for robustness, improving code quality. Do not use as rigid requirements for all code - match rigor to consequence.

Process external resources into actionable knowledge with evaluation, storage, and application decisions. knowledge intake, article evaluation, paper review, external resource Use when: user shares links to articles, papers, or external resources DO NOT use when: searching existing knowledge - use knowledge-locator.

NEVER escalate without investigation first. This is the Iron Law. Use when evaluating whether to escalate models, facing genuine complexity requiring deeper reasoning, novel patterns with no existing solutions, high-stakes decisions requiring capability investment. Do not use when thrashing without investigation - investigate root cause first. DO NOT use when: time pressure alone - urgency doesn't change task complexity. DO NOT use when: "just to be safe" - assess actual complexity instead.

Consult this skill for Python performance profiling and optimization. Use when debugging slow code, identifying bottlenecks, optimizing memory, benchmarking performance, production profiling. Do not use when async concurrency - use python-async instead. DO NOT use when: CPU/GPU system monitoring - use conservation:cpu-gpu-performance.

Consult this skill when searching or navigating stored knowledge. Use when searching for stored knowledge, cross-referencing concepts, discovering connections, retrieving from palaces, finding past PR decisions. Do not use when creating new palace structures - use memory-palace-architect. DO NOT use when: processing new external resources - use knowledge-intake.

Provides KISS, YAGNI, and SOLID code quality principles for clean code, reducing complexity, preventing over-engineering, and improving maintainability.

Outputs markdown digests and CSV exports for GitHub issues and PRs. Use when creating status reports, weekly updates, stakeholder briefings, generating GitHub comment digests, tracking initiative health. Do not use when release gates/readiness - use release-health-gates. DO NOT use when: project planning - use spec-kit:speckit-orchestrator.

Interactive selector and router for architecture paradigms. Use when selecting architecture patterns for new systems, comparing paradigm trade-offs, creating architecture decision records, evaluating architecture fit for team size and domain complexity, planning implementation roadmaps. Do not use when implementing a specific known paradigm - use the specific architecture-paradigm-* skill (hexagonal, layered, microservices, etc.) instead. reviewing existing architecture - use architecture-review instead. Use this skill BEFORE making architecture decisions. Check even if unsure about needs.

Cross-plugin testing quality metrics and standards. Referenced by pensive:test-review and parseltongue:python-testing. testing standards, quality metrics, coverage thresholds, anti-patterns Use when: test quality evaluation, coverage thresholds, quality standards DO NOT use when: simple scripts without quality requirements.

Consult this skill for session-scoped temporary knowledge structures. Use when working on complex multi-step projects, preserving context across interruptions, tracking session-specific state. Do not use when permanent knowledge structures needed - use memory-palace-architect. DO NOT use when: searching existing knowledge - use knowledge-locator.

Consult this skill when designing permanent memory palace structures. Use when creating new memory palace structures, organizing complex domains, designing spatial layouts for knowledge retention. Do not use when quick knowledge search - use knowledge-locator instead. DO NOT use when: session-specific context - use session-palace-builder.

Consult this skill when cultivating and maintaining digital gardens. Use when managing note collections, creating link structures, maintaining knowledge bases, tending garden health and growth. Do not use when creating memory palace structures - use memory-palace-architect. DO NOT use when: evaluating new knowledge - use knowledge-intake.

Consult this skill when implementing layered patterns or enforcing layer boundaries. Use when building traditional applications with clear boundaries, working with moderate-sized teams, needing familiar and well-understood patterns, compliance requirements demand clear separation. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: high scalability needs independent component scaling. DO NOT use when: teams need independent deployment cycles - use microservices.

CQRS and Event Sourcing for auditability, read/write separation, and temporal queries. Triggers: CQRS, event-sourcing, audit-trail, temporal queries, distributed-systems Use when: read/write scaling differs or audit trail required DO NOT use when: selecting paradigms (use architecture-paradigms first), simple CRUD without audit needs.

Consult this skill when designing data pipelines or transformation workflows. Use when data flows through fixed sequence of transformations, stages can be independently developed and tested, parallel processing of stages is beneficial. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: data flow is not sequential or predictable. DO NOT use when: complex branching/merging logic dominates.

Decouple domain logic from infrastructure using Hexagonal (Ports & Adapters) pattern. Triggers: hexagonal, ports-adapters, infrastructure-independence, domain-isolation, testability Use when: business logic separation, infrastructure changes needed, testability critical DO NOT use when: selecting paradigms (use architecture-paradigms first), simple CRUD.

Serverless FaaS for event-driven workloads with minimal infrastructure management. serverless, FaaS, Lambda, event-driven, pay-per-use Use when: workloads are event-driven with bursty traffic DO NOT use when: long-running processes or stateful operations required.

Minimal core system with plugin-based feature extensibility for platform development. Triggers: microkernel, plugin-architecture, extensibility, platform-design Use when: platforms/IDEs/marketplaces, core stability critical, plugin isolation needed DO NOT use when: selecting paradigms (use architecture-paradigms first), no extensibility needed.

Data-grid architecture for high-traffic stateful workloads with linear scalability. space-based, data grid, in-memory, linear scaling, high traffic Use when: traffic overwhelms database nodes or linear scalability needed DO NOT use when: data does not fit in memory or simpler caching suffices.

Git best practices for version control and collaboration

Write comprehensive tests following TDD and BDD principles

Systematic debugging approach for identifying and fixing issues

Design RESTful APIs with best practices for consistency and usability

Provides coding assistance with best practices and code review