DEV Community: Hem Bahadur Pun

I didn't understand F1, so I built a quiz app to teach myself

Hem Bahadur Pun — Fri, 02 Oct 2026 07:48:29 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

I want to get into Formula 1, but I didn't know what pole, DNF or undercut meant. Pit Wall is the quiz I built to learn.

Pick a 2026 Grand Prix and a tyre. The start lights go out and you answer five questions, one per lap. After each answer, a card explains the F1 term the question used.

Tyre	Asks about
Soft	one fact from the race
Medium	comparing drivers
Hard	the season so far

An agent writes every question, but it never grades you. With each question it also writes a GROQ query that answers it. The server runs that query against real race results in Sanity, and the result becomes the answer.

To check this matters, I gave 30 questions from the app to the same model with no access to the data.

	Correct
Pit Wall (answer from a GROQ query)	30 / 30
Same model, no data	16 / 30
Same model, Hard questions only	3 / 10

Random guessing gets 7 or 8. Asked who had the most podiums after Monaco, the model said Max Verstappen. The data says Kimi Antonelli.

Demo

Play Pit Wall. There's no sign-up. Pick a three-letter driver code and race.

Code

github.com/hempun10/pit-wall. The README covers setup from an empty Sanity project.

How I Used Sanity

The race data

A Python script converts the F1DB SQLite release (CC BY 4.0) into 6,254 Sanity documents. They cover 2014 to round 15 of 2026.

One raceResult is one driver in one race. It references its race, driver and team, so a single query answers "who finished on the podium in Azerbaijan?"

*[_type == "raceResult" && year == 2026 && round == 15 && position <= 3]
  | order(position asc) {position, "driver": driver->name, "team": team->name}

The agent's instructions warn about three traps in the data.

points counts Grand Prix points only. Sprint points live in the standings documents.
Pole is polePosition == true. gridPosition == 1 is wrong after a grid penalty.
pitStops: 0 in a dry race means missing data. Every driver has to use two tyre compounds.

Two Context endpoints

Endpoint	Source	Answers
`pit-wall-data`	the dataset, GROQ mode	facts and numbers
`pit-wall-rules`	a Knowledge Base	what F1 words mean

An endpoint with both sources ignores the Knowledge Base without an error, so Pit Wall uses two. Both expose a tool named initial_context, so the agent gets each set with a prefix.

The data endpoint needs a deployed Studio. Run sanity deploy first, or every call fails.

The Knowledge Base

Nine Wikipedia articles became 15 entries. I added one stale article on purpose, a June 2023 revision that still gives a bonus point for the fastest lap. F1 dropped that rule in 2025.

The build flagged it. One entry said the point was gone, and the glossary said it still existed. The race data settled it. Here is what a winner who also set the fastest lap scored:

Season	Points
2018	25
2019	26
2024	26
2025	25
2026	25

I resolved it to "abolished from 2025". The build flagged three more conflicts. I resolved two from the sources and dismissed one that misread a date range.

How a question gets made

The agent (gpt-5.4-mini on the Vercel AI SDK) gets the round, the tyre and the questions already asked.
It explores the data with groq_query and writes the query that answers its question.
It reads one Knowledge Base entry to explain the F1 term.
It calls submit_question.
The server runs the query. If the result isn't a single string or number, the agent gets one retry with the error.
The server encrypts the answer (AES-GCM) into the question. The browser can't read it, and the server stores nothing per player.

Every answer screen has a "How we checked this" drawer with the exact query that graded you.

The question bank

Writing a question live took 20 to 50 seconds and up to 55,000 input tokens. Now the server saves every verified question as a quizQuestion document and serves it from Sanity in about a second.

The agent writes a new question only when you've seen every stored one for that round and tyre. It stops at six per round and tyre, which also caps the cost. The bank holds 222 questions.

Live questions also got cheaper. The server cancels the OpenAI request when you leave, the agent gets only the three tools it uses, and large query results get cut off so the agent narrows its query.

Team radio

After an answer, you can ask your race engineer a question. A live agent answers from both endpoints and lists the queries and rules entries it used.

When the data can't answer, it says so. Asked why a driver made one pit stop, it confirmed the count and said the data doesn't record the reason. You get two messages per lap.

The championship

A race scores like F1's top five. Five correct answers earn 25 points, then 18, 15, 12 and 10. Your best result per race and tyre counts, and ties go to whoever got there first. Each finished race is a quizRun document.

There are no accounts, only a three-letter code. Your score travels in an encrypted token, so the browser can't change it. Replaying a question, forging a token and finishing a race twice all fail.

What I'd do differently

Vary the questions. Hard often asks "most podiums after round X", and Antonelli has won 8 of 15 races, so the answer rarely changes.
Add optional sign-in. I appear twice as HEM because I played in two browsers.
Grow the Knowledge Base. Nine articles cover newcomer questions, not race strategy.

Built with

I built Pit Wall with Pi. The car at lights out is a recording by Geoff-Bremner-Audio (CC BY 4.0). The fonts are Departure Mono and Instrument Serif, and the flags come from country-flag-icons.

Sanity Project Details

Project ID: hptt7wjq
Dataset: production (public)
Example query: Azerbaijan 2026 podium
Document types: race, raceResult, driver, team, circuit, driverStanding, teamStanding, quizQuestion, quizRun
Context endpoints: pit-wall-data (GROQ mode), pit-wall-rules (Knowledge Base "F1 rules for newcomers")

Over to you

If you follow F1, play a race you watched and tell me which question felt wrong.
If you're new, which F1 term confused you first? I'll add it to the Knowledge Base so the race engineer can explain it.

I Built a CLI That Remembers What I Was Working On (So I Don't Have To)

Hem Bahadur Pun — Sat, 14 Feb 2026 19:39:27 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Every Sunday morning, same story. Standup starts, someone asks "what did you work on last week?" and I'm sitting there scrolling through my git log trying to reconstruct what I did three days ago. Then my manager asks for a weekly summary. Then I need a PR description. Then I switch branches and completely forget what I was doing before lunch.

I was sick of it. So I built DevDaily AI — a CLI tool that acts as your developer memory.

One command, and it reads your git history, analyzes your commits, branches, diffs, PRs, ticket references — and generates a standup, a PR description, or a weekly summary. But the part I'm most proud of? It builds a persistent local journal of your work. Every command you run, every branch you switch, every commit you make — DevDaily silently captures a snapshot. So when you come back on Monday morning and can't remember what you were doing Friday afternoon:

devdaily context

And it tells you. Exactly where you left off. Which files you were editing. What branch you were on. What tickets you were working on.

No cloud. No telemetry. Everything stays on your machine at ~/.config/devdaily/journal/.

The interesting part — it's powered by GitHub Copilot CLI

DevDaily doesn't call OpenAI or Anthropic APIs directly. All the AI generation is delegated to GitHub Copilot CLI. And here's why that matters — Copilot CLI isn't just one model. It's a multi-model agentic platform. It defaults to Claude Sonnet 4.5, but you can switch to Claude Sonnet 4, GPT-5, or whatever model GitHub adds next — all through your existing GitHub account. No separate API keys, no vendor SDKs, no billing headaches. One integration, multiple AI vendors.

DevDaily calls it like this:

copilot -p "Given these 14 commits across 3 branches, generate a standup report..." --silent --no-ask-user --model claude-sonnet-4

That's it. The --silent and --no-ask-user flags let DevDaily use Copilot CLI as a headless AI backend. Users can swap models with a single flag change. And when GitHub adds new models to Copilot CLI, DevDaily gets them for free — zero code changes.

What I focused on for this challenge

The core features (standup, PR, weekly) already existed, but during this challenge I built out the pieces that make DevDaily actually useful day-to-day:

Snapshot hooks — Opt-in post-commit and post-checkout git hooks that silently capture work snapshots. Install with devdaily init --git-hooks, forget about it, and your journal fills up automatically.
Clipboard integration fix — The --format flag was broken. It was accepted but never applied — clipboard always copied raw markdown. Fixed the formatter pipeline so --format slack actually converts to Slack mrkdwn before copying.
Output formatter — Proper conversion between markdown, plain text, Slack mrkdwn, and structured JSON. The Slack converter was tricky — you need to convert **bold** to *bold* without eating *italic*, so I built a Unicode placeholder system that protects code blocks during transformation.
Webhook notifications — devdaily standup --send pushes your standup to Slack or Discord. Plus --test-webhook to validate your setup without spamming the channel.
724 tests — Comprehensive test suite covering everything from hook installation idempotency to formatter edge cases.

Demo

GitHub Repository: github.com/hempun10/devdaily
Install: npm install -g devdaily-ai

The Setup — `devdaily init`

First time? The interactive wizard gets you going in under a minute. It sets up your shell alias (dd), tab completions, notification webhooks, and git hooks — all in one flow:

devdaily init

It asks what you want to configure:

dd shell alias (so dd standup works)
Shell completions (tab-complete all commands)
Slack/Discord webhook setup
Git hooks for auto-snapshots

Pick what you need, skip what you don't. You can always come back with devdaily init --notifications or devdaily init --git-hooks to set up individual pieces later.

System Check

First thing after install — devdaily doctor makes sure everything is set up, including Copilot CLI:

Standup Generation — `devdaily standup`

The bread and butter. One command, your entire standup, copied to clipboard:

Need the last 3 days? devdaily standup --days 3. Working on a specific ticket? devdaily standup --ticket PROJ-123 pulls in the ticket context from your PM tool.

Format Options — The Fix That Matters

Before this challenge, --format slack was silently ignored. Now it actually works — and the formatted version is what gets copied to your clipboard.
devdaily standup --format slack gives you Slack-ready mrkdwn — headers become bold, lists become bullets, and markdown syntax is properly converted:

And here's what it looks like when it actually lands in Slack:

devdaily standup --format json gives you structured data — perfect for piping into dashboards or automation scripts:

And --format plain strips all markdown for clean paste into emails or chat.

Webhook Notifications — `devdaily standup --send`

Don't want to paste your standup manually? Just send it directly:

devdaily standup --send       # Sends to all configured channels
devdaily standup --slack      # Slack only
devdaily standup --discord    # Discord only
devdaily standup --test-webhook  # Test your setup without spamming

DevDaily formats the payload specifically for each platform — Slack gets proper mrkdwn blocks with headers, dividers, and ticket links. Discord gets rich embeds with color-coded types (green for standups, blue for PRs, purple for weekly summaries). Set up your webhooks once with devdaily init --notifications and forget about it.

Context Recovery — `devdaily context`

This is the feature that started the whole project. You come back from lunch, a meeting, or a weekend, and you have no idea what you were doing:

devdaily context              # Where did I leave off?
devdaily context --ai         # AI-powered summary of your recent work
devdaily context --branches   # Show all active branches and their status
devdaily context --all-projects  # Context across all your repos

It pulls from your local journal — every snapshot captured by your git hooks, every standup you ran, every PR you generated — and reconstructs what you were doing. Add --ai and Copilot CLI generates a natural language summary: "You were in the middle of refactoring the auth middleware. Your last commit touched src/services/auth.ts and you had an open PR against develop."

Work Search — `devdaily recall`

"When did I last touch the auth code?" — a question I used to answer by grepping through git logs. Now:

devdaily recall "auth"                # Search by keyword
devdaily recall --file src/auth.ts    # When was this file changed?
devdaily recall --tag feature         # Find snapshots tagged "feature"
devdaily recall PROJ-123              # Find all work related to a ticket
devdaily recall login --ai            # AI summary of search results

It fuzzy-searches across commit messages, branch names, notes, and tags in your journal. Add --ai and Copilot CLI summarizes the results: "You worked on auth-related code across 3 sessions over the last 2 weeks, primarily in src/services/auth.ts and src/middleware/rate-limit.ts."

Snapshot Journal — The Memory

This is the feature I'm most proud of. devdaily snapshot --list shows your work timeline — every commit, branch switch, and PR captured automatically:

And devdaily snapshot --stats to see your journal health:

You can also manually capture snapshots with notes and tags:

devdaily snapshot --note "before big refactor" --tag release
devdaily snapshot --light    # Quick capture, no PR/ticket fetch
devdaily snapshot --prune 90 # Clean up entries older than 90 days

PR Generation

devdaily pr auto-detects your PR template (.github/PULL_REQUEST_TEMPLATE.md), analyzes the diff, and generates the whole thing:

devdaily pr                   # Generate + interactive menu
devdaily pr --create          # Create PR directly on GitHub
devdaily pr --draft           # Create as draft
devdaily pr --interactive     # Pick labels, reviewers, assignees
devdaily pr --ticket PROJ-456 # Include ticket context in description

It detects the PR type from your commits (feature, bugfix, breaking change), generates a conventional commit title, links related issues, and gives you an interactive menu: copy to clipboard, create on GitHub, create as draft, or configure labels and reviewers.

Weekly Summary — `devdaily week`

Every Friday (or whenever your manager asks):

devdaily week                 # This week's summary
devdaily week --last          # Last week
devdaily week --all-projects  # Cross-project summary from your journal
devdaily week --save          # Save to journal for future reference
devdaily week --json          # Machine-readable stats

The --all-projects flag is where the journal really shines — it pulls snapshots from every repo you've worked in and generates one unified weekly summary. No more scrambling across repos trying to remember what you shipped.

Project Management Integration — `devdaily connect`

DevDaily integrates with GitHub Issues, Jira, and Linear. Connect your PM tool once, and standups, PRs, and weekly summaries automatically pull in ticket context:

devdaily connect              # Interactive setup
devdaily connect --test       # Verify your connection works

It shows credential status, tests the connection, and verifies it can fetch tickets. Once connected, DevDaily extracts ticket IDs from your commit messages and branch names (PROJ-123, #42, LINEAR-456), fetches the ticket details, and includes them in your AI-generated output.

Configuration — Global + Project Level

DevDaily has a layered config system. Global config lives at ~/.config/devdaily/config.json, project config lives at .devdaily.json in your repo root. Project config overrides global — so you can have different settings per repo.

devdaily config --show        # See current merged configuration
devdaily config --edit        # Open in your editor
devdaily config --path        # Show config file locations
devdaily config --reset       # Reset to defaults

The config file has JSON Schema support ($schema field), so you get autocompletion and validation in VS Code or any editor that supports it. You can configure everything — output format, default branch, standup sections, PR defaults (reviewers, labels, assignees), notification webhooks, theming, keyboard shortcuts, and more.

Here's a taste of what .devdaily.json looks like:

{
  "$schema": "https://raw.githubusercontent.com/hempun10/devdaily/main/schemas/devdaily.schema.json",
  "output": { "format": "markdown", "copyToClipboard": true },
  "standup": { "defaultDays": 1, "sections": ["completed", "in-progress", "blockers"] },
  "pr": { "defaultBase": "main", "autoLabels": true, "titleFormat": "conventional" },
  "notifications": { "slack": { "enabled": true }, "discord": { "enabled": false } },
  "projectManagement": { "tool": "github" }
}

My Experience with GitHub Copilot CLI

I used GitHub Copilot CLI to build this entire project, and I also built DevDaily to use Copilot CLI under the hood. So I got to experience it from both sides — as a developer using it to code, and as a tool author integrating with it programmatically.

Using Copilot CLI to build DevDaily

The thing that surprised me most was how good Copilot CLI is at understanding existing codebases. I could just launch copilot in my project directory and say "the --format flag on the standup command isn't working, the output is always raw markdown even when I pass --format slack" — and it would read through my source files, trace the execution path through the command handler, and come back with: "The formatter is never called before the clipboard copy. You need to apply formatOutput() before passing the text to clipboardy."

That's not autocomplete. That's actual debugging.

Here are the specific moments where Copilot CLI made a real difference:

The Slack formatter regex problem. Converting markdown to Slack mrkdwn sounds simple until you realize that markdown uses **text** for bold and *text* for italic, while Slack uses *text* for bold and _text_ for italic. If you naively convert **bold** → *bold*, you'll break any *italic* text in the same document. I described this edge case to Copilot CLI and it suggested the Unicode placeholder approach — stash code blocks and inline code using private-use-area characters (\uE000, \uE001) before running the bold/italic conversions, then restore them after. It worked perfectly.

Git hook portability. The auto-snapshot hooks needed to be POSIX-compatible (#!/bin/sh, not #!/bin/bash), run the snapshot in the background so they don't slow down commits, and append to existing hooks instead of overwriting them. I was going back and forth on the right approach and Copilot CLI helped me think through the edge cases — what if the user already has a post-commit hook? What if they install twice? What if they remove hooks but there's other content in the file? The resulting implementation handles all of these cleanly.

Test scaffolding. 724 tests is a lot. Copilot CLI was incredibly helpful for scaffolding the repetitive parts — especially the hook installation tests where I needed to cover idempotency, concurrent installations, force overwrite, appending to existing hooks, and clean removal. I'd describe the scenario, it would generate the test structure, and I'd refine the assertions.

Open-source cleanup. Before publishing, I asked Copilot CLI to audit the repo for anything that shouldn't be public — hardcoded paths, internal docs, personal information. It went through every file and flagged things I would have missed.

What I love about Copilot CLI

Multi-model flexibility. Copilot CLI isn't locked to one AI vendor. It defaults to Claude Sonnet 4.5, but you can switch to Claude Sonnet 4, GPT-5, or other models with /model or --model. Different models have different strengths — I found myself switching models depending on the task. That flexibility is something you don't get when you're locked into a single vendor's API.

Agentic capabilities. This isn't just prompt-in, response-out. Copilot CLI can read files, edit code, run shell commands, create GitHub issues — it's a full coding agent in the terminal. When I asked it to "add error handling to the webhook notification flow," it read the existing code, identified the gaps, wrote the try/catch blocks, and even added the corresponding test cases. All from one prompt.

Staying in the terminal. I'm a CLI person. Having an AI coding agent that lives where I already work — no browser tab, no VS Code sidebar, just my terminal — felt natural. I could go from writing code to asking Copilot CLI a question and back without any context switch.

MCP extensibility. Copilot CLI ships with GitHub's MCP server built in, so it already knows how to work with my repos, issues, and PRs. When I told it to create issues for the remaining work items, it created them directly on my GitHub project board. No copy-pasting, no switching to the browser.

The meta moment

There's something satisfying about using Copilot CLI to build a tool that wraps Copilot CLI. DevDaily calls copilot -p <prompt> --silent --no-ask-user to generate standups and PR descriptions — it uses Copilot CLI as a headless, multi-model AI backend. And the tool itself was built with Copilot CLI as my development partner.

Would I have been able to build DevDaily without Copilot CLI? Sure. Would I have shipped this much — snapshot hooks, formatter pipeline, clipboard fix, webhook integration, 724 tests, open-source prep — in the same timeframe? Not a chance. Copilot CLI didn't just speed things up; it caught bugs I would have missed and thought through edge cases I hadn't considered.

Tech Stack

TypeScript · Node.js · GitHub Copilot CLI · Commander.js · simple-git · clipboardy · Zod · Vitest · tsup · GitHub Actions

From Extra Syllabus to Career

Hem Bahadur Pun — Mon, 13 May 2024 14:22:08 +0000

I still remember the day it was 19th of July 2022 I learned about Web Development (HTML, CSS) in my college at high school. I was majoring in commerce then, and computer science was an extra syllabus added by our high school. But for me, this extra subject was my favorite. Then, Like everyone, I started researching the web development of this topic on YouTube.

At that time there weren't as many tutors on youtube talking about web dev. But from somewhere I got to land on the channel named Code with Harry as I was from Nepal Hindi language was of little use to me. So, I started learning about web development from his playlist. His teaching style was super fun and the way he used to clear the concept.

As I was going at a good pace. Then my high school board examination was waiting for me 😌. Due to the pressure of the examination, I got distracted and all the topics were fussed from my mind.

After around 4 months from nowhere. Again, I got the motivation to start the journey again. Then, I rejoined the playlist. Then, after around 2 months I got a bit of confidence in topics like HTML, CSS, and Internet stuff. Then built some projects CV, Course Landing Page, Hostinger Landing Page Clone. I think I lost a lot of my time learning CSS which was my second mistake. After that, I started learning about JS again from Harry Bhai. As I don't have any prior knowledge of programming at that time. It usually, takes a bit more time to catch the concepts. At that time I learned about many CS kinds of stuff and programming concepts like types of Programming Paradigms, Classes, Functions, Objects, Arrays, Variables, Loops, etc.
Then I started building some projects from YT Quote Generator, Book Mark Keeper, Music Player, Joke Teller
By building these projects I feel a bit comfortable with javascript.

At that time I had also enrolled for my Bachelor's Degree in Computer science side-wise I was constantly learning and expiring the stuff. There comes my third mistake being stuck in tutorial hell. Then, I decided to build some projects on my own and I accomplished Video Player, Form Validator.

Then, I was looking to be involved in some real-world project, and coincidently. At the end of the first semester, I got a chance to intern as a front-end developer through my college coding program. On day one, I felt like like I didn't know anything they asked me about do I know swagger, redux, react query, and many more? I felt literally what are they talking about. I just had a basic knowledge of React JS. Then, they asked me to research about the terms they just asked me and I opened YouTube a typed How to....? Then one of the senior devs of that organization told me I should try to read docs, and blogs more rather than Youtube. After around 2 weeks I started getting what they asked me about and I also started involving in their projects. Some projects I was involved in were in Thrif Store Nepal, and Billing Software. It has been a quite tough and fun journey up to now. From an extra syllabus to a career and passion for it.

Summary

Consistency is the key
Don't get stuck into tutorial hell.
Try a project-based learning approach.
Make basic strong.
If you want to grow don't stop learning.

Note: The above was my journey and learnings all the above words are from my mistakes and learnings.

Looking for your feedback, Happy Learning 🙏🏻

DEV Community: Hem Bahadur Pun

I didn't understand F1, so I built a quiz app to teach myself

What I Built

Demo

Code

How I Used Sanity

The race data

Two Context endpoints

The Knowledge Base

How a question gets made

The question bank

Team radio

The championship

What I'd do differently

Built with

Sanity Project Details

Over to you

I Built a CLI That Remembers What I Was Working On (So I Don't Have To)

What I Built

The interesting part — it's powered by GitHub Copilot CLI

What I focused on for this challenge

Demo

The Setup — devdaily init

System Check

Standup Generation — devdaily standup

Format Options — The Fix That Matters

Webhook Notifications — devdaily standup --send

Context Recovery — devdaily context

Work Search — devdaily recall

Snapshot Journal — The Memory

PR Generation

Weekly Summary — devdaily week

Project Management Integration — devdaily connect

Configuration — Global + Project Level

My Experience with GitHub Copilot CLI

Using Copilot CLI to build DevDaily

What I love about Copilot CLI

The meta moment

Links

Tech Stack

From Extra Syllabus to Career

The Setup — `devdaily init`

Standup Generation — `devdaily standup`

Webhook Notifications — `devdaily standup --send`

Context Recovery — `devdaily context`

Work Search — `devdaily recall`

Weekly Summary — `devdaily week`

Project Management Integration — `devdaily connect`