菜单
Use when deciding where new Yogieat code belongs or when reviewing architecture drift. Focuses on Service vs Facade boundaries, validator extraction, processor naming, transaction placement, dependency minimization, and preserving the existing multi-module structure.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when deciding whether a Yogieat prompt should stay on the main thread or consider repo-local agents. Classifies prompts, maps them to `feature_mapper`, `architecture_guard`, `validation_triager`, or `harness_curator`, and keeps delegation intentionally minimal.
Use when adding or extending a Yogieat feature in the Java 25 multi-module Spring Boot architecture. Maps the request to the smallest consistent slice across `apps:api/admin`, `apps:domain`, `storage`, `external`, and `support` while preserving the current Service, Facade, Processor, and Validator conventions.
Use when repeated Yogieat prompts, review comments, or misunderstandings should be translated into harness candidates or stable rules. Classifies new observations, applies the candidate-to-promotion policy, and keeps harness updates intentional rather than noisy.
Use when validating Yogieat changes or choosing the smallest Java 25 Gradle proof command. Applies Spotless first, then compile, then module-local or full tests based on repo-specific escalation rules.
Use when writing, refactoring, or reviewing Yogieat tests. Focuses on behavior-first assertions, boundary-only mocking, test layer choice, and smell detection for spy-heavy or verify-heavy tests.
yogieat-server 멀티모듈 클린 아키텍처의 구현 가이드. 새 도메인이나 기능을 추가할 때 어떤 모듈에 어떤 파일을 어떤 패턴으로 만들어야 하는지 안내한다. Spring Boot 멀티모듈, 클린 아키텍처, domain Record, Entity 매핑, Repository 인터페이스 패턴 등을 다룬다.
基于 SOC 职业分类
| name | yogieat-clean-architecture-guard |
| description | Use when deciding where new Yogieat code belongs or when reviewing architecture drift. Focuses on Service vs Facade boundaries, validator extraction, processor naming, transaction placement, dependency minimization, and preserving the existing multi-module structure. |
Use this skill when the task is "where should this live?" or "does this still fit the project conventions?"
./AGENTS.md and .codex/rules/architecture.md.@Transactional(readOnly = true) on read-only facade or service methodsreadOnly = true or missing a write transaction boundarydashboard endpoints for data that should still be a resource representationPOST resource creation when the feature needs canonical item access