New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Liveblog Dev

by liveblog in liveblog/liveblog

Run a local Liveblog development environment. An agent skill from liveblog/liveblog.

AGPL-3.0Auto-check passedDevOps & Cloud

Install Liveblog Dev

skills CLI
$ npx skills add liveblog/liveblog --skill liveblog-dev -a claude-code

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

GitHub CLI
$ gh skill install liveblog/liveblog liveblog-dev --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/liveblog/liveblog.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/liveblog-dev .claude/skills/liveblog-dev && 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
liveblog-dev
GitHub stars
119
Token cost
~1.9k tokens
SKILL.md length
1,007 words
Files
1
Skills in repo
1
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Run a local Liveblog development environment. An agent skill from liveblog/liveblog.

  • Works in 3 steps: Pick the mode → Confirm only when it matters → Run the script and hand off
  • Wants to do any of: — set me up
  • SKILL.md covers The golden rule: relay, don't…, Pre-approved commands, Workflow and Known issue: MongoDB fails to…, plus 1 more section
  • Calls docker

What it does

Liveblog Dev is an agent skill from liveblog/liveblog. Run a local Liveblog development environment. Wraps the dev scripts under scripts/dev/ (setup, up, down) so someone can bring the app up, stop it, or check its status without knowing the Docker / honcho / webpack commands underneath. Invoke when the user wants to do any of: — "set me up", "first-time setup", "I just cloned this, get me running" — "start liveblog", "run the app locally", "spin up the dev environment" — "stop liveblog", "shut down the local environment" — "is it running?", "what's the status of the…

Its SKILL.md is about 1.9k 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 DevOps & Cloud, covering Test generation and Containers. It works with Docker, webpack, JavaScript and Python. The repository describes itself as: Sourcefabric's Live Blog is an open source web app that enables journalists to provide immediate and ongoing coverage on rapidly evolving news events. The licence is AGPL-3.0.

When your agent uses it

  • Wants to do any of: — set me up
  • First-time setup
  • I just cloned this
  • Get me running — start liveblog

Example prompts

  • “set me up”
  • “first-time setup”
  • “I just cloned this, get me running”
  • “/liveblog-dev”

Requirements

  • Docker

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Pick the mode
  2. Confirm only when it matters
  3. Run the script and hand off

What it can do on your machine

Read from SKILL.md and the folder at commit 917f82f. 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

    Shell commands in SKILL.md call:

    • docker

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

  • Network

    No URLs in SKILL.md. Its commands use docker, which can reach the network depending on how they are called.

    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

Liveblog Dev loads about 1.9k tokens when it runs. Until then it costs about 178 tokens; SKILL.md has 1,007 words of instructions outside code blocks.

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

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 liveblog/liveblog at commit 917f82f, republished under its AGPL-3.0 licence (© liveblog). 1,007 words, ~1,896 tokens.

Download SKILL.mdSave it as .claude/skills/liveblog-dev/SKILL.md (or your agent's skills folder).
name
liveblog-dev
description
Run a local Liveblog development environment. Wraps the dev scripts under scripts/dev/ (setup, up, down) so someone can bring the app up, stop it, or check its status without knowing the Docker / honcho / webpack commands underneath. Invoke when the user wants to do any of: — "set me up", "first-time setup", "I just cloned this, get me running" — "start liveblog", "run the app locally", "spin up the dev environment" — "stop liveblog", "shut down the local environment" — "is it running?", "what's the status of the local stack?" Do not invoke for: production deploys, running the test suites, or backend / client code changes. This skill only starts, stops, and reports on the local dev stack.

Running Liveblog locally

You are helping someone bring up (or stop, or check) a local Liveblog dev environment. The person may not be technical — they might be a PM or a designer who just needs the app running so they can click around. Talk in plain language: no Docker / honcho / webpack / pyenv jargon unless they raise it first. Explain what's happening, and hand off with "here's where you can click."

This skill does not write code, commit, or open PRs. Its whole job is to run one of three scripts and relay the result. The scripts own all behaviour and all error messages. Your job is to route the user's intent to the right script and pass its output along — never to reimplement its checks, guess at fixes, or quote error text back from memory.

The golden rule: relay, don't reinterpret

The scripts print their own errors with their own fix-it instructions (Docker not running, virtualenv missing, "run setup first", port conflicts, and so on). When a script fails:

  • Relay its message to the user verbatim and stop.
  • Do not try to install tooling, kill processes, edit files, or otherwise "fix" the underlying problem yourself.
  • Do not paraphrase or predict the error — show them what the script actually said.

If a script's output is confusing to a non-technical user, you may add a one-line plain-language summary underneath the verbatim output — but never replace it.

Pre-approved commands

The project ships .claude/settings.json with an allow-list covering the three dev scripts and a small set of read-only diagnostics (docker compose ps / logs, lsof on the relevant ports, curl health checks, and reading the log files under scripts/dev/.run/). Those run without a prompt.

If you want to run something not on that list, stop and ask the user first. Don't broaden what you do to work around a missing permission.

Workflow

1. Pick the mode

The user's message maps to one of four modes:

  • setup — first time, or after a reset. Runs ./scripts/dev/setup.sh.
  • up — start the stack for normal day-to-day use. Runs ./scripts/dev/up.sh.
  • down — stop the running stack. Runs ./scripts/dev/down.sh.
  • status — check what's currently running. Read-only, no script.

If the intent is genuinely ambiguous — for example "get me set up" from someone who already ran setup last week (do they want setup again, or just up?) — use AskUserQuestion with concrete options before doing anything.

2. Confirm only when it matters
  • up and status on a clear request: just do it. A plain "start liveblog" is its own confirmation — don't add a round-trip.
  • setup: confirm first (it's slow and does a lot). State plainly what it will do.
  • down: a normal stop is safe — proceed. But if the user asked for --wipe-data or --reinit (or said "wipe everything" / "fresh start" / "re-initialise"), spell out in plain language that this deletes their local data (or re-runs DB init) and confirm with AskUserQuestion before running it.

If the user would rather skip the confirmation next time, mention the slash commands exist: /liveblog-setup, /liveblog-up, /liveblog-down. Typing those is itself the confirmation.

3. Run the script and hand off

Run the one script for the chosen mode with the appropriate flags, and relay its output. Then close with a short, plain-language hand-off:

  • After up: "The app is running — open http://localhost:9000 and log in with admin / admin." Mention that stopping is /liveblog-down, and that the logs live under scripts/dev/.run/ if they want to watch progress.
  • After setup: "Setup's done. Next, start the app with /liveblog-up."
  • After down: relay the script's reminder that Docker itself keeps running after the stack stops.
Show full SKILL.md (418 more words)Show less
status mode (read-only)

No script, no confirmation. Report what's actually running using only allow-listed commands:

  • docker compose -f docker/docker-compose-dev-services.yml ps — are the backing services up?
  • lsof -i :5000 (or :5001 on macOS) — the API. lsof -i :5100 — the websocket. lsof -i :9000 — the client dev server.
  • curl the API (http://localhost:5000/api/, or :5001 on macOS) and the client (http://localhost:9000/) to confirm they answer.

Summarise in plain language: what's up, what's down, and (if nothing is running) that /liveblog-up will start it.

Known issue: MongoDB fails to restart on macOS

Some Mac setups hit a MongoDB failure that has nothing to do with the scripts themselves. docker logs mongodb shows:

WiredTiger error (1) ... file:WiredTiger.wt, connection: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted

Mongo starts fine the very first time (it's creating its files), then breaks on every restart after that (down + up, or up twice). This comes from how Docker Desktop shares the host filesystem into the container on macOS. MongoDB's WiredTiger storage engine can't reopen an existing data file across that bind mount. It doesn't happen on every machine, and it doesn't happen at all outside macOS.

Because it's not universal, don't change docker/docker-compose-dev-services.yml in the repo to work around it. Switching Mongo to a different volume type there would move the data path for everyone, including people it doesn't affect, and could quietly break their existing local data. If you hit this, fix it locally instead, on your own machine only:

  1. Edit your local (uncommitted) copy of docker/docker-compose-dev-services.yml: change the mongodb-3.4.23 service's volume from ../data/mongodb:/data/db to mongodb_data:/data/db, and add a top-level volumes: section with mongodb_data: under it. This moves Mongo's storage into a Docker-managed volume instead of the host bind mount, which sidesteps the file-sharing issue entirely.
  2. docker compose -f docker/docker-compose-dev-services.yml down to drop the old container, then re-run setup so the database gets initialised into the new volume.

Leave those two lines as local, uncommitted changes. Don't stage or commit them.

Notes

  • Ports. The API is on 5000 (5001 on macOS, where AirPlay holds 5000). The websocket is on 5100, the client on 9000. The scripts handle the port choice; you only need this for the lsof / curl checks in status mode.
  • Data. A normal down keeps the user's local blogs and users. Only --wipe-data deletes them — treat it as destructive.
  • Don't start Docker for the user. If a script says Docker isn't running, ask them to start it; don't try to start it yourself.
  • When a script genuinely breaks (crashes, prints something the fix-it text doesn't cover): relay it verbatim and stop. Don't paper over it.

© liveblog, AGPL-3.0. 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 .claude/skills/liveblog-dev of liveblog/liveblog.

Open the folder on GitHubat commit 917f82f

Compare with similar skills

Liveblog Dev 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.

Liveblog Dev compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Liveblog Dev this skillliveblog/liveblog119—~1.9kAutomated safety check: PassAGPL-3.0
Env Troubleshoot312362115/claude107—~900Automated safety check: WarnMIT
Debug CIweb-infra-dev/rslint461—~2.8kAutomated safety check: PassMIT
Minimegasandia-minimega/minimega160—~3.2kAutomated safety check: PassGPL-3.0-only
Unraiddinglebear-ai/unraid135—~5.4kAutomated safety check: NotesMIT
Generate Nemo Gym Envadithya-s-k/FineEnvs456—~2.1kAutomated safety check: PassApache-2.0

Similar skills

  • Env Troubleshoot

    312362115/claude

    环境排障技能：结构化排查开发环境问题. An agent skill from 312362115/claude.

    107 GitHub stars~900 tokensUpdated 4 mo ago
    DevOps & CloudAuto-check: warnings

  • Debug CI

    web-infra-dev/rslint

    Reproduce Linux CI failures locally using Docker when the same tests pass on the host, especially Go platform differences and VS Code extension tests requiring xvfb.

    461 GitHub stars~2.8k tokensUpdated today
    DevelopmentAuto-check passed

  • Minimega

    sandia-minimega/minimega

    This skill should be used when the user asks how to configure, run, automate, integrate, or troubleshoot minimega (VMs, namespaces, VLANs, clusters, miniccc, miniweb, command socket or Python API…

    160 GitHub stars~3.2k tokensUpdated 3 days ago
    DevOps & CloudAuto-check passed

  • Unraid

    dinglebear-ai/unraid

    This skill should be used when the user mentions Unraid, asks to check server health, monitor array or disk status, list or restart Docker containers, start or stop VMs, read system logs, check…

    135 GitHub stars~5.4k tokensUpdated 5 days ago
    DevOps & CloudAuto-check: notes

  • Generate Nemo Gym Env

    adithya-s-k/FineEnvs

    Builds a NeMo Gym (NVIDIA) variant of an RL environment. An agent skill from adithya-s-k/FineEnvs.

    456 GitHub stars~2.1k tokensUpdated yesterday
    DevOps & CloudAuto-check passed

  • Cosmos3 Env Troubleshoot

    NVIDIA/cosmos-framework

    Official

    Diagnose and fix Cosmos3 environment, installation, and runtime errors.

    559 GitHub stars~1.3k tokensUpdated today
    DevOps & CloudAuto-check: notes

Works with

Categories

Questions about Liveblog Dev

What does Liveblog Dev do?

Run a local Liveblog development environment. An agent skill from liveblog/liveblog. Liveblog Dev is an agent skill from liveblog/liveblog. Run a local Liveblog development environment.

When should I use Liveblog Dev?

Liveblog Dev fits situations like: wants to do any of: — set me up; first-time setup; I just cloned this; get me running — start liveblog.

How do I install Liveblog Dev in Claude Code?

Run `npx skills add liveblog/liveblog --skill liveblog-dev -a claude-code`. Or copy the skill folder (.claude/skills/liveblog-dev in liveblog/liveblog) into .claude/skills/liveblog-dev in your project. Claude Code loads it when a task matches its description.

How do I install Liveblog Dev in Codex?

Run `npx skills add liveblog/liveblog --skill liveblog-dev -a codex`. Or copy the skill folder (.claude/skills/liveblog-dev in liveblog/liveblog) into .agents/skills/liveblog-dev in your project. Codex loads it when a task matches its description.

Can I use Liveblog Dev 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 liveblog/liveblog --skill liveblog-dev -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/liveblog-dev, .gemini/skills/liveblog-dev, .github/skills/liveblog-dev and .opencode/skills/liveblog-dev in your project.

What does Liveblog Dev need to run?

Going by SKILL.md and its folder, Liveblog Dev needs the command-line tools its instructions call (docker). Our summary lists: Docker.

Does Liveblog Dev access the network?

SKILL.md contains no URLs. Its commands use docker, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Liveblog Dev 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 Liveblog Dev use?

Liveblog Dev is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Liveblog Dev use?

About 1.9k tokens (SKILL.md is roughly 7.6k 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 Liveblog Dev?

Skills that share tags, products or a category with Liveblog Dev: Env Troubleshoot (312362115/claude, 107 stars), Debug CI (web-infra-dev/rslint, 461 stars), Minimega (sandia-minimega/minimega, 160 stars) and Unraid (dinglebear-ai/unraid, 135 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Liveblog Dev?

liveblog (a GitHub organization) maintains it in liveblog/liveblog, which has 119 GitHub stars. The repository was last updated on October 7, 2026.

Source: liveblog/liveblog on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.