Browse skills

Use when reverse engineering binaries, firmware, mobile apps, JavaScript/Electron apps, .NET assemblies, network protocols, or malware samples; when decompiling, deobfuscating, unpacking, debugging, or hooking shipped artifacts; when solving CTF challenges (pwn, crypto, forensics, web); when a conclusion needs evidence from a shipped artifact rather than available source; or when routing authorized pentest and security-analysis work. Do not use for ordinary review of source code you already have.

The English summary is being prepared. Showing the original description.

Use when starting a new .NET/Blazor/Angular MVP project in an empty repository.

The English summary is being prepared. Showing the original description.

Use when working with Obsidian vaults, notes, tasks, properties, bases, plugins, or themes.

The English summary is being prepared. Showing the original description.

Use when generating or updating a project README.md or CHANGELOG.md.

The English summary is being prepared. Showing the original description.

Use when raising code quality or test coverage across a .NET, Java, or Python repository.

The English summary is being prepared. Showing the original description.

Use when the user needs to create or refine a feature SPEC SDD before implementation.

The English summary is being prepared. Showing the original description.

Single owner of everything under docs/architecture/ — ADRs, architecture and design documents, and architecture diagrams. Routes each deliverable to the right engine: /mermaid-architecture for Markdown-native diagrams, /drawio-architecture for editable .drawio diagrams, and the optional archify skill for interactive standalone HTML diagrams (used only when already installed in the environment; never installed at runtime). Use whenever architecture documentation, ADRs, or architecture diagrams must be created or updated.

The English summary is being prepared. Showing the original description.

Use when building a new MCP server in TypeScript, Python, or C# that exposes tools to LLMs.

The English summary is being prepared. Showing the original description.

Use when initializing or migrating an AI agent harness in a repository.

The English summary is being prepared. Showing the original description.

Use when turning approved plans, specs, PRDs, or Epics into trackable GitHub Issues.

The English summary is being prepared. Showing the original description.

Use when designing, redesigning, or improving a frontend interface in Angular, React, or Blazor. Use for landing pages, dashboards, components, forms, and responsive layouts that must work mobile-first and then scale to desktop.

The English summary is being prepared. Showing the original description.

Use when the user reports a hard bug, unexpected failure, or performance regression that needs root-cause analysis.

The English summary is being prepared. Showing the original description.

Use when generating or editing draw.io/diagrams.net architecture diagrams via MCP or native XML.

The English summary is being prepared. Showing the original description.

Use when the user wants to improve architecture, consolidate tightly-coupled modules, or make a codebase more testable.

The English summary is being prepared. Showing the original description.

Use when planning the migration of a legacy system or monolith — analyzes the source codebase (current repo, or a repo URL cloned to a temp dir) and produces an evidence-based Strangler Fig migration plan with per-domain SPECs. Default target is .NET (Blazor WebAssembly, .NET MAUI, ASP.NET Core); other stacks allowed by user decision. Do NOT use to implement code or when approved SPECs already cover the migration.

The English summary is being prepared. Showing the original description.

Use when adding logging, metrics, tracing, or alerting to production code, or when a past incident lacks diagnostic data.

The English summary is being prepared. Showing the original description.

Use when analyzing SonarQube issues and turning them into SPEC SDDs and tracked GitHub Issues for TDD implementation.

The English summary is being prepared. Showing the original description.

Use when auditing UI code for interface-guideline compliance (accessibility, forms, animation, images, performance, UX copy) and/or validating a deployed page against Lighthouse 95+ targets. Produces evidence-based findings (file:line + Lighthouse JSON) and turns confirmed pendencies into Draft SPECs via write-specs. Do NOT use to design/build UI from scratch (use design) or to fix findings inline — fixes go through the SPEC pipeline.

The English summary is being prepared. Showing the original description.

Use when exposing a WordPress site to AI agents via MCP, or when WordPress MCP setup fails.

The English summary is being prepared. Showing the original description.

Use when the user wants to configure, authenticate, or use Google NotebookLM via the nlm CLI or MCP.

The English summary is being prepared. Showing the original description.

Use when the user asks to connect an AI agent to external apps via Composio, or when Composio CLI or MCP setup fails.

The English summary is being prepared. Showing the original description.

Use when reviewing code before it merges, whether written by an agent or a human.

The English summary is being prepared. Showing the original description.

Use when the user asks to implement an approved SPEC SDD using test-driven development.

The English summary is being prepared. Showing the original description.

Use when auditing a repository for evidence-backed gaps between code, SPECs, architecture, and documentation — before a release, after a review, or when the user asks what is missing or divergent. Confirmed gaps become Draft SPECs via write-specs, a tracked GitHub Epic via create-issues, and orchestrated execution via orchestrator, with an explicit approval gate before any external action.

The English summary is being prepared. Showing the original description.