Agent skill

Phoenix Pubsub Patterns

by j-morgan6 in j-morgan6/elixir-phoenix-guide

A skill your agent uses when adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology, topic naming, handleinfo message handling.

MITAuto-check passedBackend & APIs

Install Phoenix Pubsub Patterns

skills CLI
$ npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-pubsub-patterns -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install j-morgan6/elixir-phoenix-guide phoenix-pubsub-patterns --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/j-morgan6/elixir-phoenix-guide.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/phoenix-pubsub-patterns .claude/skills/phoenix-pubsub-patterns && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
phoenix-pubsub-patterns
GitHub stars
166
Token cost
~1.8k tokens
SKILL.md length
273 words
Files
1
Skills in repo
19
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology, topic naming, handleinfo message handling.

  • Works in 6 steps: Always guard subscriptions with if… → Broadcast from contexts, not LiveViews —… → Use consistent topic naming —… → …
  • Adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology
  • SKILL.md covers RULES — Follow these with no…, Subscription Pattern, Broadcasting from Contexts and Topic Naming Conventions, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Phoenix Pubsub Patterns is an agent skill from j-morgan6/elixir-phoenix-guide. Use when adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology, topic naming, handleinfo message handling.

Its SKILL.md is about 1.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Event-driven systems and LLM observability. The licence is MIT.

When your agent uses it

  • Adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology
  • Handleinfo message handling

Example prompts

  • “/phoenix-pubsub-patterns”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Always guard subscriptions with if connected?(socket) — the disconnected render runs in a separate short-lived process; subscribing there…
  2. Broadcast from contexts, not LiveViews — keeps real-time logic in the business layer; LiveViews only subscribe and react
  3. Use consistent topic naming — "resource:id" for specific resources, "resource:action" for collection-wide events
  4. Handle PubSub messages in handle_info/2 — never in handle_event/3; PubSub messages are process messages, not client events
  5. Prefer update/3 when the new value derives from the old — update(socket, :posts, &[post | &1]) reads better than reaching into…
  6. Test PubSub by calling context functions and asserting LiveView updates — don't test PubSub.broadcast directly; test the full cycle

What it can do on your machine

Read from SKILL.md and the folder at commit cdfddac. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are elixir).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Phoenix Pubsub Patterns loads about 1.8k tokens when it runs. Until then it costs about 38 tokens; SKILL.md has 273 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~38
When it runs · the whole SKILL.md, loaded when a task matches
~1.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from j-morgan6/elixir-phoenix-guide at commit cdfddac, republished under its MIT licence (© j-morgan6). 273 words, ~1,805 tokens.

Download SKILL.mdSave it as .claude/skills/phoenix-pubsub-patterns/SKILL.md (or your agent's skills folder).
name
phoenix-pubsub-patterns
description
Use when adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology, topic naming, handle_info message handling.
file_patterns
**/*_live.ex, **/*_live/*.ex, **/contexts/**/*.ex
auto_suggest
true

Phoenix PubSub Patterns

RULES — Follow these with no exceptions

  1. Always guard subscriptions with if connected?(socket) — the disconnected render runs in a separate short-lived process; subscribing there is wasted work, not a duplicate (LiveView mounts twice: once static, once connected)
  2. Broadcast from contexts, not LiveViews — keeps real-time logic in the business layer; LiveViews only subscribe and react
  3. Use consistent topic naming — "resource:id" for specific resources, "resource:action" for collection-wide events
  4. Handle PubSub messages in handle_info/2 — never in handle_event/3; PubSub messages are process messages, not client events
  5. Prefer update/3 when the new value derives from the old — update(socket, :posts, &[post | &1]) reads better than reaching into socket.assigns manually. Both are equivalent; this is style, not safety.
  6. Test PubSub by calling context functions and asserting LiveView updates — don't test PubSub.broadcast directly; test the full cycle

Subscription Pattern

Subscribe in mount/3 only when connected. The static render doesn't need real-time updates.

elixir
defmodule MyAppWeb.PostLive.Index do
  use MyAppWeb, :live_view

  @impl true
  def mount(_params, _session, socket) do
    if connected?(socket) do
      Phoenix.PubSub.subscribe(MyApp.PubSub, "posts")
    end

    {:ok, assign(socket, :posts, list_posts())}
  end

  @impl true
  def handle_info({:post_created, post}, socket) do
    {:noreply, update(socket, :posts, fn posts -> [post | posts] end)}
  end

  @impl true
  def handle_info({:post_updated, post}, socket) do
    {:noreply,
     update(socket, :posts, fn posts ->
       Enum.map(posts, fn
         p when p.id == post.id -> post
         p -> p
       end)
     end)}
  end

  @impl true
  def handle_info({:post_deleted, post}, socket) do
    {:noreply,
     update(socket, :posts, fn posts ->
       Enum.reject(posts, &(&1.id == post.id))
     end)}
  end
end

Broadcasting from Contexts

Broadcast after successful database operations. The context owns the business logic — LiveViews are just subscribers.

elixir
defmodule MyApp.Blog do
  alias MyApp.Blog.Post
  alias MyApp.Repo

  def create_post(attrs) do
    %Post{}
    |> Post.changeset(attrs)
    |> Repo.insert()
    |> broadcast(:post_created)
  end

  def update_post(%Post{} = post, attrs) do
    post
    |> Post.changeset(attrs)
    |> Repo.update()
    |> broadcast(:post_updated)
  end

  def delete_post(%Post{} = post) do
    post
    |> Repo.delete()
    |> broadcast(:post_deleted)
  end

  # Only broadcast on success
  defp broadcast({:ok, post}, event) do
    Phoenix.PubSub.broadcast(MyApp.PubSub, "posts", {event, post})
    {:ok, post}
  end

  defp broadcast({:error, changeset}, _event) do
    {:error, changeset}
  end
end

Topic Naming Conventions

Use a consistent naming scheme so subscribers know what to expect.

elixir
# Collection-wide — all posts
topic = "posts"
# Events: {:post_created, post}, {:post_updated, post}, {:post_deleted, post}

# Specific resource — one post
topic = "posts:#{post.id}"
# Events: {:post_updated, post}, {:post_deleted, post}, {:comment_added, comment}

# User-scoped — all activity for a user
topic = "users:#{user.id}"
# Events: {:notification, notification}, {:message_received, message}
Subscribing to Specific Resources
elixir
@impl true
def mount(%{"id" => id}, _session, socket) do
  post = Blog.get_post!(id)

  if connected?(socket) do
    Phoenix.PubSub.subscribe(MyApp.PubSub, "posts:#{post.id}")
  end

  {:ok, assign(socket, :post, post)}
end

Scoped Broadcasting

When events should only reach specific users or resources:

elixir
# In context — broadcast to resource-specific topic
defp broadcast({:ok, comment}, :comment_added) do
  Phoenix.PubSub.broadcast(
    MyApp.PubSub,
    "posts:#{comment.post_id}",
    {:comment_added, comment}
  )
  {:ok, comment}
end

# In context — broadcast to user-specific topic
defp broadcast({:ok, notification}, :new_notification) do
  Phoenix.PubSub.broadcast(
    MyApp.PubSub,
    "users:#{notification.user_id}",
    {:new_notification, notification}
  )
  {:ok, notification}
end

Deriving New Assigns with update/3

Use update/3 when the new value derives from the old one — it reads better than reaching into socket.assigns manually. Functionally, assign/3 and update/3 produce identical results here; this is a style preference, not a correctness rule.

elixir
# Equivalent — reaches into socket.assigns directly
def handle_info({:post_created, post}, socket) do
  {:noreply, assign(socket, :posts, [post | socket.assigns.posts])}
end

# Preferred — update/3 reads better when deriving from the old value
def handle_info({:post_created, post}, socket) do
  {:noreply, update(socket, :posts, fn posts -> [post | posts] end)}
end

# Good — update a specific item in the list
def handle_info({:post_updated, updated_post}, socket) do
  {:noreply,
   update(socket, :posts, fn posts ->
     Enum.map(posts, fn
       post when post.id == updated_post.id -> updated_post
       post -> post
     end)
   end)}
end

# Good — remove an item from the list
def handle_info({:post_deleted, deleted_post}, socket) do
  {:noreply,
   update(socket, :posts, fn posts ->
     Enum.reject(posts, &(&1.id == deleted_post.id))
   end)}
end

Testing PubSub

Test the full cycle: call a context function, assert the LiveView updates. Don't test PubSub.broadcast in isolation.

elixir
describe "real-time updates" do
  test "new post appears in list", %{conn: conn} do
    user = user_fixture()
    conn = log_in_user(conn, user)

    {:ok, lv, _html} = live(conn, ~p"/posts")

    # Create a post through the context (triggers broadcast)
    {:ok, post} = Blog.create_post(%{title: "New Post", user_id: user.id})

    # Assert the LiveView received and rendered the update
    assert render(lv) =~ "New Post"
  end

  test "updated post reflects changes", %{conn: conn} do
    user = user_fixture()
    post = post_fixture(user_id: user.id, title: "Original")
    conn = log_in_user(conn, user)

    {:ok, lv, _html} = live(conn, ~p"/posts")
    assert render(lv) =~ "Original"

    {:ok, _post} = Blog.update_post(post, %{title: "Updated"})

    assert render(lv) =~ "Updated"
    refute render(lv) =~ "Original"
  end

  test "deleted post disappears from list", %{conn: conn} do
    user = user_fixture()
    post = post_fixture(user_id: user.id, title: "To Delete")
    conn = log_in_user(conn, user)

    {:ok, lv, _html} = live(conn, ~p"/posts")
    assert render(lv) =~ "To Delete"

    {:ok, _post} = Blog.delete_post(post)

    refute render(lv) =~ "To Delete"
  end
end

See phoenix-liveview-essentials skill for LiveView lifecycle patterns. See testing-essentials skill for comprehensive testing patterns.

© j-morgan6, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/phoenix-pubsub-patterns of j-morgan6/elixir-phoenix-guide.

Open the folder on GitHubat commit cdfddac

Compare with similar skills

Phoenix Pubsub Patterns next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Phoenix Pubsub Patterns compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Phoenix Pubsub Patterns this skillj-morgan6/elixir-phoenix-guide166—~1.8kAutomated safety check: PassMIT
Absinthe SubscriptionsTheBushidoCollective/han198—~875Automated safety check: PassCustom licence
Phoenixericrisco/rsc-harness167—~2.9kAutomated safety check: NotesMIT
Phoenix Contextsoliver-kriska/claude-elixir-phoenix565—~841Automated safety check: PassMIT
Databuddydatabuddy-analytics/Databuddy1.2k—~2.1kAutomated safety check: PassAGPL-3.0
Phoenix GraphqlArize-ai/phoenix12k—~2.2kAutomated safety check: PassCustom licence

Similar skills

  • Absinthe Subscriptions

    TheBushidoCollective/han

    A skill your agent uses when implementing real-time GraphQL subscriptions with Absinthe.

    198 GitHub stars~875 tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed
  • Phoenix

    ericrisco/rsc-harness

    A skill your agent uses when building an Elixir web app with Phoenix — contexts, Ecto schemas, changesets and migrations, LiveView, channels and PubSub, the generators, and the boundary between…

    167 GitHub stars~2.9k tokensUpdated yesterday
    AI & LLM EngineeringAuto-check: notes
  • Phoenix Contexts

    oliver-kriska/claude-elixir-phoenix

    Phoenix context design — creating/splitting contexts, Scope (1.8+), Ecto.Multi, PubSub, routers, plugs, controllers.

    565 GitHub stars~841 tokensUpdated 3 days ago
    AI & LLM EngineeringAuto-check passed
  • Databuddy

    databuddy-analytics/Databuddy

    Integrate Databuddy analytics using the SDK, REST API, or MCP.

    1.2k GitHub stars~2.1k tokensUpdated yesterday
    Backend & APIsAuto-check passed
  • Phoenix Graphql

    Arize-ai/phoenix

    Write efficient GraphQL queries against the Phoenix API. An agent skill from Arize-ai/phoenix.

    12k GitHub stars~2.2k tokensUpdated today
    Backend & APIsAuto-check passed
  • Phoenix REST API

    Arize-ai/phoenix

    REST API development for Phoenix. An agent skill from Arize-ai/phoenix.

    12k GitHub stars~286 tokensUpdated today
    Backend & APIsAuto-check passed

More from j-morgan6/elixir-phoenix-guide

All 19 skills in this repo
  • Code Quality

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when refactoring for duplication, complexity, or dead code — includes the plugin's on-demand analysis scripts.

    166 GitHub stars~1.4k tokensUpdated 3 mo ago
    Auto-check passed
  • Deployment Gotchas

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when preparing releases or deployment config — runtime.exs vs compile-time config, release migrations, PHXHOST/PHXSERVER, assets, health checks.

    166 GitHub stars~2.6k tokensUpdated 3 mo ago
    Auto-check passed
  • Ecto Changeset Patterns

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when a resource needs multiple changesets (registration vs update), conditional validation, field transforms, or uniqueness validation — changeset composition.

    166 GitHub stars~2.1k tokensUpdated 3 mo ago
    Auto-check passed
  • Ecto Essentials

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when defining schemas, writing queries, or creating migrations — schema design, Repo usage, indexes, query composition.

    166 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed
  • Ecto Nested Associations

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when a form or operation manages parent and child records together — castassoc/castembed, onreplace, Ecto.Multi across tables, FK cascade design.

    166 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed
  • Elixir Essentials

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when writing or refactoring core Elixir — pattern matching, case/cond/with, pipes, {:ok, }/{:error, } contracts.

    166 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed

Questions about Phoenix Pubsub Patterns

What does Phoenix Pubsub Patterns do?

A skill your agent uses when adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology, topic naming, handleinfo message handling. Phoenix Pubsub Patterns is an agent skill from j-morgan6/elixir-phoenix-guide.PubSub — subscribe/broadcast topology, topic naming, handleinfo message handling.

When should I use Phoenix Pubsub Patterns?

Phoenix Pubsub Patterns fits situations like: adding real-time updates via Phoenix.PubSub — subscribe/broadcast topology; handleinfo message handling.

How do I install Phoenix Pubsub Patterns in Claude Code?

Run `npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-pubsub-patterns -a claude-code`. Or copy the skill folder (skills/phoenix-pubsub-patterns in j-morgan6/elixir-phoenix-guide) into .claude/skills/phoenix-pubsub-patterns in your project. Claude Code loads it when a task matches its description.

How do I install Phoenix Pubsub Patterns in Codex?

Run `npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-pubsub-patterns -a codex`. Or copy the skill folder (skills/phoenix-pubsub-patterns in j-morgan6/elixir-phoenix-guide) into .agents/skills/phoenix-pubsub-patterns in your project. Codex loads it when a task matches its description.

Can I use Phoenix Pubsub Patterns in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-pubsub-patterns -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/phoenix-pubsub-patterns, .gemini/skills/phoenix-pubsub-patterns, .github/skills/phoenix-pubsub-patterns and .opencode/skills/phoenix-pubsub-patterns in your project.

What does Phoenix Pubsub Patterns need to run?

SKILL.md names no scripts, command-line tools or credentials: Phoenix Pubsub Patterns is instructions for the agent only.

Does Phoenix Pubsub Patterns access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Phoenix Pubsub Patterns safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Phoenix Pubsub Patterns use?

Phoenix Pubsub Patterns is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Phoenix Pubsub Patterns use?

About 1.8k tokens (SKILL.md is roughly 7.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Phoenix Pubsub Patterns?

Skills that share tags, products or a category with Phoenix Pubsub Patterns: Absinthe Subscriptions (TheBushidoCollective/han, 198 stars), Phoenix (ericrisco/rsc-harness, 167 stars), Phoenix Contexts (oliver-kriska/claude-elixir-phoenix, 565 stars) and Databuddy (databuddy-analytics/Databuddy, 1.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Phoenix Pubsub Patterns?

j-morgan6 (a GitHub user) maintains it in j-morgan6/elixir-phoenix-guide, which has 166 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on July 6, 2026.

Source: j-morgan6/elixir-phoenix-guide on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.