scribe

fangdev24's avatarfrom fangdev24

Institutional knowledge capture. Activates when discussing session wrap-up, documenting learnings, or preserving decisions for future reference.

0stars🔀0forks📁View on GitHub🕐Updated Jan 8, 2026

When & Why to Use This Skill

Scribe is a specialized Claude skill designed for institutional knowledge capture and automated documentation. It streamlines the process of preserving critical insights, architectural decisions (ADRs), technical patterns, and session summaries directly from development conversations, ensuring that valuable team intelligence is organized and searchable for future reference.

Use Cases

  • Documenting complex bug fixes and root cause analyses into a structured problems-solutions database to prevent recurring issues.
  • Recording Architectural Decision Records (ADRs) during design discussions to track technology choices, trade-offs, and context.
  • Capturing non-obvious 'gotchas' and hidden requirements discovered during implementation to reduce friction for other team members.
  • Generating comprehensive session summaries at the end of a workday to track accomplished tasks, blockers, and immediate next steps.
  • Formalizing reusable code patterns and best practices identified during development into a centralized pattern library.
namescribe
descriptionInstitutional knowledge capture. Activates when discussing session wrap-up, documenting learnings, or preserving decisions for future reference.

Scribe Skill - Knowledge Capture

This skill ensures valuable learnings are captured during development conversations.

Purpose

Prevent knowledge loss by capturing:

  • Problem solutions
  • Architecture decisions
  • Discovered patterns
  • Non-obvious gotchas
  • Session summaries

When to Activate

This skill should activate when:

  • User mentions "end of session" or "wrapping up"
  • A significant problem has been solved
  • An architecture decision has been made
  • A non-obvious gotcha has been discovered
  • User asks to "document" or "capture" something

Trigger Phrases

Trigger Action
"Let's wrap up" Suggest running /scribe
"Finally got it working" Offer to document the solution
"We should remember this" Offer to capture as knowledge
"That was tricky" Ask if it should be documented
"Decided to go with X" Offer to create decision record

Knowledge Categories

Problems & Solutions

Location: knowledge-base/problems-solutions/YYYY-MM-DD-description.md

Capture when:

  • An error was debugged
  • A workaround was found
  • A configuration issue was resolved

Template:

# Problem: {Title}

**Date**: {YYYY-MM-DD}
**Tags**: `{tag1}`, `{tag2}`

## Symptoms
{What was observed}

## Root Cause
{Why it happened}

## Solution
{How it was fixed}

## Prevention
{How to avoid in future}

Architecture Decisions (ADRs)

Location: knowledge-base/decisions/adr-NNN-description.md

Capture when:

  • Technology choice made
  • Architecture pattern chosen
  • Trade-off accepted

Template:

# ADR-{NNN}: {Title}

**Status**: {Proposed | Accepted | Deprecated}
**Date**: {YYYY-MM-DD}

## Context
{What prompted this decision?}

## Decision
{What was decided?}

## Consequences
### Positive
- {Benefit}

### Negative
- {Trade-off}

## Alternatives Considered
- {Alternative 1}: Rejected because {reason}

Patterns

Location: knowledge-base/patterns/pattern-description.md

Capture when:

  • A reusable approach discovered
  • A best practice identified
  • A code pattern works well

Template:

# Pattern: {Title}

**Category**: {Category}
**Tags**: `{tag1}`, `{tag2}`

## Problem
{What problem does this solve?}

## Solution
{The pattern}

## When to Use
{Applicable situations}

## Example
{Code or implementation example}

Gotchas

Location: knowledge-base/gotchas/gotcha-description.md

Capture when:

  • Something behaves unexpectedly
  • Documentation was misleading
  • Hidden requirement discovered

Template:

# Gotcha: {Title}

**Date**: {YYYY-MM-DD}
**Tags**: `{tag1}`, `{tag2}`

## What Happened
{The unexpected behaviour}

## Why
{Root cause or explanation}

## Workaround
{How to handle it}

Session Summaries

Location: knowledge-base/sessions/YYYY-MM-DD-session-summary.md

Capture at end of sessions:

  • What was accomplished
  • Blockers encountered
  • Next steps

Template:

# Session Summary: {Date}

## Accomplished
- {Task 1}
- {Task 2}

## Blockers
- {Blocker 1}

## Decisions Made
- {Decision 1}

## Next Steps
1. {Next step 1}
2. {Next step 2}

Usage

Manual Invocation

/scribe

Automatic Prompts

At natural breakpoints, the assistant may gently ask:

"Should I capture that solution/decision/gotcha for future reference?"

RAG Preparation

When capturing, format for future retrieval:

  • Use consistent markdown headings
  • Include searchable tags
  • Write self-contained entries
  • Use specific, technical terms

Directory Setup

Ensure these directories exist:

knowledge-base/
├── problems-solutions/
├── decisions/
├── patterns/
├── gotchas/
└── sessions/