菜单
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.