Templates · Engineering
README template
Project overview, setup, usage and contributing
Start with this template →Sign in
Opens on reph with the template ready to start. No account needed; sign in to keep your document.
Filled example
The template filled in for a made-up company, so you can see what good looks like.
ledgerline
A small Node.js service that imports bank statement CSVs, categorizes each transaction, and posts the result to Northwind's finance warehouse. Built for the finance ops team.
Features
- Imports CSV statements from five bank formats, detected automatically.
- Categorizes transactions with editable rules in
rules/*.yaml, no code changes needed.
- Flags duplicates across overlapping statement periods before anything is posted.
- Posts clean batches to the warehouse and writes a reconciliation report per run.
Getting started
Prerequisites
- Node.js 20 or newer
- Docker, for the local Postgres used in tests
- A warehouse service account (ask #finance-eng for read-only dev credentials)
Installation
git clone git@github.com:northwind/ledgerline.git
cd ledgerline
npm install
cp .env.example .env
Usage
npm run dev
Import one statement and preview the result without posting anything:
npm run import -- --file samples/acme-bank-2026-08.csv --dry-run
The dry run prints a table of categorized transactions and any suspected duplicates. Drop --dry-run to post the batch.
Configuration
| Variable |
Default |
Description |
DATABASE_URL |
postgres://localhost:5432/ledgerline |
Local staging database |
WAREHOUSE_URL |
none |
Warehouse endpoint; required unless --dry-run |
WAREHOUSE_TOKEN |
none |
Service account token, never committed |
RULES_DIR |
./rules |
Folder of categorization rule files |
LOG_LEVEL |
info |
One of debug, info, warn, error |
Development
docker compose up -d db
npm test
npm run lint
Tests use fixture statements in test/fixtures/. When adding a bank format, add a fixture with at least one duplicate and one unknown category so both paths are covered.
Contributing
Open an issue in the Finance Engineering project before large changes. Branch names follow feat/<short-name> or fix/<short-name>, and every pull request needs one review from the finance-eng group plus a green CI run. Rule-only changes in rules/ can be approved by finance ops directly.
License
Internal to Northwind. Owned by the Finance Engineering team; questions go to #finance-eng.
The template
Show the blank template
README
One-line description of what this project does and who it's for.
Features
The three or four things this project actually does, not an exhaustive API list.
Getting started
Prerequisites
- Runtime version, required accounts/credentials, system dependencies
Installation
git clone <repo-url>
cd README
npm install
Usage
npm run dev
A minimal, copy-pasteable example of the most common thing someone will do with this.
Configuration
| Variable |
Default |
Description |
|
|
|
Development
How to run tests, lint, and the local dev loop. Link CONTRIBUTING.md if it's more than a few lines.
Contributing
PR process, branch naming, where to file issues, or a pointer to a separate CONTRIBUTING.md.
License
License name and link. Every public repo needs one.
Questions
- How long should a README be?
- Short enough to read in five minutes; move deep material to a docs folder and link it
- What matters most?
- A copy-pasteable path from clone to a running project, tested on a fresh machine
- Does an internal project need a license section?
- Yes, one line: say it is proprietary and internal, and name the owning team, so nobody copies it into an open source repo or a client deliverable
Fill it with your agent
Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.
Find my reph doc "README" with search_docs, then read it with read_doc. Draft each section from the package manifest, env example file, CI config and docs folder I paste. Use the real install and run commands from the manifest scripts and list every environment variable with its default. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (commands you could not verify) with add_comment quoting that section's heading line, then call request_review with a one-line summary.
Related templates
ADR
Architecture decision record: one decision, its context and consequences
EngineerTech leadEngineering managerAgent instructions
The charter your AI coding agents work from, project overview through review checklist
EngineerTech leadEngineering managerSREAI feature eval plan
How you will measure an AI feature before and after launch: the task, a quality rubric, the eval dataset, metrics, baseline vs target, human review, regression gates and a cost and latency budget
EngineerTech leadProduct managerResearcherAPI spec
Endpoints, request/response shapes, errors, auth and versioning
EngineerTech leadBug report
Reproducible bug with expected vs actual behaviour
EngineerSRECode review checklist
What to check before approving a change
EngineerTech leadStart with this template →Sign in