Description

Generate narrative blog posts from AI coding session transcripts. Reads session files, selects sessions relevant to a topic, and produces an agent-narrated blog post about the human-agent collaboration. Supports builder's log, tutorial, and technical deep-dive styles.

README (SKILL.md)

DevLog Generator

Name: Devlog
Author: lordshashank

Generate narrative developer blog posts from human-agent coding session transcripts. The blog is written from the agent's first-person perspective — "I" is the agent, and the human developer is referred to as "my human."

Workflow

Phase 1: Understand the Request

Extract from the user's message:

Project — which codebase? ("eastore", "filecoin", "couponswap"). If unspecified, use the current working directory.
Topic/feature — what specifically? ("auth system", "dashboard", or the whole project). If unspecified, include all sessions.
Style — builder's log (default), tutorial, or technical deep-dive. Override only if the user explicitly asks.
Time range — "last week", "January sessions", or all (default).

Phase 2: Discover Sessions

Determine which platform to scan. Check references/platforms/ for supported platforms — each subdirectory is a platform. Auto-detect from the current environment, or from the user's request.

Load only the relevant platform directory. Each contains a reference file (storage schema, session paths, discovery instructions) and scripts (list-sessions.sh, read-session.sh). Never load all platform references upfront.

Run the platform's list-sessions.sh \x3Cproject> to scan for matching sessions, OR follow the discovery instructions in the platform reference file manually.

If the platform has no reference directory in references/platforms/, discover sessions manually — check the platform's data/config directories (e.g. ~/.local/share/, ~/.config/, ~/Library/), look for session storage files (JSONL, JSON, SQLite), and inspect the schema to extract the human-agent dialogue. Follow the same filtering principles from Phase 3.

Present the session index to the user for confirmation.

Phase 3: Select & Read

From the session index, determine which sessions are relevant to the user's topic. Read the full transcripts of selected sessions.

When reading transcripts, filter aggressively:

Keep:

User messages (text) — the human's intent, direction, corrections
Assistant messages (text) — the agent's reasoning, proposals, explanations
Tool call names + file paths — what was built
Error messages — struggles and debugging

Strip:

tool_result content bodies (raw file contents, grep output — 80-90% of token size)
System messages, usage metadata, compaction/summary entries
Full tool input arguments (keep name + file path only, not entire diffs)

Refer to the platform reference file loaded in Phase 2 for platform-specific field names and parsing details.

If filtered transcripts still exceed context, process per-session: generate per-session summaries, then synthesize across sessions. Prioritize the human-agent dialogue over tool call details.

Phase 4: Write the Blog

Read references/blog-writing-guide.md for the agent-narrated writing guide. This contains the voice definition, collaboration vocabulary, transcript extraction patterns, and blog structure.

Read the style-appropriate example from examples/:

examples/builders-log.md for builder's log style (default)
examples/tutorial.md for tutorial style
examples/technical.md for technical deep-dive style

Load assets/devlog-template.md as the blog skeleton. This is a starting structure, not a rigid format — adapt sections, reorder, merge, or drop headings based on what the session transcripts actually contain. A single-session blog may skip phase headings entirely. A heavily iterative session might expand "The Hard Part" into multiple sections. Let the story dictate the shape.

Generate the blog following the writing guide. The blog must be narrated by the agent in first person ("I"), referring to the human developer as "my human." When the session involves architecture, flows, or multi-component interactions, include Mermaid diagrams (```mermaid code blocks) to visualize the system — see the diagrams section in the writing guide for when and how.

Phase 5: Output

Write the blog to {project}-{topic}-devlog.md in the current working directory, or a user-specified path.

Report: title, word count, sessions included, time span covered, key files referenced.

Phase 6: Publish

Ask the user if they want to publish the blog online.
If yes, check references/publishing/ for supported platforms. Each subdirectory is a publishing platform.
Load the relevant platform's reference file for API details and requirements.
Check for required environment variables (e.g. HASHNODE_PAT, HASHNODE_PUBLICATION_ID for Hashnode).
If any are missing, tell the user what to set and how — e.g. export HASHNODE_PAT=... in ~/.zshrc or ~/.bashrc for future sessions. Ask the user to provide the values for the current session.
Cover image (optional): If you have image generation capabilities (e.g. an image generation tool or MCP server), generate a cover image that visually represents the blog's theme. Upload it to a publicly accessible URL and pass it to publish.sh with the --cover-image \x3Curl> flag. The image should be landscape-oriented (1200×630 or similar), visually relevant to the blog topic, and not contain text that duplicates the title. If you don't have image generation capabilities, skip this step — the blog publishes fine without a cover image.
Run the platform's publish.sh with the blog file path and title (plus --cover-image \x3Curl> if a cover image was generated).
Report the published post URL to the user.

Edge Cases

Scenario	Handling
No sessions found	Report which paths were scanned. Ask the user to check the project name or provide a path.
Ambiguous project match	List matching projects, ask the user to pick.
Single session	Simpler structure — no multi-session phase headings needed.
Huge session (5000+ lines)	Chunk per-turn-group, summarize sections, then synthesize.
Mixed platforms	Merge sessions from multiple platforms chronologically.
Subagent transcripts	Skip by default. Main session already references their results.
Current session	When the user says "what we just did" — use current session context directly, no JSONL needed.
Compacted sessions	Compaction does not delete data. Raw messages remain. Read everything, skip compaction/summary lines.
User declines to publish	Skip Phase 6 entirely. The blog file is already saved locally from Phase 5.

Resources

Platform References (load only the relevant one)

references/platforms/claude-code/ — Claude Code reference + scripts
- claude-code.md — Session paths, JSONL schema, discovery instructions
- list-sessions.sh — Scan Claude Code projects for matching sessions
- read-session.sh — Extract transcript from Claude Code JSONL
references/platforms/opencode/ — OpenCode reference + scripts
- opencode.md — Storage layout, JSON hierarchy, discovery instructions
- list-sessions.sh — Scan OpenCode projects for matching sessions
- read-session.sh — Extract transcript from OpenCode's JSON hierarchy
references/platforms/openclaw/ — OpenClaw reference + scripts
- openclaw.md — Session paths, JSONL schema, discovery instructions
- list-sessions.sh — Scan OpenClaw agents for matching sessions
- read-session.sh — Extract transcript from OpenClaw JSONL
references/platforms/codex/ — Codex reference + scripts
- codex.md — Rollout file format, JSONL schema, discovery instructions
- list-sessions.sh — Scan Codex rollout files for matching sessions
- read-session.sh — Extract transcript from Codex rollout JSONL
references/platforms/gemini-cli/ — Gemini CLI reference + scripts
- gemini-cli.md — JSON session format, SHA256 project hashing, discovery instructions
- list-sessions.sh — Scan Gemini CLI session files for matching projects
- read-session.sh — Extract transcript from Gemini CLI session JSON
references/blog-writing-guide.md — Voice, collaboration vocabulary, transcript extraction patterns, blog structure

Publishing Platforms (load only the relevant one)

references/publishing/hashnode/ — Hashnode publishing reference + script
- hashnode.md — GraphQL API endpoint, authentication, publishPost mutation, required env vars
- publish.sh — Publish a markdown file to Hashnode, outputs the post URL

Examples

examples/builders-log.md — Builder's log style output
examples/tutorial.md — Tutorial style output
examples/technical.md — Technical deep-dive output

Assets

assets/devlog-template.md — Blog skeleton template

Usage Guidance

This skill does what it says — it scans local AI coding session stores and generates an agent-narrated devlog, and can optionally publish to services like Hashnode — but review a few things before using it: - The package metadata claims 'no required binaries', but the included scripts require a POSIX shell and python3. Make sure python3/bash are available or expect the scripts to fail. - The skill will scan application data directories (e.g., ~/.local/share/opencode, ~/.gemini/tmp, ~/.config, ~/Library). These scans are necessary to discover session transcripts, but they can reveal other local data. If you have sensitive files in these locations, inspect the scripts first or run the skill in a controlled environment. - Publishing uses service credentials (e.g., HASHNODE_PAT). The SKILL.md instructs the agent to ask you for credentials if they're not set — do NOT paste secrets into the chat if you don't want them captured. Prefer exporting credentials into your shell environment (export HASHNODE_PAT=...) or using a secure secret injection mechanism rather than sending tokens in a message. - Review the publish.sh and any network-calling code before invoking publishing: confirm which endpoints are used and whether data (including any cover image URLs) will be uploaded to third-party servers. - The read-session scripts attempt to strip raw tool outputs, but transcripts themselves can contain secrets (API keys, tokens, file contents). Inspect a sample session output the skill proposes to include before publishing or uploading anywhere. If you want to proceed: review the referenced platform scripts and publish script locally, ensure you run this in a trustable environment, and never paste long-lived secrets into an untrusted chat. If the skill author can update metadata to declare required binaries and list the publishing env vars up front (and remove the prompt-to-paste guidance), that would substantially reduce the current concerns.

Capability Analysis

Type: OpenClaw Skill Name: devlog Version: 1.0.0 This skill is classified as suspicious due to its broad file system access and direct use of sensitive environment variables, even though these capabilities are ostensibly for its stated purpose. Specifically, `SKILL.md` instructs the agent to manually discover sessions by checking broad user directories (`~/.local/share/`, `~/.config/`, `~/Library/`), and `references/platforms/gemini-cli/list-sessions.sh` scans common development directories (`~`, `~/dev`, `~/projects`, etc.) up to three levels deep to find project roots. While the intent is to locate session data, the wide scope of these searches presents a significant risk for unintended data exposure if the agent were to misinterpret instructions or be prompted maliciously. Additionally, `references/publishing/hashnode/publish.sh` directly accesses `HASHNODE_PAT` and `HASHNODE_PUBLICATION_ID` from environment variables for publishing, a high-risk operation, despite `SKILL.md` instructing the agent to prompt the user if these are missing.

Capability Assessment

ℹ Purpose & Capability

The skill's name/description (generate blog posts from coding session transcripts) aligns with the provided scripts and examples: platform-specific list/read scripts, templates, and a publish script. However the registry metadata claims no required binaries/env vars while many included scripts declare or implicitly require python3 and a POSIX shell (bash). Publishing support expects platform credentials (e.g., HASHNODE_PAT) even though requires.env is empty — an inconsistency between declared requirements and actual runtime needs.

⚠ Instruction Scope

SKILL.md instructs the agent to discover and read session storage across multiple platform paths (e.g., ~/.local/share, ~/.gemini/tmp, ~/.config, ~/Library) and to run platform list/read scripts. That is coherent for the stated goal, but the discovery steps can scan broad areas of the user's home tree and read many app data files. The skill attempts to strip large tool outputs, but the runtime instructions also say to 'ask the user to provide values for the current session' when publishing — which may prompt users to paste secrets into chat. This credential-handling guidance is risky and under-specified (no secure ephemeral ingestion mechanism is described).

ℹ Install Mechanism

There is no install spec (instruction-only), which reduces install-time risk. But code files (shell scripts that exec python3) are included and intended to be executed at runtime. The absence of declared required binaries (metadata lists none) conflicts with the scripts' internal 'Requires: python3' comments and shebangs — the agent will need a shell + python3 available for these scripts to work.

⚠ Credentials

Declared requires.env is empty, yet the publishing flow references service credentials (e.g., HASHNODE_PAT, HASHNODE_PUBLICATION_ID) and the included publish.sh likely reads env vars or expects secrets. The skill instructs the agent to tell the user how to export env vars and to ask the user for values during the session — this encourages users to paste secrets into the chat/session. Requesting publishing credentials is proportionate to the publishing feature, but the lack of explicit declaration in the registry metadata and the guidance to input secrets in-session are concerning.

✓ Persistence & Privilege

The skill does not request always:true, does not modify other skills, and has no install step that writes system-wide configuration. It reads user files but does not request permanent elevated presence. Autonomous invocation is enabled by default but not combined with other high-risk factors here.

Version History

v1.0.0

Initial release of DevLog Generator. - Generate narrative developer blog posts from coding session transcripts, narrated by the agent. - Automatically scans supported platforms for session data and filters relevant sessions based on project, topic, style, and time range. - Aggressively filters transcript data to highlight human-agent collaboration and technical decisions. - Adapts blog structure and style (builder’s log, tutorial, or technical deep-dive) to match user preference and session content. - Supports publishing generated blogs to multiple online platforms with optional AI-generated cover images. - Includes detailed edge case handling for various data and publishing scenarios.

Metadata

Slug devlog

Version 1.0.0

License —

All-time Installs 1

Active Installs 1

Total Versions 1

Frequently Asked Questions

What is Devlog?

Generate narrative blog posts from AI coding session transcripts. Reads session files, selects sessions relevant to a topic, and produces an agent-narrated blog post about the human-agent collaboration. Supports builder's log, tutorial, and technical deep-dive styles. It is an AI Agent Skill for Claude Code / OpenClaw, with 1244 downloads so far.

How do I install Devlog?

Run "/install devlog" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Devlog free?

Yes, Devlog is completely free (open-source). You can download, install and use it at no cost.

Which platforms does Devlog support?

Devlog is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Devlog?

It is built and maintained by lordshashank (@lordshashank); the current version is v1.0.0.

More Skills

Devlog