# Plan a Trekking Trip With AI, a Weight Spreadsheet, and the LighterPack SDK

> Source: <https://dev.to/paladini/plan-a-trekking-trip-with-ai-a-weight-spreadsheet-and-the-lighterpack-sdk-k7j>
> Published: 2026-09-03 13:40:22+00:00

Planning a multi-day trek is a data problem disguised as an adventure. You collect GPX files, weather notes, permit links, and a growing pile of gear receipts. Weight limits show up in airline rules, in your own fitness goals, and in every "do I really need this?" moment at 4,000 meters.

Most hikers end up with the same fragmentation: a spreadsheet here, a LighterPack list there, product links in browser tabs, and half-remembered weights copied from store pages. The list gets stale the moment you buy one more layer or swap a stove.

This tutorial describes a workflow I used while preparing a Salkantay trek repository, generalized so you can adapt it to any hike. The idea is simple:

`@paladini/lighterpack`

You will not get a magic "upload PDF → perfect pack list" button. You will get a repeatable pipeline you can version in Git, re-run before a trip, and extend with your own rules.

Think in three layers:

| Layer | Role | Artifact |
|---|---|---|
| Planning | Context, route, references |
`README.md` , GPX, notes |
| Inventory | Quantities, weights, prices, purchase status | `gear/items.csv` |
| Publishing | Shareable pack list with categories and photos | LighterPack list + public link |

AI sits on the **edges** of this system: helping you draft the plan, extracting rows from invoices, and filling gaps when a product page is hard to parse. The CSV stays deterministic. The sync script stays boring. That separation is what makes the workflow trustworthy.

`2026/my-trek/`

.The SDK is **unofficial**. It talks to the same web API the LighterPack site uses and authenticates with your normal username and password. Treat those credentials like any other secret.

Start with questions AI is good at when you feed it structured context:

Ask for a **draft** checklist by category (shelter, cooking, clothing, safety), not a final weight table. Your job is to reject, merge, and annotate.

A useful prompt pattern:

```
I am hiking [trail] in [month] with [N] people.
Constraints: [weight limit], [diet], [owned vs to-buy].
Return a table with columns: category, item, model, quantity, notes.
Mark each row as owned, to-buy, or borrow.
Do not invent weights or prices.
```

Save the narrative plan in `README.md`

and keep evolving it. Do **not** let the chat transcript become your inventory database. Chats are great for exploration; they are poor as source of truth.

This is where AI saves the most tedious work. After you buy gear, you usually have:

Paste the text (or attach a readable PDF/image) and ask the model to emit **CSV-shaped rows** aligned with your schema.

Recommended columns:

```
category,item,model,quantity,unit_price,total_price,unit_weight_kg,total_weight_kg,baggage,status,notes,url
```

Example prompt:

```
Extract gear purchases from this invoice into CSV rows.
Schema: category,item,model,quantity,unit_price,total_price,unit_weight_kg,total_weight_kg,baggage,status,notes,url
Rules:
- baggage is "carry-on" or "checked" when known, else empty.
- status is "owned", "to-buy", or "rent".
- unit_weight_kg only if explicitly stated; otherwise leave blank.
- url: product page if visible, else empty.
- One row per line item; quote fields that contain commas.
Output only CSV, no commentary.
```

Review every row. AI will misread bundles ("2 pairs of socks" vs quantity 2), confuse shipping with product weight, and hallucinate URLs. Weights from manufacturer pages are often missing on invoices — look them up once, then store them in the CSV.

For a two-person trip, decide early whether quantities are **per person** or **shared** and document that in `notes`

. LighterPack supports quantity per line item; your spreadsheet should match how you think about the pack.

Once reviewed, commit `gear/items.csv`

to Git (or keep it locally if you prefer). This file is the contract between:

Conventions that paid off in practice:

`Camping`

, `Clothing`

, `Hydration`

, etc.).`Math.round(kg * 1000)`

).A minimal row might look like:

```
Clothing,Trekking boots,Hoka Speedgoat 6,2,1000.0,2000,0.267,0.534,carry-on,owned,,
```

Install the SDK:

```
npm install @paladini/lighterpack
```

Create `scripts/lighterpack/.env`

(never commit it):

```
LIGHTERPACK_USERNAME=your_username
LIGHTERPACK_PASSWORD=your_password
```

The sync script reads the CSV, groups items by category, resolves images, and creates the list in one batch call. The core pattern:

``` js
import { LighterPackClient } from '@paladini/lighterpack';

const lp = new LighterPackClient({
  username: process.env.LIGHTERPACK_USERNAME!,
  password: process.env.LIGHTERPACK_PASSWORD!,
});

await lp.account.setCurrencySymbol('$'); // or €, £, etc.

const detail = await lp.batch.createListWithItems({
  name: 'My Trek 2026 (2 people)',
  description: 'Generated from gear/items.csv',
  categories: [
    {
      name: 'Shelter',
      items: [
        {
          name: '2-person tent',
          description: 'Naturehike Star River 2 · Checked bag',
          qty: 1,
          weight: 1950, // grams
          weightUnit: 'g',
          price: 900,
          url: 'https://example.com/tent',
          worn: false,
          consumable: false,
        },
      ],
    },
  ],
});

await lp.lists.setOptionalFields(detail.listId, {
  images: true,
  price: true,
  worn: true,
  consumable: true,
  packWeight: true,
});

const shareUrl = await lp.lists.generateShareLink(detail.listId);
console.log(shareUrl);
```

`createListWithItems`

is the workhorse: one round trip to scaffold categories and items. For large lists (50+ lines), this is far less fragile than clicking through the UI.

Map CSV columns to SDK fields explicitly:

`name`

← `item`

`description`

← `model`

, `notes`

, `baggage`

, `status`

(joined as readable text)`qty`

← `quantity`

`weight`

← `unit_weight_kg`

converted to grams`price`

← `unit_price`

`url`

← `url`

LighterPack can display item photos from external URLs, but retailer CDNs often block hotlinking or return generic Open Graph images. In a real sync of ~50 items, a majority of naive `og:image`

URLs failed.

A more reliable approach:

`lp.items.uploadImage(itemId, { buffer, filename, mimeType })`

.Local upload beat `setImageUrl`

for visibility on the share page. Keep downloaded binaries out of Git; store only the resolver map and scripts.

After `npm run sync:trek`

(or your own script name), check:

Example output from a successful run:

```
{
  "listId": 17,
  "name": "Salkantay 2026 (2 people)",
  "weightGrams": 25100,
  "price": 14489.78,
  "shareUrl": "https://lighterpack.com/r/example"
}
```

Re-run the sync after CSV edits. Idempotency strategy: find an existing list by name, delete it, recreate. Crude but clear for personal repos.

`.env`

, passwords, or invoice PDFs with personal data.| Choice | Benefit | Cost |
|---|---|---|
| CSV as source of truth | Git-diffable, scriptable | Manual review after AI extraction |
| Batch SDK create | Fast, repeatable | Deletes/recreates list on full sync |
| AI invoice parsing | Less typing | Requires validation; not fully autonomous |
| Local image upload | Reliable thumbnails | Extra download/upload step |

This workflow is optimized for **multi-day treks** where gear lists are large and shared. For a day hike, a single LighterPack list edited by hand is probably enough.

`make check`

that validates CSV totals and required fields before sync.If you try this pipeline, start with ten items end to end before importing a full expedition list. Fix the schema once, then scale.

**Question for readers:** Where do you draw the line between "AI drafts the row" and "I require a photo of the scale / spec sheet before it enters the CSV"? I still hand-verify every weight that affects carry-on compliance.

`@paladini/lighterpack`

on npm