القائمة
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.