메뉴
Use when you have new source material (transcripts, interviews, support logs, docs, code changes) and want to reason about what existing service design artifacts need updating
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when writing Rails controllers or implementing state changes - enforces resource extraction, thin controllers delegating to models, params.expect, and controller concerns for scoping
Use when designing database schema, writing migrations, or making data storage decisions - enforces UUIDs, account_id multi-tenancy, no foreign keys, and proper index patterns
Use when writing Hotwire (Turbo/Stimulus) code in Rails - enforces dom_id helpers, morph updates, focused Stimulus controllers, and JavaScript private methods
Use when writing background jobs or async operations - enforces thin job wrappers (3-5 lines) that delegate to models using _later/_now naming pattern
Use when writing Rails models - enforces state-as-records not booleans, concerns as adjectives namespaced under model, and concern extraction triggers
Use when naming classes, methods, routes in vanilla Rails codebases - enforces concern adjectives (-able/-ible only), no bangs for state, resource naming cascade, and commit message format
| name | service-design-ingest |
| description | Use when you have new source material (transcripts, interviews, support logs, docs, code changes) and want to reason about what existing service design artifacts need updating |
Core principle: New evidence updates understanding. Process source material and propose specific, traceable updates to existing artifacts.
Accept pasted content, file paths, or URLs. Classify before processing:
| Source type | What it typically reveals |
|---|---|
| Transcript / interview | User mental models, emotions, language, unmet expectations |
| Support log | Failure points, recovery paths, frequency signals |
| Ops runbook / code change | Backstage process shifts, new constraints |
| Business doc | Strategic intent, success metrics, org priorities |
| User feedback | Peak moments, information gaps |
docs/service-design/<slice>/).| Classification | Meaning | Action |
|---|---|---|
| Confirm | Evidence supports an existing [hypothesis] | Upgrade to [confirmed], cite source |
| Contradict | Evidence conflicts with an existing entry | Downgrade or flag [gap], explain conflict |
| Extend | Elaborates on an existing entry | Propose addition with confidence tag |
| Novel | No match in existing artifacts | Propose where it belongs |
docs/service-design/<slice>/sources/ for traceability.The most important output is confidence movement: [hypothesis] → [confirmed], or [confirmed] → [gap] when evidence contradicts. Every ingest should strengthen or challenge what's already written.
Present proposed updates for human review. The human decides what to accept.
Every sibling skill produces artifacts this skill updates: service-design:service-blueprint, service-design:empathy-analysis, service-design:journey-map. Run ingest first, then the relevant skill to incorporate accepted changes.