lx-wnk
UserPortable Agent Skills for AI coding agents (Claude Code, Codex, Cursor, Gemini) — agentskills.io-conformant, versioned, installable via skills.sh
Categories
Indexed Skills (15)
agent-context-init
Initialize Agent-Context in the current project — sets up the layered context architecture with shared infrastructure, project-specific layers, memory stubs, and skill registry. Use this skill whenever the user asks to initialize Agent-Context, set up Agent-Context, bootstrap Agent-Context, or says things like "init agent-context", "set up context layers", "add agent-context to this project". Also use when the user wants to start using Agent-Context in a new or existing project.
agent-context-update
Update Agent-Context to the latest version — refreshes shared infrastructure files while preserving all project-specific configuration, memory, and skills. Use this skill whenever the user asks to update Agent-Context, upgrade Agent-Context, sync Agent-Context, or says things like "update agent-context", "get latest agent-context", "refresh context files", "sync agent infrastructure". Also use when the user wants to check if a newer Agent-Context version is available.
architecture-design
Design system-level architecture — bounded contexts, modules, domains, layering, dependency direction, and ADRs. Make sure to use this skill whenever the user asks to design an architecture, plan a system, define bounded contexts, draft an ADR, decide on module boundaries, or says things like "entwirf die Architektur", "plane das System", "wie strukturieren wir X", "architecture design", "system design", "bounded contexts", "module layout". Use this skill for HIGH-LEVEL structural decisions only — component and class-level design belongs in `component-design`.
architecture-review
Review system-level architecture of a PR, branch, namespace, or whole project — boundary violations, dependency cycles, layer breaches, ADR compliance, cohesion of modules and bounded contexts. Make sure to use this skill whenever the user asks to review the architecture, audit module boundaries, check for circular dependencies, verify domain structure, or says things like "architektur-review", "prüfe die struktur", "check architecture", "review namespace", "audit boundaries", "are our modules clean". Use this skill for HIGH-LEVEL structural review only — SOLID, class design, and method-level issues belong in `component-review`.
atom-operating-model
Default operating model for non-trivial work: act as a coordinating PM that fans out a team of isolated, communicating worker agents, with parallel work in separate git worktrees. Trigger on "arbeite im Team", "parallel bearbeiten", "koordiniere Agenten", "mehrere Tasks gleichzeitig", "spawn a team", "fan out", "work on these in parallel", "PM mode", "split this across agents". Defines worktree topology rules, the main-thread-PM mesh, peer-to-peer comms governance, and an execution-context boundary (full background mesh only in interactive sessions; headless/spawned agents use the synchronous subset only). NOT for trivial single-step tasks — those stay with the coordinator. For single-feature delivery detail use the project's OFD harness; this is the layer above that distributes streams.
branch-review
Multi-agent code review EXCLUSIVELY of the diff between the current branch and a base branch (default main) — not a whole-repo audit, only diff-touched areas. Spawns parallel subagents for code quality, architecture, security (OWASP/CWE/CVSS), SEO, privacy/legal, UI/UX (WCAG), and performance, consolidated into a P0–P4 Findings.md. Optional `--apply-fixes` applies clear fixes and a `/simplify` pass behind a test/lint gate (`--no-simplify` opts out), and escalates design decisions. Use for "review this branch", "PR review", "diff review", "branch review", "review my PR", "review what changed", or German "review meinen branch", "review die änderungen", "schau dir den branch an", "PR-Review" — whenever a PR link, branch range, or diff is posted, even without the word "review" if context is clear. DO NOT trigger for a whole-project audit without branch context — use full-project-review. DO NOT trigger for several or all open PRs ("review my PRs", "fix PR issues", "alle PRs prüfen") — use review-and-fix.
component-design
Design low-level component and class structure — classes, interfaces, design patterns, method signatures, aggregates, service contracts, and collaboration within a single module or bounded context. Make sure to use this skill whenever the user asks to design classes, pick a design pattern, define interfaces, model an aggregate, shape a service, or says things like "wie strukturiere ich die klassen", "welches pattern passt", "component design", "class design", "design the service", "model the aggregate". Use this skill for DETAIL DESIGN inside a known module — system-level structure belongs in `architecture-design`.
component-review
Review low-level component and class design — SOLID, cohesion, pattern correctness, interface design, method contracts, aggregate integrity, and domain-model health inside a PR, branch, namespace, or module. Make sure to use this skill whenever the user asks to review class design, check SOLID, audit a component, check if a pattern is used correctly, or says things like "component review", "class review", "prüfe das klassen design", "are these classes clean", "review the service", "solid check". Use this skill for DETAIL REVIEW only — module boundaries and dependency structure belong in `architecture-review`.
full-project-review
Comprehensive multi-agent audit of the ENTIRE project (all repos / full HEAD state). Spawns parallel subagents for code quality, architecture, security (OWASP/CWE/CVSS), SEO, privacy/legal, UI/UX (WCAG), and performance, and consolidates their reports into a complete Findings.md with P0–P4 prioritization and reasoned recommendations. Use this skill for "review the entire project", "full project audit", "audit the codebase", "comprehensive review", "code audit", "security audit", "compliance audit", "review everything", "DSGVO audit", "OWASP audit", or German equivalents "vollumfängliches review", "review das ganze projekt", "audit das projekt", "kompletter code-audit", whenever a systematic audit without branch/diff context is requested — even when no changes are pending, no PR exists, or the branch is empty. PR/diff status is NOT a blocker. DO NOT trigger when only branch changes should be reviewed — use branch-review for that.
obsidian
Obsidian vault access via Local REST API using curl — read, search, create, or update notes in the knowledge base. Trigger on ANY of these: user mentions "obsidian", "vault", "knowledge base", "my notes", or "note" in a save/lookup context; user asks to "save", "persist", "document", "note down", or "look up" information; phrases like "note this down", "add this to my knowledge base", "search my notes", "check if I have notes on X", "create a note"; CLAUDE.md says to search or store in Obsidian before/after tasks — do it proactively; starting a task where prior context might exist → search first; mid-task discovery of a non-obvious insight, gotcha, root cause, or workaround → save it; finishing a task with decisions or learnings worth remembering → persist it; something written to CLAUDE.md or project docs → also save it for cross-project search.
oss-readiness
Audits a repository for public-release ("open source") readiness: README front-door quality (Why/How/Benefits, badges, quick example, section order), doc deduplication, community-health files (LICENSE, CONTRIBUTING, SECURITY, CODE_OF_CONDUCT, issue/PR templates), and repo signals (description, topics, CI badge, releases, .gitignore, secrets). Fans out 4 parallel dimension agents into outputs/OSS-Readiness.md, P0-P3 findings. --apply-fixes drafts missing community-health files tailored to the repo, adds a CI badge, reorders README, dedups docs — escalates subjective calls (tagline, license choice, prose voice) as TODOs, never guesses. Use for "oss readiness", "prep for public release", "audit my repo for open source", "make this repo public-ready", "readme tuning", "make it presentable", or German "fit für open source", "repo veröffentlichen", "readme aufhübschen", "public-ready machen", "oss-check". Does NOT review source-code quality/security — use /branch-review or /full-project-review.
reproduce-first-debug
Debug a defect under a hard reproduce-first gate — no hypothesis, code reading, or fix before a reproduction artifact fails. The reproduction is promoted to a permanent regression test, committed RED before the fix, then logged to a bug ledger. Uses local fixtures, never real ticket or production data. Use this skill when a defect lacks a confirmed root cause, or the user says "debug this", "fix this bug", "why is X broken", "this is failing", "the test is red", "investigate this error", "find the root cause", "debugge das", "warum geht das nicht", "das funktioniert nicht", "finde den Fehler", "such den Bug", "der Test ist rot", "Fehler analysieren". Also trigger when a stack trace, failing test output, or error log is pasted without a question. DO NOT trigger for a known cause where only the fix is wanted, for adding tests to working code, or for reviewing a diff — use `branch-review` for that. NOT for general debugging without the RED-repro-and-ledger gate — see `superpowers:systematic-debugging`.
review-and-fix
Review MULTIPLE open pull requests in one pass — discovers the open PRs (or the ones you name), runs `/branch-review` per PR in an isolated git worktree, and archives every report to `outputs/reviews/YYYYMMDD-<branch>.md` with a fixed/not-fixed flag plus a roll-up index. Optional `--apply-fixes` is forwarded to each per-PR review; design decisions from all PRs are batched and escalated once at the end. Use for "review my PRs", "check the open PRs", "review all open pull requests", "fix PR issues", "PR fleet review", "audit the open PRs", or German "review meine PRs", "check die offenen PRs", "alle PRs prüfen", "PRs reviewen und fixen", "offene Pull Requests durchgehen". DO NOT trigger for a single diff on the branch you already have checked out — use /branch-review. DO NOT trigger for a whole-repo audit without PR context — use /full-project-review.
session-handoff
Generate a structured handoff document at the end of a work session — what was implemented, which decisions were made and why, open questions, and recommended next steps. The document is written to `outputs/handoffs/latest.md`, and the previous handoff is rotated to a dated, topic-named archive (repo convention, cf. `branch-review`). Use this skill whenever the user wants to end a session, create a handoff, or says: "session-handoff", "wrap up", "end of session", "session summary", "hand over to next session", "Handoff erstellen", "Session abschließen", "was haben wir heute gemacht", "Zusammenfassung der Session", "nächste Schritte dokumentieren", "übergib an nächste Session".
tech-gazette
Generate a Tech Gazette as a self-contained HTML file covering 18+ topic areas relevant to Software Architects and Lead Developers working in Shopware/E-Commerce agencies. Supports daily and weekly editions. Use this skill whenever the user asks to create a tech gazette, generate a tech briefing, write a tech newspaper, or says things like "tech gazette", "Gazette erstellen", "daily tech news", "weekly tech news", "Tech-Briefing", "tägliche Gazette", "wöchentliche Gazette".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.