engineering-ledger
Skill0 starsChanged 56 days agoMITView on GitHub
Maintain a progressive engineering thought-process ledger (phases, attack plans, tactical decisions, lessons learned). Read before non-trivial work; append before ending a session. Use when starting features, debugging hard problems, finishing sprints, or when the user asks to capture reasoning, trade-offs, or lessons.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- craft-adoptSkill
- craft-promoteSkill
- product-managementSkill
- using-craftSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
After a bug, failed approach, or benchmark surprise
- Very specific: line 52
Read INDEX.md — current phase, last session summary, open questions.
- Very specific: line 53
Read active AP-### in attack-plans.md if one exists.
- Distinctive: line 55
If conflict: stop, cite DR id, ask user how to proceed (respect / supersede).
- Distinctive: line 57
Do not skip because "I remember the context."
- Very specific: line 143
Create ADR in project's docs/decisions/.
- Distinctive: line 161
Before claiming ledger work complete:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Engineering Ledger
Capture how the project was built — not just the diff. Code shows what; this ledger shows why, what we rejected, and what we learned.
When to use
- Starting a feature, sprint, or phase
- Choosing between approaches (libraries, architecture seams, optimization targets)
- After a bug, failed approach, or benchmark surprise
- End of session / before branch switch / before handoff
- User says: "log this decision", "capture lessons", "update the ledger", "what did we learn"
When NOT to use
- Trivial one-line fixes with no design choice
- Pure questions with no project change
- Duplicating an ADR — link to ADR instead (see references/adr-vs-ledger.md)
Ledger location (default)
docs/engineering-ledger/ in the target project (not in the craft repo):
| File | ID prefix | Purpose |
INDEX.md | — | Timeline + active phase + links |
phases.md | PH- | North-star phase status and gates |
attack-plans.md | AP- | Component attack strategy per unit of work |
decisions.md | DR- | Tactical decisions (reversible) |
lessons.md | LL- | Blameless lessons, failed hypotheses |
Scaffold from templates/ if missing.
Phase routing
For which upstream skill to load after the read loop, follow using-craft (reference-only router). Craft never copies Addy skill bodies.
Read loop (mandatory before non-trivial work)
- Read
INDEX.md— current phase, last session summary, open questions. - Read active
AP-###inattack-plans.mdif one exists. - Scan
decisions.mdActive index for conflicts with the planned approach. - If conflict: stop, cite DR id, ask user how to proceed (respect / supersede).
Do not skip because "I remember the context."
Write loop (mandatory before ending substantive work)
- Attack plan — if new unit of work: add
AP-###(goal, components, order, done-when). - Decision — if you chose between options: append
DR-###(see template). - Lesson — if something failed, surprised, or generalized: append
LL-###with Scope (project|universal) and Promotion candidate. - Phase — if a gate cleared: update
phases.mdstatus + evidence (tests, benchmark, ADR link). - INDEX — one paragraph: what happened, what's next, blockers.
Append only. Never delete entries. Supersede with Supersedes: DR-### / Superseded-by: DR-###.
Entry formats
Full templates: references/entry-templates.md
Decision (DR) — minimum fields
### DR-003 — Batched benchmark ingest at 128
- **Date:** 2026-09-13
- **Status:** accepted
- **Context:** 10k BEIR ingest took ~13 min one-doc-at-a-time
- **Options:** (1) batch embed+upsert (2) --fast mock mode (3) both
- **Decision:** batch_size=128 + optional --fast for 100k+
- **Rationale:** ONNX dispatch overhead dominated; batching 160× Qdrant round-trips
- **Tradeoffs accepted:** Benchmark ingest path bypasses dedup at scale
- **Links:** commit 2ea19cb, ADR-013Lesson (LL) — minimum fields
### LL-002 — BEIR doc_id must survive ingest
- **Date:** 2026-09-13
- **Status:** resolved
- **Scope:** universal
- **Promotion candidate:** yes
- **Category:** correctness
- **What happened:** 0% HitRate@5 on SciFact — hashed doc_id broke qrel match
- **Root cause:** ingest_text hashed source_uri, not BEIR id
- **Fix:** pass doc_id through ingest_text; relevant_sources fallback
- **General lesson:** Benchmark labels must match indexed metadata, not convenience hashesScope: project = stays in this repo. universal = candidate for craft-promote (see references/promotion-criteria.md).
Attack plan (AP)
### AP-001 — Sample corpus + rerank metrics
- **Status:** done
- **Goal:** Prove full pipeline quality story on real formats
- **Components:** PDF/DOCX sample, rerank HitRate@5, config defaults, CI gate
- **Order:** corpus → rerank metrics → config → CI
- **Done when:** 93 tests green, README table updatedPhase model
See references/phase-model.md. Default gates:
| Phase | Gate (examples) |
| Shape | Problem framed, AP written, out-of-scope listed |
| Spec / ADR | ADR or spec exists for forks |
| Build | Tests green for touched seams |
| Verify | Benchmark or smoke evidence recorded in ledger |
| Ship | CI green, ledger INDEX updated |
Promotion to ADR
Promote DR → ADR when any of:
- Reversal would require migration or multi-day rework
- Choice affects multiple teams or external contracts
- User explicitly requests ADR
Create ADR in project's docs/decisions/; link both ways.
Anti-patterns
| Don't | Do instead |
| Dump chat transcripts into the ledger | Curated DR/LL with ids |
| Rewrite old entries | Append superseding DR |
| Skip ledger because ADRs exist | ADRs = forks; ledger = narrative |
| Log every file edit | Log choices with alternatives |
| Start coding before read loop | Read INDEX + active AP first |
Verification
Before claiming ledger work complete:
- INDEX reflects current state
- New entries have sequential ids
- LL entries include Scope; universal lessons mark Promotion candidate
- Active index sections updated at top of decisions/lessons files
- Links to commits, ADRs, or PRs where applicable
- Phase status in
phases.mdmatches evidence (tests, benchmark, CI)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

