メニュー
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: