mcpbeat

Grad Sd Logic

asgard-ai-platform/grad-sd-logic

Apply Service-Dominant Logic (Vargo and Lusch, 2004) and value co-creation principles to reframe exchange and value creation. Use this skill when the user needs to redesign value propositions around service exchange, analyze co-creation dynamics between firms and customers, shift from goods-dominant to service-dominant thinking, or when they ask 'how is value created with customers', 'what is our service logic', or 'how do we enable co-creation'.

3k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
223
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/asgard-ai-platform/skills --skill grad-sd-logic

What comes with it

6 813 bytes besides the instruction
examples/sample_scenario.md

The instruction itself

13 sections, as written by the author

Service-Dominant Logic (S-D Logic)

Overview

Service-Dominant Logic reframes marketing from goods-centered (value-in-exchange) to service-centered (value-in-use). Vargo and Lusch (2004, 2008, 2016) articulate foundational premises: service is the fundamental basis of exchange, value is always co-created with beneficiaries, and all economic actors are resource integrators.

When to Use

  • Redesigning value propositions to emphasize service and outcomes
  • Analyzing how value is co-created across actor networks
  • Shifting organizational mindset from product-centric to service-centric
  • Designing service ecosystems and platform strategies

When NOT to Use

  • Operational cost optimization of existing manufacturing processes
  • Short-term pricing decisions requiring goods-dominant accounting
  • When stakeholders require traditional financial metrics without translation

Assumptions

IRON LAW: Value is ALWAYS co-created. The firm can only offer value
propositions, not deliver value. Value is uniquely and phenomeno-
logically determined by the beneficiary in context of use.

Key assumptions:

  • Service (application of competences) is the fundamental basis of exchange
  • Goods are distribution mechanisms for service provision
  • Operant resources (knowledge, skills) are the primary source of advantage
  • All actors (firms, customers, partners) are resource integrators
  • Value is always co-created within service ecosystems

Methodology

Step 1 — Map the foundational premises

Evaluate the current business through S-D Logic's key foundational premises (FPs):

| FP | Premise | Diagnostic Question |

|----|---------|-------------------|

| FP1 | Service is the fundamental basis of exchange | What competence application does our offering enable? |

| FP6 | Value is co-created by multiple actors | Who participates in value creation beyond the firm? |

| FP7 | Actors cannot deliver value, only offer propositions | Are we assuming value is embedded in the product? |

| FP9 | All actors are resource integrators | What resources do customers bring to the exchange? |

| FP10 | Value is uniquely determined by the beneficiary | Do we measure value-in-use or only value-in-exchange? |

Step 2 — Identify operant vs operand resources

| Resource Type | Definition | Examples |

|--------------|-----------|----------|

| Operand | Resources acted upon (static) | Raw materials, equipment, money |

| Operant | Resources that act on others (dynamic) | Knowledge, skills, technology, relationships |

Shift strategic focus from operand to operant resources.

Step 3 — Map the service ecosystem

Identify all actors, institutions, and resource flows in the value co-creation network:

  • Micro level: dyadic interactions (firm-customer)
  • Meso level: service systems and platforms
  • Macro level: institutional arrangements and shared norms

Step 4 — Redesign value propositions

Reframe offerings as value propositions that enable beneficiary value creation:

  • From "what we sell" to "what outcomes we enable"
  • From "product features" to "resource integration support"
  • From "delivery" to "co-creation facilitation"

Output Format

## S-D Logic Analysis: [Context]

### Current Logic Assessment
- Dominant logic: [goods-dominant / transitioning / service-dominant]
- Value definition: [value-in-exchange / value-in-use / both]

### Foundational Premise Audit
| FP | Current State | Gap | Action |
|----|--------------|-----|--------|
| FP1 (Service basis) | | | |
| FP6 (Co-creation) | | | |
| FP10 (Beneficiary value) | | | |

### Service Ecosystem Map
- Key actors: ...
- Resource flows: ...
- Institutional arrangements: ...

### Redesigned Value Propositions
1. [From]: [product-centric statement] → [To]: [service-centric proposition]
2. ...

Gotchas

  • S-D Logic is a lens/mindset, not a predictive model — it reframes thinking but does not forecast outcomes
  • "Co-creation" does not mean the customer does the work; it means value emerges in use context
  • Value co-destruction is possible when resource integration fails — do not assume co-creation is always positive
  • Operant resources are harder to measure than operand resources; resist defaulting to tangible metrics
  • S-D Logic's vocabulary (operant/operand, service ecosystem) can alienate practitioners — translate carefully
  • Institutions and institutional logics (added in 2016 update) are essential for ecosystem-level analysis

References

  • Vargo, S. L., & Lusch, R. F. (2004). Evolving to a new dominant logic for marketing. *Journal of Marketing*, 68(1), 1-17.
  • Vargo, S. L., & Lusch, R. F. (2008). Service-dominant logic: Continuing the evolution. *Journal of the Academy of Marketing Science*, 36(1), 1-10.
  • Vargo, S. L., & Lusch, R. F. (2016). Institutions and axioms: An extension and update of service-dominant logic. *Journal of the Academy of Marketing Science*, 44(1), 5-23.

How to use it

Copy the folder

Take asgard-ai-platform/grad-sd-logic from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.