# Ledgerline > Decision provenance and shared context for AI-assisted product development across every role — product, design, engineering, QA, release, marketing, and post-release analysis. Use this skill whenever the user wants to set up or use Ledgerline; start a work session on a product or project; create, load, or update a context package, decision ledger, org context, or product context; commit or capture decisions from a session; do a phase handoff; add a new product or project to their portfolio; or asks "what was decided and why" about a project. Also trigger when the user mentions ledgerline, decision ledger, context commit, context package, session start, or handoff — and proactively offer a ledger entry whenever a meaningful decision (with alternatives and tradeoffs) crystallizes mid-conversation, even if the user doesn't ask. - Skill: `jasonholderness-bl/ledgerline` (Agent Skill, multi-file: 18 files) - Install (CLI): `npx skillmds@latest add jasonholderness-bl/ledgerline` - Raw SKILL.md: https://api.skillmd.com/api/skills/jasonholderness-bl/ledgerline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: JasonHolderness-bl (https://skillmd.com/u/jasonholderness-bl) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/jasonholderness-bl/ledgerline --- # Ledgerline Ledgerline keeps the *why* behind decisions traveling with a project — through all nine phases of product development (ideation → scoping → design → stories → architecture → build → QA/release → marketing → post-release analysis) and across every person's AI sessions. The core artifact is a **decision ledger**: an append-only record of decisions, the alternatives that were rejected, the rationale and tradeoffs, and the constraints that forced them. Around it sits a small context package per project, a context per product, and one org context. ## Operations Determine which operation the user wants, then read ONLY that operation's reference file and follow it exactly: | Operation | User intent sounds like | Reference file | |---|---|---| | `init` | "Set up Ledgerline", "configure the shared store", first-ever use | `references/init.md` | | `new-product` | "Add a product", "set up context for [product/client]" | `references/new-product.md` | | `new-project` | "New project/feature", "start a context package for X" | `references/new-project.md` | | `start-session` | "Start a session", "I'm working on X today", "load context for X", "catch me up" | `references/start-session.md` | | `commit` | "Commit context", "log these decisions", "capture this session", end of a working session | `references/commit.md` | | `handoff` | "Handoff", "I'm passing this to [role/phase]", phase transition | `references/handoff.md` | If the user's intent is ambiguous, ask which operation they want — don't guess between `commit` and `handoff` (handoff includes a commit plus a current-state rewrite). ALL operations require knowing where the shared store lives. Read `references/backends.md` FIRST in every operation to locate the config and resolve the backend. If no config can be found, offer to run `init`. ## The context model (three-tier cascade) ``` / ledgerline-config.md ← backend, paths, conventions org-context.md ← how the company works (process, DoD, standing tradeoffs) registry.md ← the product picker: every product, one line each products// product-context.md ← ICP, positioning, voice, stack, metrics for THIS product projects// ← the six-file project package 00-brief.md 01-decisions.md 02-scope.md 03-current-state.md 04-open-questions.md 05-glossary.md ``` **Resolution cascade:** org-context loads first, product-context overrides it where they conflict, project files sit on top. Client-owned products may fully replace org positioning and voice while still inheriting org process. When contexts conflict, the more specific tier wins — and say so if it matters to the answer. ## Core rules (apply during EVERY operation and every session where Ledgerline context is loaded) 1. **The ledger is settled.** Decisions with status Accepted are not relitigated. If a suggestion conflicts with one, say so explicitly, cite the decision ID (e.g., "this conflicts with D-014"), and ask whether the user wants to formally supersede it — never silently propose a rejected alternative. 2. **Open questions are not answers.** Before answering anything the team may not have decided, check `04-open-questions.md`. If the topic is listed there, flag it as undecided instead of answering as if settled. 3. **Proactive capture.** When a conversation produces a real decision — a choice between alternatives with a rationale — offer to record it: "That sounds like a ledger entry. Want me to draft it?" Offer once per decision; don't nag. This applies in ANY session where Ledgerline context is loaded, not just during `commit`. 4. **Distillation, not transcripts.** The bar for a ledger entry: would someone downstream make a worse decision without knowing this? Exploration without commitment is not a decision. 5. **Canonical names.** Use the terms in `05-glossary.md`. Never invent a synonym for something the glossary names. 6. **Interview, don't assign homework.** Whenever a template needs filling, interview the user conversationally — a few questions at a time, adapting to their answers — and generate the completed artifact. Never hand the user a blank template to edit. 7. **Sensitive content stays out.** No customer-identifying details, compensation/personnel/legal matters, credentials, or security specifics in any Ledgerline artifact. If the user supplies them, anonymize ("a mid-market logistics customer") and say you did. 8. **Ledger entries are ADR-compatible.** Sequential IDs (D-001…), statuses Proposed | Accepted | Deprecated | Superseded by D-###, append-only, supersede-don't-edit. Teams with existing ADRs can import them as ledger entries unchanged. ## Templates Blank templates live in `assets/templates/`. They are raw material for interviews — read the relevant template to know what fields to elicit, then generate the filled version. The project package templates are under `assets/templates/project/`.