메뉴
Project design system rules — CSS framework, visual grammar, component classes, and UI generation surface patterns. Read this before designing or reviewing views to understand the project's visual constraints.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Rails engineering principles — Rails-first design, DRY, SRP, concerns (3-method rule), REST, no service objects, business logic in models, dependency discipline. Shared by architect (designs to these), engineer (builds to these), and review agents (checks against these).
CLI reference for bin/agent-log — agent activity logging tool. Provides run lifecycle management, decision logging, event logging, and query commands backed by db/agent_log.sqlite3.
The 12-section feature specification format — used by the architect to write feature specs and by the orchestrator to validate spec completeness before handing to the engineer.
Handoff contract between the discovery agent and the architect agent. Defines what a complete brief contains, what level of detail prevents follow-up questions, and what the architect can derive from the codebase vs. what must come from the user.
DEPRECATED — this skill has been replaced by the generic design-system skill at skills/design-system/SKILL.md. This directory can be deleted.
| name | design-system |
| description | Project design system rules — CSS framework, visual grammar, component classes, and UI generation surface patterns. Read this before designing or reviewing views to understand the project's visual constraints. |
This skill is project-specific. Read it to understand the CSS framework, visual grammar, and component library before designing or reviewing views.
Setup required: When adopting this team for a new project, replace the placeholder sections below with the project's actual design system documentation. Remove any sections that don't apply (e.g., AI generation surfaces for projects without LLM features).
Fill in your project's CSS framework name, class prefix/naming pattern, and layout system.
Document:
ERB helper methods (if any):
List any view helpers that wrap framework components. Example:
framework_button(label, **options)
framework_card(**options, &block)
framework_badge(label, variant:)
Define the type treatment for different data types. A clear grammar lets every agent make consistent class decisions without guessing.
Fill in your project's visual grammar rules. Example pattern:
| Type | Treatment | Class |
|---|---|---|
| Technical data (IDs, timestamps, counts, codes, file sizes) | Monospace | [your-mono-class] |
| Prose, labels, instructions, headings, generated text | Sans-serif (default) | (no class needed) |
The rule: name the class for every data field in every design spec. A field rendered in the wrong type treatment is a design system violation.
If this project has no AI generation features, delete this section.
Every surface that triggers or displays AI generation must follow this contract:
Trigger state — before generation fires:
Loading state — while generation is in progress:
Error states — when generation fails:
<%# Pattern for a generation trigger — replace with this project's trigger class %>
<%= framework_button "Generate", class: "[ai-trigger-class]", data: { turbo_submits_with: "Generating..." } %>
Fill in prohibited patterns for this project's views.
Common entries: