MrCipherSmith
UserHelyx — Telegram-first multi-project hub for Claude Code. Multi-session MCP bot with dual-layer memory, voice transcription, web dashboard, and real-time CLI monitoring.
Categories
Indexed Skills (50)
code-verifier
Use when running a full quality gate after implementation — lint, type-check, tests, and import validation. Mandatory step in job-orchestrator after task-implementer and after fix iterations. Use standalone when you need a structured verification report.
context-collector
Use when a job needs a unified context document — gathering docs, libraries, and references for sub-agents before execution.
feature-analyzer
Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch.
flow-orchestrator
Use when Task Manager is enabled and a non-trivial feature, issue, or story should be driven through keryx flow from initialization to a user-selected completion, verified handoff, or open state.
issue-analyzer
Use when decomposing a GitHub issue into atomic tasks for AI implementation, planning task breakdown, or preparing work for task-implementer agents.
job-documenter
Use when a job folder needs to be initialized, or analysis/report/review documents need to be created or updated in jobs/.
job-orchestrator
Use when a GitHub issue or complex intent needs to be analyzed, planned, and implemented end-to-end with sub-agents.
task-implementer
Use when implementing a single decomposed task from issue-analyzer end-to-end, or executing autonomous code changes from a JSON task object.
brainstorm
Use when exploring architecture decisions, tech choices, feature ideas, or any open-ended problem that benefits from multiple perspectives.
docpack-orchestrator
Use when creating or updating a Metaproject requirements package under docs/requirements: PRD, specification, README, policies/protocols/schemas, roadmap updates, verification, and package review. Use for requests like 'create requirements package', 'prepare module documentation', 'write PRD/spec for module', or 'оформи пакет документации'. Not for reverse-engineering current codebase documentation; use autodoc-orchestrator for that.
interview
Use before implementation, design, or migration when requirements are unclear and targeted clarifying questions are needed to gather precise context.
interviewer
Use when requirements are ambiguous and precise clarification is needed before proceeding with a complex task.
prd-creator
Use when a vague or unstructured request needs to be converted into a formal, testable Product Requirements Document.
metaproject-security
Use when working with Metaproject Security: checking prompts, external content, memory/wiki/report writes, PII/secrets redaction, prompt-injection risk, data exfiltration, or security policy reports under .metaproject/security and .metaproject/data/security.
pr-issue-documenter
Use when documenting PR changes, adding a PR description, creating a linked issue for a PR, or updating an existing issue body.
tests-creator
Use when writing test cases BEFORE implementation — converts acceptance criteria into failing test stubs that task-implementer will make pass. Mandatory step in the TDD pipeline between issue-analyzer and task-implementer.
review-architecture
Use when: reviewing code for architectural violations — layer violations, dependency direction mistakes, module boundary coupling, SOLID principle breaches, NestJS module/provider structure, React MVVM boundary violations, or MobX store layer misplacement. Triggered by: "review architecture", "check architecture", "architectural review", or dispatched by review-orchestrator with --architecture or --backend. NOT for: style/naming preferences, logic correctness bugs, or security vulnerabilities.
review-backend
Use when: reviewing NestJS backend changes — API design, service layer, DTO validation, database patterns, and TypeScript correctness. Covers "review backend", "backend review", "review API", "review NestJS", or dispatched by review-orchestrator with --backend flag. NOT for: frontend patterns, MobX, React components, general security vulnerabilities (use review-security-code for XSS/injection/auth-bypass), or performance profiling (use review-performance).
review-clean-code
Use when: reviewing code against Clean Code principles (Uncle Bob) and SOLID at the function/class level — meaningful names, small functions, single level of abstraction, argument count, error handling, DRY, comment quality, and SOLID (SRP, OCP, LSP, ISP, DIP) as applied to individual classes and functions. Triggered by: "review clean code", "check clean code", "Uncle Bob review", "SOLID review", "review --clean-code", or dispatched by review-orchestrator. NOT for: architectural layer violations (review-architecture), naming convention formatting (review-style), logic correctness bugs (review-logic), or security (review-security-code).
review-frontend
Use when a frontend review is requested, checking React component patterns, MobX state management (observer, actions, computed, reactions, lifecycle), View-Store boundaries, and TypeScript safety in changed frontend code. NOT for backend patterns, security vulnerabilities, performance bottlenecks, or cross-layer architecture.
review-highload
Use when: reviewing code that will run under high concurrency or high traffic — race conditions, connection pool exhaustion, cache invalidation, missing indexes, unbounded queues, missing backpressure, retry storms, idempotency gaps, hot-path blocking I/O, and distributed systems anti-patterns. Triggered by: "review highload", "review scalability", "highload review", "review concurrency", "review --highload", or dispatched by review-orchestrator. NOT for: frontend re-render performance (review-performance), general N+1 queries (review-performance), clean code style (review-clean-code), or NestJS module structure (review-architecture).
review-logic
Use when: reviewing code for logic correctness, algorithmic bugs, missing error handling, async/await mistakes, null/undefined risks, race conditions, type contract violations, or spec compliance. Dispatched by review-orchestrator for --frontend, --backend, and --all. Also invoked directly: "review logic", "check correctness", "are there any bugs here". NOT for: security vulnerabilities, performance profiling, style/naming preferences, or architectural pattern concerns — those belong in their respective specialized reviewers.
review-orchestrator
Use when: a code review is requested and the user does not explicitly name a specialized reviewer. Handles "review", "code review", "review PR", "review --frontend", "review --backend", "review --architecture", "review --security", "review --performance", "review --style", "review --strict", "review --project-conventions", "review --legacy-profiles", "review --all". Routes to specialized reviewers in parallel and consolidates findings into one unified report. NOT for: running a single specialized reviewer — invoke it directly by name instead.
review-performance
Use when a performance review is requested, checking for N+1 queries, unnecessary re-renders, memory leaks, missing indexes, large bundle imports, and synchronous blocking in changed code. NOT for security, logic correctness, style, or architecture.
review-security-code
Use when a code-level security review is requested, checking for injection vulnerabilities, auth gaps, insecure cryptography, secrets, and OWASP Top 10 patterns in changed code. NOT for infrastructure, deployment, or dependency audits.
review-strict
Use when: a strict engineering pass is needed — either as a meta-reviewer reading consolidated findings from other reviewers and elevating weak findings, or standalone on a git diff. Covers "strict review", "review --strict", "boss review", "review as boss", or dispatched by review-orchestrator as an optional post-pass after other reviewers complete. NOT for: first-pass review (run domain reviewers first); large refactors outside the diff scope (file separately).
review-style
Use when: reviewing code for style, naming conventions, readability, and DRY violations — without touching logic, architecture, security, or performance. Covers "review style", "style review", "check naming", "check readability", or dispatched by review-orchestrator with --style flag. NOT for: logic bugs, architectural violations, security vulnerabilities, performance anti-patterns, or any finding that could cause a functional regression.
docpack-review
Use when reviewing or verifying a Metaproject requirements package under docs/requirements for completeness, versioning, README/PRD/spec consistency, schema references, roadmap updates, unsupported claims, and implementation-status accuracy. Usually dispatched by docpack-orchestrator. Not for reviewing autodoc-generated current-codebase documentation.
perf-check
Use when measuring bundle size, detecting performance regressions, auditing slow queries, or investigating why something is slow.
security-audit
Use when checking for dependency vulnerabilities, accidentally committed secrets, or security issues in Docker images.
test-gen
Use when unit or integration tests need to be written for a specific file or module.
review-core-boundaries
Use when reviewing shared core/infrastructure module changes for dependency direction, feature-boundary leakage, abstraction stability, composition, and blast-radius risks. Dispatched by review-orchestrator for --core-boundaries, --project-conventions, --all, or src/core/** changes.
review-flow-graph
Use when reviewing generic ReactFlow or graph-surface abstraction changes: public graph surface, store subclassing, layout lifecycle, internal helper boundaries, selection lifecycle, and large-graph performance. Dispatched by review-orchestrator for --flow-graph, --project-conventions, --all, or src/core/flow/** / graph abstraction changes.
review-frontend-conventions
Use when reviewing frontend code against repository-local conventions commonly captured in CLAUDE.md or similar project guides: React/MobX boundaries, TypeScript strictness, i18n placement, storage wrappers, error handling, styling tokens, Storybook expectations, and local tooling rules. Dispatched by review-orchestrator for --frontend-conventions, --project-conventions, --all, or frontend src/**/*.ts(x) changes when local convention docs exist.
review-testing-practices
Use when reviewing unit, integration, Storybook, component, or e2e tests against repository-local testing conventions: co-location, network mocking, MSW-style boundary mocks, behaviour assertions, deterministic waits, smoke/full split, locator priority, and screenshot-test discipline. Dispatched by review-orchestrator for --testing-practices, --project-conventions, --all, or changed test/e2e/story files.
agent-entrypoint-distiller
Use when the user asks to split, decompose, distill, or refactor a large AGENTS.md or CLAUDE.md into Metaproject rules and project-specific skills while keeping root entrypoints compact.
flow
Use whenever the user asks to start, create, track, or finish a managed piece of work - "создай фло", "заведи флоу из этой ишью", "create a flow", "start a story", "какой статус по фло", "заверши фло/стори", or pastes an issue link asking to work on it. All flow state changes go through the keryx flow CLI; never edit flow.json or frozen acceptance criteria by hand.
gdctx
Use for commands, search, diff, test logs, lint/build output, and large file reads that can produce long output; prefer compact keryx ctx output before loading raw command output into agent context.
gdgraph
Use by default for project navigation and file discovery before broad raw search, especially when the user asks where something is, what files are related, what might be affected, or needs implementation, review, refactoring, debugging, architecture, dependency, module relationship, import cycle, or orphan-file context.
entity-skill-creator
Use when create canonical project-skills from a path, symbol, wiki page, module, component, store, service, or domain entity.
gdwiki
Use FIRST for conceptual questions - how something works, why, architecture, domain models, business rules, user scenarios, auth and other flows, integrations, and known decisions. Read wiki/index.md, then use gdgraph to reach code.
context-router
Use when choose between gdgraph, gdctx, gdwiki, memory, health, and project-skills before raw file reads.
entity-skill-learner
Use when update project-skills from review findings, test failures, health reports, memory entries, and verifier reports.
entity-skill-router
Use when select relevant project-skills for known modules, components, stores, services, and domain entities.
entity-skill-verifier
Use when verify project-skills against current code, graph, wiki, health, memory, tests, and review lessons.
metaproject-router
Use when choose which Metaproject module, working skill, or project-skill should be used for a user request.
agent-entrypoint-manager
Use when maintain AGENTS.md, CLAUDE.md, and local-first Metaproject references.
hook-manager
Use when create and verify lightweight git hooks for graph, health, and skill verification.
skill-catalog-manager
Use when generate `.metaproject/skills/catalog.md` and machine-readable skill registry.
health
Use for code quality state - lint, type, test, coverage, dependency, and complexity health of the project, a module, or a file. Read the health report before claiming quality status or gate results.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.