Writing it up and sharing it

The README is the front door

When someone arrives at your GitHub repository, the first thing they see is the README.md file rendered on the page. A good README answers four questions in about thirty seconds of reading:

1. What is this? One sentence. “A small Python script that summarises today’s NEPSE close in plain Nepali.”
2. Why does it exist? Two or three sentences. The reader, the problem, the gap it fills.
3. How do I run it? Step-by-step. The exact commands.
4. What’s next? What you would build if you had more time. Honest about limits.

That is the whole spec. Four short sections. Half a page of Markdown. The discipline to write that, before you move on to the next project, is the discipline that compounds.

A template you can copy

Open README.md in your project folder. Replace its contents with something like:

# NEPSE Daily Summariser

A small Python script that fetches today's NEPSE close,
asks Claude to summarise it in plain Nepali, and prints
the result.

## Why

Most short-form NEPSE coverage is in English or financial
Nepali. I wanted my aunt — who reads Nepali but not
financial jargon — to be able to glance at one paragraph
each morning and know whether the market moved up or down,
and which sectors led.

## How to run

Requires Python 3.12 and an Anthropic API key.

    git clone https://github.com/yourname/nepse-summariser
    cd nepse-summariser
    python3 -m venv .venv
    source .venv/bin/activate
    pip install -r requirements.txt

Copy `.env.example` to `.env` and set your key:

    cp .env.example .env
    # edit .env and paste your Anthropic API key

Then:

    python summarise.py

The summary is printed and saved to `summaries/<date>.txt`.

## What's next

- Send the summary to Telegram instead of printing.
- Add a CLI flag to choose between Nepali and English.
- Use a vision-capable model to read NEPSE close screenshots
  directly, for days when the API is down.

Two notes about that template:

• It includes a .env.example file — a copy of .env with the secret value stripped out. The point is that someone cloning your repo knows which keys they need to set, without you leaking your own. Commit .env.example; do not commit .env. (Refer back to Chapter 4, Section 2 if you need the rule reinforced.)
• The “What’s next” section is your friend. It signals to a reader (and a future employer) that you understand the project’s limits and have ideas about where it could go.

A small note on screenshots

If your project produces output a human will see — a chart, a formatted summary, a small web page — paste one screenshot near the top of the README. Six words: “this is what it looks like.” For a script that prints a paragraph in the terminal, a copy-pasted block of the actual output works just as well.

A README without any sense of what the program produces makes the reader squint. A README with one example of output answers the most natural question instantly.

Push it, and commit the README

git add README.md .env.example
git commit -m "Add README with overview, run instructions, and next steps"
git push

Refresh the repository page on GitHub. Your README is now the public face of the project. Anyone with the link sees what you built.

Telling people

Telling people about your work is a small, important act of professional courage. The default for most beginners is silence — they finish a project, push it, and never mention it. Five minutes of telling people changes the work’s reach by a hundred times.

Three modest places to start:

1. A LinkedIn post. Short. One paragraph: what you built, why, what you learned, a link to the repo. Tag #AILiteracyNepal if you want to be found by the community.
2. A WhatsApp/Viber message to two friends. “I built this small thing — does the summary make sense to your mum?” Real feedback from real people is worth more than a hundred star ratings.
3. A small blog post. Medium, Substack, Hashnode, your own static site — anywhere. Tell the story: what you tried, what failed, what you learned. The post itself becomes a tiny portfolio piece.

You do not need to do all three. One is enough. The act of saying “I built this” out loud, in public, is what closes the loop on the project. The next time you start one, it will feel less like the first time.

What you have, now

A complete, working, version-controlled, README-equipped, publicly visible small AI application of your own. Built end to end. Using a pre-trained model. Solving a real, specific problem for a specific person. Most professional engineers do not build their first such thing until well into their second year of work. You have done it in eight weeks.

Take a moment with that. Then keep going.

The arc of Course 01, in one paragraph

You started as a user of AI and ended as someone who has built one. Along the way you set up a workshop (Chapter 1), learned the Python you needed to wield it (Chapter 2), met the numerical toolkit every working data person uses (Chapter 3), adopted the three habits that separate tinkerers from builders (Chapter 4), called both a hosted language model and a local vision model from your own code (Chapter 5), and closed the loop by finishing — really finishing — a small real thing (Chapter 6). The track from here goes deeper into each piece: Course 02 on data, Course 03 on machine learning, Course 04 on language models, Course 05 on shipping. But the substrate is now under you, and that substrate is what almost every working AI builder relies on every day.

Course 02 begins

You have built a small project — and you have already, twice, hit the same fact: the work is mostly in the data. The model was easy to call; the prompt was easy to write; the fragile, frustrating, time-consuming pieces were the receipts that did not parse, the CSV columns that came back as strings, the rows with missing fields, the Nepali names spelled five different ways.

That is exactly what Course 02 is about. Working with Data. The least glamorous course in the track, and quietly the most important one.

When you are ready, turn the page.