publish-subscribe-designer
Purpose
Design publish-subscribe interactions with explicit producers, consumers, events, topics, and failure handling.
Expected inputs
- events to emit
- producers
- consumers
- failure/ordering requirements
Deliverables
- pub/sub design
- topic-event map
- failure handling notes
- operational considerations
Trigger this skill when
- You need to make an enterprise or integration decision that spans more than a single codebase.
- Multiple systems, teams, environments, or governance constraints influence the design.
- A recommendation needs to be tied to enterprise reality rather than generic integration advice.
Operating procedure
- Clarify the system, estate, or cross-system workflow being assessed.
- Separate facts, assumptions, constraints, and missing enterprise context.
- Produce a context-specific analysis rather than a platform- or buzzword-driven recommendation.
- Make tradeoffs explicit, especially around governance, ownership, runtime failure, and operational cost.
- Recommend the next most useful architecture or delivery skill.
Quality gates
- Recommendations acknowledge enterprise constraints, ownership, and operational consequences.
- Interfaces, dependencies, and environment implications are not hand-waved away.
- Assumptions and open questions are visible.
- Output is specific enough to inform architecture, integration, or release planning.
Output style
- Be concrete and structured.
- Separate evidence, inference, and recommendation.
- Prefer explicit tradeoffs over single-answer absolutism.
- Use priority or severity where useful.
Failure modes to avoid
- Do not recommend technology because it sounds enterprise-grade.
- Do not ignore team boundaries, operational maturity, or integration sprawl.
- Do not treat all workloads as equally suited to the same platform pattern.
- Do not hide uncertainty behind confident language.
Minimum output skeleton
## Summary
## Findings or proposal
## Evidence vs assumptions
## Risks or tradeoffs
## Recommended next skill
Handoff targets
- message-bus-selector
- loose-coupling-checker
- environment-topology-planner
1---2name: publish-subscribe-designer3description: publish-subscribe-designer4---5# publish-subscribe-designer67## Purpose8Design publish-subscribe interactions with explicit producers, consumers, events, topics, and failure handling.910## Expected inputs11- events to emit12- producers13- consumers14- failure/ordering requirements1516## Deliverables17- pub/sub design18- topic-event map19- failure handling notes20- operational considerations2122## Trigger this skill when23- You need to make an enterprise or integration decision that spans more than a single codebase.24- Multiple systems, teams, environments, or governance constraints influence the design.25- A recommendation needs to be tied to enterprise reality rather than generic integration advice.2627## Operating procedure281. Clarify the system, estate, or cross-system workflow being assessed.292. Separate facts, assumptions, constraints, and missing enterprise context.303. Produce a context-specific analysis rather than a platform- or buzzword-driven recommendation.314. Make tradeoffs explicit, especially around governance, ownership, runtime failure, and operational cost.325. Recommend the next most useful architecture or delivery skill.3334## Quality gates35- Recommendations acknowledge enterprise constraints, ownership, and operational consequences.36- Interfaces, dependencies, and environment implications are not hand-waved away.37- Assumptions and open questions are visible.38- Output is specific enough to inform architecture, integration, or release planning.3940## Output style41- Be concrete and structured.42- Separate evidence, inference, and recommendation.43- Prefer explicit tradeoffs over single-answer absolutism.44- Use priority or severity where useful.4546## Failure modes to avoid47- Do not recommend technology because it sounds enterprise-grade.48- Do not ignore team boundaries, operational maturity, or integration sprawl.49- Do not treat all workloads as equally suited to the same platform pattern.50- Do not hide uncertainty behind confident language.5152## Minimum output skeleton53```md54## Summary55## Findings or proposal56## Evidence vs assumptions57## Risks or tradeoffs58## Recommended next skill59```6061## Handoff targets62- message-bus-selector63- loose-coupling-checker64- environment-topology-planner