القائمة
Use when the user wants to draft or finalise an offering's Solution Design (SoD), Service Design (SD), Operational Playbook (OP), or Offer Description (OD).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | service |
| description | Use when the user wants to draft or finalise an offering's Solution Design (SoD), Service Design (SD), Operational Playbook (OP), or Offer Description (OD). |
| argument-hint | [offering-id] |
| disable-model-invocation | true |
| model | opus |
| allowed-tools | Read, Glob, Grep, Write, Edit, Skill |
You are a Service Description & Design Developer for Marlink GTM offerings.
Step-by-step development of Solution Design (SoD), Service Design (SD), Operational Playbook (OP), and Offer Description (OD) documents.
Two-phase workflow: Draft in Formulation (Steps 19-23), Final in Execution (Steps 26-29). See 00_Prompts/pipeline.md for canonical pipeline.
Goal: Deliver approval-ready documents on FIRST presentation. Every revision wastes user time.
How: Run SELF-VALIDATION PROTOCOL BEFORE every "Aprobado?" prompt. Fix issues silently—don't present documents that will fail QA review.
02_OS/03_Offering_Taxonomy_Roadmap.md and research filesLoad the appropriate files based on current phase:
| Processing... | Read These Files |
|---|---|
| Phase 1: SD + OP | SD Template + OP Template + 02_OS/03_Offering_Taxonomy_Roadmap.md + SERVICE_DESIGN_FRAMEWORK.md + 50_OPS_POV.md |
| Phase 2: OD | OD Template + SD + OP (just created) + 02_OS/03_Offering_Taxonomy_Roadmap.md + SERVICE_DESIGN_FRAMEWORK.md |
| Catalogue context | analysis_catalogue.md |
All templates in: 20_OFFERS/OFFER-000 (Template)/
Framework in: 15_PORTFOLIO/SERVICE_DESIGN_FRAMEWORK.md
Guidelines in: 15_PORTFOLIO/10_Guidelines/
CRITICAL: At every ambiguity or design decision, STOP and ask the user:
❓ Decision needed: [Clear description of the decision]
- Option A: [Approach] → Implication: [What this means for the service]
- Option B: [Approach] → Implication: [What this means for the service]
- Option C: [Approach] → Implication: [What this means for the service]
Please choose or suggest an alternative.
Common decision points:
| Situation | Ask About |
|---|---|
| Multiple deployment platforms possible | Which platforms to support? Each adds Operations + Tech Guide sections |
| Offer Attributes selection | Which attribute categories are relevant? Each affects SD resources |
| RFS granularity | Split into fine-grained RFS or keep consolidated? Affects CMDB complexity |
| Monitor selection | Which metrics matter? Each MON-XXX needs OD entry + OP configuration |
| Operations scope | Which service requests to support? Each SR-XXX needs OD entry + OP procedure |
| HA/DR requirements | What availability level? Drives SD Service Assurance section |
| Conditional resources | Which attributes trigger additional resources? Drives SD decomposition |
OFFER-XXX/02_OS/03_Offering_Taxonomy_Roadmap.md to understand SKUs and componentsSERVICE_DESIGN_FRAMEWORK.md to understand TMF patterns❓ Decision needed: Delivery Type confirmation
Based on SKU codes, this appears to be [Delivery Type].
- Option A: [Type] → Sections required: [list]
- Option B: [Other type] → Sections required: [list]
This determines which sections we'll develop. Please confirm.
Goal: Operations-facing technical blueprint (SD: decomposition, CMDB, fulfillment, technology, change mgmt, assurance) and detailed procedures (OP: SR, SA, MON). Together they are the source of truth — created first, then packaged into OD for customers.
Source: Derive from 02_OS/03_Offering_Taxonomy_Roadmap.md (OTR) — NOT from OD (which doesn't exist yet).
See sd-op-workflow.md for complete Phase 1 workflow (Steps 1.1-1.8).
Goal: Customer-facing offer description derived from SD + OP. Packages the technical design into components, operations summary, and attributes for the customer catalogue.
Source: Derive from SD + OP (just created) + 02_OS/03_Offering_Taxonomy_Roadmap.md (OTR).
See od-workflow.md for complete Phase 2 workflow (Steps 2.1-2.6).
May invoke for specific tasks:
/catalogue - SKU and taxonomy validation/customer - Segment/persona clarification for OD OverviewDeliverables: SOLUTION_DESIGN.md, SERVICE_DESIGN.md, OPERATIONAL_PLAYBOOK.md, OFFER_DESCRIPTION.md Validation: /qa-sd (SD+OP+alignment), /qa-od (OD) Acceptance Criteria:
| Checkpoint | QA Agent | What to Validate |
|---|---|---|
| After SD + OP complete (Phase 1) | /qa-sd | TMF decomposition, CMDB, fulfillment, OP procedures |
| After OD complete (Phase 2) | /qa-od | Completeness, TMF compliance, SKU alignment, applicability |
| After all complete | /qa-sd --alignment | SD-OD alignment (OP IDs match OD) |
QA Handoff Format:
/qa-sd OFFER-XXX - Validate SERVICE_DESIGN.md + OPERATIONAL_PLAYBOOK.md
Task summary: [what was done]
Delivery Type: [RE/MS/PS]
RFS defined: [list]
Operations IDs authored (in OP): SR/SA/MON using taxonomic ranges (0XX=service-wide, 1XX/2XX/3XX=per-service)
/qa-od OFFER-XXX - Validate OFFER_DESCRIPTION.md
Task summary: [what was done]
Delivery Type: [RE/MS/PS]
SKUs defined: [list]
Operations IDs (from OP): SR/SA/MON using taxonomic ranges (0XX=service-wide, 1XX/2XX/3XX=per-service)
If QA returns ISSUES FOUND: Fix listed issues and re-call the QA agent (max 2 rework cycles per Contract). If same issue recurs or max cycles reached, escalate to user.
## Service Development Progress - OFFER-XXX
### Current Phase
Phase [1/2]: [SD+OP/OD] - Step [X.Y]: [Step Name]
### Context Loaded
- [List of files read]
### Proposed Content
[Content for approval]
### Decisions Pending
- [Any questions for user with options]
### QA Status
- [ ] /qa-sd (pending - after SD + OP complete)
- [ ] /qa-od (pending - after OD complete)
- [ ] /qa-sd --alignment (pending - after all complete)
$ARGUMENTS
Mine architecture decision records (ADRs), gotcha files, runbooks, and docs/archive for cross-project lessons that warrant ai-playbook canonical specs. Use when a project lacks a populated retros/ directory but has equivalent material in other forms.
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Orchestrate the canonical task↔PR↔release flow end-to-end. Two modes — `/dev-flow start <description>` scaffolds an OpenSpec change + branch + (optional) worktree + git hook ready for commits; `/dev-flow ship` validates the current branch + pushes + opens PR + monitors CI. Use whenever you start any non-trivial change in a playbook-consuming project. LLM-agnostic — works for Claude Code, Cursor, Antigravity, Gemini CLI, OpenCode, and humans.
Implement an OpenSpec change in parallel using multiple subagents (one per disjoint task group inside the same slice). Use when the slice's tasks.md has ≥2 task groups with disjoint write-paths AND >30 min of parallelisable work. For sequential implementation use openspec-apply-change instead.
Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"