rd-session-doc

Generate structured session work logs documenting changes, decisions, and known issues.

Updated Jan 29, 2026
One-click install
npx skills add https://github.com/Sky9th/RedDust-Abandon --skill rd-session-doc-sky9th
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: rd-session-doc
Source: https://github.com/Sky9th/RedDust-Abandon/tree/main/.claude/skills/rd-session-doc
Command: npx skills add https://github.com/Sky9th/RedDust-Abandon --skill rd-session-doc-sky9th

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Development sessions produce decisions and context that fade quickly; this Skill archives each session into a standardized Markdown log so developers can resume work days or weeks later without losing the reasoning behind changes. ## Core Features & Use Cases - Five-Section Template Enforcement: Every session doc contains Background, Changes, Decisions, Known Issues, and Cross-References sections with strict content requirements. - Mechanical Quality Gates: Validates minimum length, filename format (YYYY-MM-DD-topic.md in kebab-case ASCII), date accuracy, single-topic focus, and merge suggestions against existing session files. - Decision Tracking with Alternatives: Requires each decision to list at least one rejected alternative and the reason for rejection, preserving design rationale. - Use Case: After a coding session that refactored the animation pipeline, invoke this Skill to produce a dated session file in .agent/sessions/ capturing what changed, why, remaining issues, and links to related plans and tech docs. ## Quick Start Archive this session's work by writing a session doc following the rd-session-doc template.

Frequently Asked Questions about rd-session-doc

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a development session log?▼

A session log records what changed, why, decisions made, and known issues at the end of a work session. This Skill generates one using a fixed five-section template: Background, Changes, Decisions, Known Issues, and Cross-References, saved to .agent/sessions/.

What should a session doc filename look like?▼

Filenames must follow YYYY-MM-DD-topic.md in kebab-case ASCII only, such as 2026-06-20-grip-switching.md. No uppercase letters, Chinese characters, spaces, or special characters other than hyphens are allowed, and the year must match the actual session date.

When should I not create a session doc?▼

Skip session docs for pure Q&A or exploration sessions that produced no artifacts, and for sessions under five minutes with no meaningful output. Sessions under 15 lines of content should be merged into the next session rather than written as thin standalone files.

Why must decisions list rejected alternatives?▼

Recording rejected alternatives preserves the reasoning behind each choice so future developers understand why other approaches were not taken. Each decision entry must name at least one alternative and the specific reason it was rejected.

Can one session doc cover multiple unrelated topics?▼

No, the single-topic rule warns when a session touches more than three unrelated domains and refuses when splitting would produce better documentation. Mixed topics like plan rewrites plus asset cleanup should become separate session files.