一键导入
这个仓库中的 skills
Create or improve Claude Code and Codex skills. Use only when the request is explicitly about the skill itself: creating a new skill, editing a SKILL.md file, testing a skill draft in .claude/skills/.../SKILL.md or .agents/skills/.../SKILL.md, improving an existing skill, debugging why a skill is not triggering, running evals or benchmarks for a skill, or turning an already-described workflow into a reusable skill. Trigger on phrases like existing skill, skill draft, SKILL.md, skill trigger, skill eval, make this into a skill, or turn this workflow into a skill. Do not use for ordinary implementation work unless the user explicitly mentions a skill, SKILL.md, or converting the task into a skill. That exclusion includes generic coding tasks, generic automation/workflow setup, CI setup, GitHub Actions workflows, debugging, code review, database migrations, schema changes, and production incident response when the user is just asking for help with the task itself.
Use when designing or reviewing domain-model accessors that expose internal state for persistence, serialization, tests, or framework integration. Applies the breachEncapsulationOf naming pattern so unavoidable getters are visibly treated as encapsulation breaches, not casual domain APIs. Trigger for getter naming conventions, persistence-only getters, serialization accessors, Tell Don't Ask pressure, or requests to prevent getter misuse.
Use only when the user explicitly asks for Clean Architecture design, implementation, or review. Applies a domain, use case, interface adapter, and infrastructure layer model, with persistence and RPC adapters outside the domain and use-case rules. Do not trigger for generic architecture advice, hexagonal architecture, onion architecture, or ordinary design review unless Clean Architecture is named.
Use when CQRS changes aggregate boundaries or state shape. Helps reduce oversized command aggregates by moving read concerns to read models, keeping only command-decision state in aggregates, and using events for state transitions. Trigger for large aggregates, heavy command updates, aggregates containing query-only data, or boundary redesign during CQRS adoption.
Use when explaining why CQRS often needs event sourcing or durable events for reliable command-to-query synchronization. Covers calculated value sync, database trigger limits, polling scalability, double commits, and making events the source of truth. Trigger for CQRS synchronization, read-model update strategy, CQRS without ES, or double-commit concerns.
Use when evaluating whether CQRS is worth adopting, especially tradeoffs among consistency, availability, scalability, operational complexity, and event sourcing. Trigger for read/write separation decisions, eventual consistency concerns, CQRS architecture review, or choosing between a unified model and CQRS.
Use when creating project-specific lint rules for AI agents or humans using existing language linter ecosystems. Generates rules under a `lints/` directory with actionable diagnostic messages that tell an agent exactly how to repair the violation. Trigger for custom lint rules, AI linter rules, enforcing naming or structure patterns, or turning code-review rules into lint checks.
Use for DDD aggregate design, implementation, refactoring, or review. Covers aggregate boundaries, aggregate roots, true invariants, immutable updates, ID references, eventual consistency, domain events, and Evans/Vernon aggregate rules. Trigger for aggregate boundary questions, aggregate roots, entity design inside aggregates, large aggregates, mutable aggregate code, public fields, direct child mutation, or cross-aggregate coordination.
Use when reviewing or designing transaction boundaries that touch DDD aggregates. Detects the anti-pattern of updating multiple aggregates in one transaction and replaces it with one-aggregate transactions plus eventual consistency, domain events, sagas, or process managers. Trigger for cross-aggregate transactions, `@Transactional` use cases, one transaction one aggregate, or aggregate consistency coordination.
Use when a use case wants to check another aggregate's state before changing the current aggregate. Helps separate true invariants from policies, detect Saga misuse, reason about CQRS/Event Sourcing lookup limits, and decide whether inconsistent data is acceptable. Trigger for cross-aggregate validation, checking another aggregate, command-side read-model access, reverse lookup constraints, or Saga-based validation.
Use for choosing and applying DDD building blocks: value objects, entities, aggregates, domain services, repositories, factories, and domain events. Trigger for domain modeling, entity versus value object decisions, aggregate boundaries, domain service placement, or implementing a domain model from requirements.
Use when analyzing existing non-DDD or legacy code to propose DDD domain models with aggregates, local entities, value objects, domain services, invariants, and pseudocode. Trigger for extracting a domain model from code, redesigning legacy code with DDD, finding aggregates, or proposing domain boundaries from an existing implementation.
Use when planning a DDD implementation flow that starts from the domain model and tests before infrastructure. Covers test-first domain modeling, in-memory repositories, use cases, and delaying persistence/framework choices. Trigger for starting from the domain model, TDD with DDD, in-memory repository design, use-case tests, or DDD development process.
Use when replacing raw primitive values with validated domain primitives or value objects so invalid domain states cannot be represented. Covers always-valid construction, smart constructors, parse-don't-validate, and avoiding primitive obsession. Trigger for domain primitive design, validated IDs, email/money/range types, always-valid models, or preventing invalid states.
Use when designing DDD module boundaries, package layout, bounded-context internals, or language-specific module organization. Helps keep domain concepts cohesive while exposing narrow APIs and hiding implementation details. Trigger for DDD modules, package-by-domain, bounded context internals, module visibility, or organizing aggregates and value objects.
Use when designing or reviewing repositories in DDD. Treats repositories as collection-like access to aggregate roots, not generic DAO layers, and separates query/read-model concerns from command persistence. Trigger for repository interfaces, aggregate persistence, save/load semantics, query placement, ORM leakage, or repository anti-patterns.
Use when deciding where repository interfaces and implementations belong in layered, Clean Architecture, or DDD projects. Emphasizes that aggregates should not depend on repositories and that application/use-case layers own repository orchestration. Trigger for repository-in-domain questions, repository package placement, or aggregates calling repositories.
Use when deciding whether a primitive value should become a domain-specific type or value object. Balances primitive obsession against value-object obsession using risk, invariants, behavior, and cost. Trigger for wrapping strings/ints/UUIDs, value object decisions, too many tiny types, or whether a primitive is good enough.
Use when clarifying software abnormal-state terminology such as error, defect, fault, failure, bug, incident, and exception. Helps choose handling, testing, and mitigation strategies from precise classification. Trigger for error terminology, fault versus failure, defect versus bug, abnormal-state design, failure analysis, or test classification.
Use when designing or reviewing error handling across domain logic, application services, and infrastructure. Uses recoverability to choose typed errors, Result/Either, exceptions, retries, and logging. Trigger for improving error handling, Result types, exception design, recoverable errors, domain errors, or error-handling refactors.
Use when wrapping collections in a domain-specific class to centralize collection rules, invariants, and behavior. Trigger for scattered list logic, collection wrappers, raw Order lists becoming `Orders`, enforcing collection invariants, or reviewing collection-heavy domain code.
Use when deciding whether similar code should be deduplicated. Prioritizes shared intent and change reason over textual similarity, avoiding harmful DRY abstractions when code looks alike but changes for different reasons. Trigger for duplicate code, DRY decisions, merging functions, common helpers, or refactoring similar implementations.
Use when reviewing or refactoring object coupling caused by train-wreck call chains and knowledge of nested internals. Applies the Law of Demeter / Principle of Least Knowledge to move behavior closer to the owning object. Trigger for chained calls, dot chains, train wrecks, high coupling, Feature Envy, or reducing object navigation.
Use only when migrating an existing skill directory from `.claude/skills/{name}` to `.agents/skills/{name}` and creating `.claude/skills/{name}` and `.codex/skills/{name}` symlinks. Requires a skill name argument. Trigger for migrating skills to `.agents`, unifying Claude and Codex skill locations, or creating these skill symlinks.
Use when redesigning package or module structure for messy codebases, large modules, dependency problems, or new project structure. Applies information hiding, change reasons, dependency direction, and release boundaries. Trigger for package structure review, module dependencies, file placement, circular dependency cleanup, or module hierarchy design.
Use when replacing validation that discards information with parsing that returns a typed, validated value. Helps enforce invariants through the type system and reduce shotgun parsing. Trigger for validation refactors, type-safe inputs, invalid-state prevention, reducing `Maybe`/nullable checks, or converting validators into constructors/parsers.
Use only for Scala 3 implementations of CQRS/Event Sourcing with Apache Pekko. Covers aggregate actors, PersistenceEffector-style command handling, domain-model separation, typed state transitions, event design, Protocol Buffers serialization, ZIO use cases, and read-model updaters. Do not trigger for non-Scala stacks or conceptual CQRS questions without Pekko/Scala implementation work.
Use when actively refactoring an existing codebase's package or module structure. Detects cycles, oversized modules, misplaced responsibilities, and dependency direction problems, then proposes and executes a migration plan. Trigger for cleaning dependencies, breaking cycles, splitting modules, moving files, or structural refactoring work.
Use when reviewing or improving Claude Code, Codex, or compatible agent skills. Checks SKILL.md frontmatter, trigger boundary, progressive disclosure, no-op instructions, duplication, sediment, sprawl, examples, and validation readiness. Trigger for skill review, SKILL.md review, skill quality check, trigger debugging, or improving an existing skill.
Use when reviewing or refactoring code that queries object state and makes decisions outside the object that owns the data. Moves behavior to the responsible object to improve encapsulation. Trigger for getter misuse, Feature Envy, Tell Don't Ask, encapsulation improvements, or moving responsibility into domain objects.
Commit working-tree changes using Conventional Commits. Stage changes in meaningful units, write commit messages in English, and avoid co-author or agent attribution in commit messages. Use this skill only when the user explicitly asks to create a real git commit, such as "commit these changes", "create a git commit", "git commit", or "commit this work". Do not use it when the user only wants commit message wording without making an actual commit. This skill commits locally only; it does not push.
Create, improve, and review GitHub OSS README.md files. Organize information around What, Why, How to start, Help, and Maintainers, and make the shortest credible path to Quickstart and docs obvious. Use this skill for new README creation, README restructuring, README review, and deciding when detailed documentation should move out of the README. Trigger on README-related requests such as "create a README", "improve this README", "add a Quickstart", "make a GitHub README template", or "review this README".
Systematically inventory and organize GitHub Issues. Classify open issues, group related work, identify close candidates, prioritize remaining work, and propose useful batches. This includes separating CodeRabbit-generated issues from human-reported issues, grouping by root cause, and finding completed issues that can be closed. Trigger on GitHub Issue organization requests such as "organize issues", "triage GitHub issues", "audit open issues", "close stale issues", or "prioritize issues".
既存のTAKTワークフローとファセットを分析し、改善提案を行うスキル。ワークフローYAMLの構造検証、 ファセット間の整合性チェック、スタイルガイド準拠の確認、未使用ファセットの検出、 ルール設計の最適化提案を実施する。実行ログ(.takt/logs/*.jsonl)が存在する場合は ログベース診断分析も行い、ルール評価効率・ループホットスポット・ABORT率等を報告する。 references/taktのスタイルガイド・エンジン仕様を基準として分析する。 トリガー:「ワークフローを分析」「taktの設定を確認」「ファセットの品質チェック」 「ワークフローのレビュー」「takt analyze」「ワークフローの改善提案」 「ワークフローの整合性チェック」「taktの問題を見つけて」 「ログを分析」「実行ログの診断」「taktのログを見て」「ルール評価の統計」 「ai_fallbackの頻度」「ループの検出」
TAKTファセット(Persona/Policy/Instruction/Knowledge/Output Contract)の 個別作成・編集スキル。各ファセットのスタイルガイドに準拠した単体ファイルを生成する。 references/taktにあるスタイルガイド・ビルトインファセット群を参照資料として活用し、 ファセット種別の判断、テンプレート選択、品質チェックを行う。 トリガー:「ペルソナを作りたい」「ポリシーを追加」「インストラクションを書く」 「ナレッジを定義」「出力契約を作成」「ファセットを編集」「takt facet」 「レビュアーのペルソナ」「コーディングポリシー」
既存のTAKTワークフロー(ワークフローYAML・ファセット群)を最適化するスキル。 トークン消費削減、ステップ統合、ルール簡素化、ファセット再利用促進、 ループ制御の改善、並列化の提案を実施し、最適化後のファイルを直接生成する。 takt-analyzeの診断結果(静的分析・ログ診断)を入力として活用できる。 本スキルは「最適化の実行」のみを担い、診断・分析はtakt-analyzeに委譲する。 references/taktのエンジン仕様・スタイルガイドを基準とする。 トリガー:「ワークフローを最適化」「taktの高速化」「ワークフローを軽くしたい」 「トークンを減らしたい」「ステップを減らしたい」「takt optimize」 「ワークフローの効率化」「ファセットを整理したい」「ワークフローをスリムにして」 「taktのコスト削減」「ワークフローをシンプルにしたい」
nrslib/takt の新バージョンリリース時に、takt-*スキル群(takt-task-builder, takt-workflow-builder, takt-facet-builder, takt-analyzer, takt-optimizer)を最新のtaktバージョンに追従させるスキル。 TypeScriptスキーマ(taskRecordSchemas.ts / taskExecutionSchemas.ts)、ワークフローYAML、ファセットMarkdownの差分を検出し、 SKILL.md・参照ドキュメント(task-schema.md等)を体系的に更新する。 トリガー:「taktスキルを更新」「takt-*スキルの鮮度チェック」「taktバージョンアップ対応」 「スキルが古くないか確認」「takt skill updater」
TAKTワークフロー(ワークフローYAML)の作成・カスタマイズスキル。Faceted Prompting (Persona/Policy/Instruction/Knowledge/Output Contract)に基づくファセット群の 生成を含む。references/taktにあるtaktのソースコード・ドキュメント・ビルトインワークフロー群を 参照資料として活用する。ユーザーの要件をヒアリングし、step構成、ルール設計、 ファセットファイル生成を一括で行う。 トリガー:「ワークフローを作りたい」「ワークフローを定義」「taktのワークフローを作成」 「新しいtaktワークフローを作って」「takt workflow」「ワークフローYAML」
TAKT ワークフローエンジン。Agent Team を使ったマルチエージェントオーケストレーション。ワークフロー YAML(steps / initial_step)に従ってマルチエージェントを実行する。
TAKTのtasks.yaml(タスクメタデータ)とタスクディレクトリ(.takt/tasks/{slug}/order.md)の 作成・編集を支援するスキル。TaskRecordスキーマに準拠したYAMLエントリの生成、 order.mdタスク仕様書の作成、ステータス遷移ルールの検証を行う。 references/taktにあるtaskスキーマ定義・ドキュメントを参照資料として活用する。 トリガー:「タスクを追加」「tasks.yamlを編集」「taktタスクを作成」 「タスク仕様書を書く」「order.mdを作成」「takt task」「タスクを定義」 「pendingタスクを追加」「GitHub Issueからタスク作成」