Forem: MJ Dashtaki

How I Built a Personal Work Journal Dashboard with Claude

MJ Dashtaki — Thu, 07 May 2026 10:49:25 +0000

I've been keeping a work journal for almost 1.5 years now. Nothing fancy: just a Google Doc where I dump daily notes: what I shipped, what frustrated me, who I worked with, how I felt. After a year and a half, I had a wall of text that I never actually read back.

Then I thought: what if Claude could read it for me?

The idea: a Claude "skill"

The inspiration came from a weekly ritual at my company: every Friday we have a Company Standup where each person shares the highlights and lowlights of their week. I always found myself scrambling to remember what I'd actually done, mentally skimming five days of work in thirty seconds while someone else was still talking.

I thought: I already have all of this written down. I just need something to read it back to me, and ideally tell me more than I'd remember on my own.

That's when I started building a Claude skill around my journal. I use Claude Code with a custom skills system (essentially markdown files that tell Claude how to handle specific commands). When I type /journal, Claude reads a SKILL.md file and knows exactly what to do: read my journal from Google Drive, analyze it, and render an interactive dashboard.

The skill file looks like this:

---
name: journal
description: >
  Work journal dashboard skill. Reads your work journal from Google Drive,
  a pasted text, or a local file, analyzes the entries, and renders an
  interactive dashboard.

  Trigger when user says:
  - /journal
  - "show my dashboard"
  - "how was my week"
  - "what did I ship this week"
  - any mention of viewing or analyzing their work journal
---

The description isn't just documentation: it's what Claude uses to decide when to activate this skill. Any phrasing works. As long as the intent is there, Claude picks it up.

How it works: three steps

Step 1: Read the journal from Google Drive

Claude has a Google Drive MCP (Model Context Protocol) connection. With one tool call, it fetches the full document:

Google Drive: read_file_content
fileId: 1Y8rsID6YF3Zhmnbt8t-...

My journal format is simple: bold date headings with bullet points underneath.

**14.03**
- Got good feedback from Sarah in standup
- Helped deploy the new search feature to prod
- Started working on the notification redesign

No schema, no special syntax. Just notes.

Step 2: Claude analyzes the text directly

One important architectural note: the Anthropic API cannot be called from inside a browser widget due to sandbox restrictions. Claude analyzes the journal in the conversation itself, not at render time.

Instead, Claude itself analyzes the journal text in the conversation and produces a structured JSON object. This gets embedded directly into the widget as a const D = {...}. No runtime API calls needed.

The JSON schema covers everything I care about:

{
  "weeks": [
    {
      "label": "W1: 23–27 Mar",
      "week_highlights": ["..."],
      "week_lowlights": ["..."],
      "days": [
        { "date": "23.03", "sentiment": "good", "pos": 65, "neg": 10 }
      ],
      "meetings_regular": 5,
      "meetings_friction": 0
    }
  ],
  "appreciation": [
    { "from": "Sarah", "text": "Really clean PR structure, easy to review...", "date": "14.03" }
  ],
  "pain_points": [
    { "label": "Local dev / deploy process", "count": 12 }
  ],
  "people": [
    { "name": "Sarah", "score": 14, "tags": ["pairing", "reviews"] }
  ],
  "skills": [
    { "name": "Git worktree", "date": "13.04", "type": "skill" }
  ]
}

The analysis rules I give Claude matter a lot here. For example:

appreciation: only include explicitly positive feedback from others, no self-praise
pain_points.count: count by how many distinct days mention that theme
sentiment pos + neg: should sum to at most 90, leaving room for neutral days

Step 3: Render an interactive dashboard

Claude uses a visualizer tool to render an HTML widget inline in the chat. The widget has 9 tabs:

Tab	What it shows
This week	Highlights and challenges for current + previous week
Full month	PR count, features shipped, overtime days
Sentiment	Daily mood bars per week (green = positive, red = negative)
Appreciation	Public feedback received from teammates
Pain points	Frequency bars for recurring frustrations
Meeting load	Stacked bar chart: regular vs friction meetings per week
Feature delivery	Gantt-style bars from start to prod, colored by speed
Collaboration	Who I worked with most, and how
Skills picked up	Tools and techniques learned, with date and context

All styling uses CSS variables, so it adapts to light and dark mode automatically.

Here's what it looks like:

What I actually learned from it

A year and a half of data, visualized, told me things I hadn't consciously registered:

The notification redesign took 18 days, nearly 3x longer than the search feature (6 days). The journal shows why: repeated interruptions, unclear API ownership, and a PM pushing for delivery before the spec was settled.

My worst weeks weren't about the work, they were about communication. Week 4 had the most "friction" meetings and the lowest sentiment scores, all tied to one recurring dynamic with a teammate.

I picked up 11 new tools and skills in 6 weeks, seeing it laid out as a card grid made me realize how much ground I'd covered during onboarding, even when it felt chaotic.

The Appreciation tab is underrated. On a rough day, scrolling through actual quotes from teammates is genuinely useful.

The skill file: what makes it reusable

The whole thing is driven by a single SKILL.md file. When I want to update what the dashboard shows, I just edit the file. No code deployment, no config changes. The skill tells Claude:

When to trigger (any phrasing, any language)
Where to read data from (Google Drive file ID)
What JSON schema to produce
What tabs to render and how

This is what makes it powerful: the "app" lives in a markdown file, and Claude is the runtime.

Try it yourself

The skill is open source. Install it in one line:

npx skills add github.com/mjdashtaki/mj-skills

Or clone the repo directly: github.com/mjdashtaki/mj-skills

The skill supports three journal sources out of the box: Google Drive (via the Drive connector), direct paste, or a .txt/.md file upload. No hardcoded file IDs: Claude asks you on first run.

If you want to build it yourself from scratch, the core idea works with any journal format:

Keep a simple daily log (bullet points are enough)
Write a SKILL.md that tells Claude when to activate and what to analyze
Define the JSON schema for the data you care about
Let Claude analyze and render. No backend needed.

The hardest part isn't the code. It's deciding what questions you actually want to answer about your own work. Start there, and work backwards.

I write about frontend engineering, AI tooling, and developer experience. If you're building something similar, I'd love to hear about it.

How I Built an AI Chat That Speaks As Me

MJ Dashtaki — Sun, 22 Feb 2026 16:26:03 +0000

The idea

My portfolio site is a fairly standard one — it shows who I am, what I've built, and where I've worked. But it always felt passive. Someone lands on it, reads through the timeline, and leaves. No conversation, no depth beyond what fits on a page.

I wanted to change that. What if a visitor could just ask? "Has MJ worked with AI before?" "What was his biggest project?" "Does he have team leadership experience?" Instead of hunting through paragraphs, they'd get a direct, conversational answer, as if they were talking to me.

That's the idea: an "Ask MJ" chat widget, powered by AI, that answers in first person as me, grounded in real content about my career.

The architecture: RAG in plain English

I chose RAG. It sounds complex but the concept is simple:

Store your knowledge — take a document about yourself (in my case, a Markdown file with my full work history, skills, projects, and even performance review highlights and hobbies :) and break it into chunks. Embed each chunk as a vector(a mathematical representation of its meaning) and store it in a database.
At query time, retrieve — when someone asks a question, embed the question the same way, then find the chunks in the database whose vectors are closest in meaning. Those are the most relevant pieces of context.
Generate — pass the retrieved context plus the user's question to a language model, and let it compose a reply.

The result is a chat that only answers from your content, not from the general internet. It can't hallucinate facts about you because it's constrained to what you've written.

Technology choices

Supabase + pgvector — the memory

I already use Supabase for other projects and it was a natural fit. What makes it perfect here is pgvector, a Postgres extension that lets you store and query vector embeddings natively inside your database. No separate vector database service to set up, no extra infrastructure. One SQL migration, one similarity-search function, done.

create extension if not exists vector;

create table documents (
  id bigserial primary key,
  content text not null,
  embedding vector(1536)
);

The similarity search function ranks chunks by cosine distance, the closer two vectors are, the more semantically related they are. It's elegant and fast.

OpenAI — the embedder

For turning text into vectors I used OpenAI's text-embedding-3-small model. It produces 1536-dimensional embeddings and is both affordable and high quality. Every chunk of my content gets embedded once (during the ingest step), and every user question gets embedded at query time before the similarity search.

Groq + Llama — the voice

For the actual chat generation I chose Groq running Llama 3.3 70B. Groq's inference hardware is genuinely fast. Responses start streaming back almost immediately, which is important for a good chat UX. Llama 3.3 70B is a capable open model that follows nuanced system prompts well.

The system prompt was where I spent real attention. It's not enough to say "you are MJ." The model needs explicit rules: always speak in first person, never say "he" or "MJ has", you ARE this person, not an AI assistant describing someone else. That specificity is what keeps the voice consistent.

Next.js App Router — the glue

The whole thing runs inside my existing Next.js site with App Router. The chat API is a single route handler (/api/chat) that handles the full pipeline, embed the query, retrieve from Supabase, build the prompt, stream Groq's response back to the browser as plain text. The client reads the stream token by token and appends to the UI in real time.

No separate backend. No microservices. One route file.

Building with Claude Code

Here's what made this especially interesting: I built it using Claude Code — Anthropic's AI coding agent that runs in the terminal alongside your editor.

The workflow was collaborative in a way that felt genuinely different from using a regular code editor. I'd describe what I wanted, Claude would propose an implementation plan, we'd discuss the approach, and then it would write the code. When something broke, it diagnosed and fixed the issue in context, without losing track of what we were building.

What we built, step by step

The full feature came together in these pieces:

Content file (mj-content.md) — a structured Markdown document with my full career history, AI experience, product stories, languages, and volunteering work. The source of truth for everything the chat knows.
Ingest script (ingest.ts) — a one-time Node script that reads the content file, splits it on --- section boundaries into natural chunks, embeds each chunk via OpenAI, clears the old rows, and upserts everything into Supabase. Re-runnable whenever the content updates. One command: yarn ingest.
API route (/api/chat) — the server-side pipeline: embed the query → similarity search in Supabase → build a first-person system prompt with the retrieved context → stream Groq Llama's response back as a plain text ReadableStream.
ChatWidget component — a 'use client' React component with a floating button, a slide-up panel, streaming message rendering, animated typing indicator, error handling, Escape-to-close, body scroll lock on mobile, and full-screen layout on small screens.

The result

The chat works. Someone can visit mjdashtaki.com, click "Ask about MJ from MJ's AI Twin", and ask something like "Has MJ led any teams?" or "What was his biggest technical challenge?" and get a warm, first-person answer grounded in real facts about my career.

It's not a gimmick. It makes the portfolio interactive in a way a static page can't be. Recruiters, collaborators, or curious engineers can get real signal fast, without reading everything.

The whole thing — from zero to deployed — was built in a single focused session, using a stack of four packages added to an existing Next.js project. That's what I find exciting about where tooling is right now: the distance from idea to working product has collapsed.

What's next

A few things I'd like to add:

Suggested questions — surface a few starter prompts ("What's MJ's strongest skill?", "Is he available for freelance?") to help visitors who don't know where to begin.

But for a v1, I'm happy with it. It speaks as me, it knows my story, and it loads fast.

If you want to build something similar on your own portfolio, the stack is: Supabase pgvector + OpenAI embeddings + Groq Llama + Next.js API route. The ingest script and route handler are each under 60 lines.

🚀 Accelerate Your Onboarding: How to Hit the Ground Running as a New Product Engineer

MJ Dashtaki — Sun, 13 Apr 2025 16:21:47 +0000

Joining a new company can feel like being dropped into the middle of a busy highway. There are new faces, unfamiliar tools, and processes that are still a mystery. But the faster you ramp up, the sooner you can start making an impact. Here’s a guide to help you onboard like a pro, especially if you’re a product or frontend engineer.

When onboarding begins, you’ll likely have many meetings and tasks to manage. I just wanted to share how I approach my onboarding process to make it as fast and efficient as possible.

🔍 1. Start With Curiosity: Ask for Documentation

Also, all companies have a sort of documentation that can helps, so look for key resources:

Engineering handbook
Architecture overviews
Incident response guides
Release checklists
Feature lifecycle docs

Before you dive into the code, ask your team:

Do we have documentation on engineering workflows, release processes, or incident handling?

The best time to ask questions is during a meeting with your onboarding's meetings. If you need help from someone you don’t have a meeting with, take that as an opportunity to reach out and schedule a 1:1 meeting, introduce yourself, and have a quick chat with someone who knows the product well.

Tip: If documentation is outdated or missing, take notes and help improve it. It’ll help the next joiner (and solidify your knowledge).

🧠 2. Learn the Product, Not Just the Code

Understanding the product and customer pain points makes you a better product engineer. Don’t just look at functions, look at the why behind them. Some companies have walkthrough session, and they show you what is the product and how it works. This meeting ideally led by someone from PS or Sales who knows the platform in more detail. I really believe that having a solid understanding of the product and the business context helps us write better code. Ideally, this kind of session should happen in the first week of onboarding.

Regardless of whether we’re backend or frontend engineers, at the end of the day, we’re product engineers, and being able to see/feel the customer’s pain points puts us in a much stronger position to build meaningful solutions.

🛠️ 3. Understand the Codebase With Context

Don’t just randomly browse files and start with a map. Before diving into the code, familiarize yourself with the structure and flow. Understanding these will help you navigate the codebase effectively and contribute to the project faster:

Look for README files in each directory.
Ask for an architectural overview or a recorded engineering walkthrough.
Find out where feature flags, state management, and routing are handled.

Ask:

"What’s the entry point of the app?"
"How are new features usually added?"
"Is there a standard folder structure or naming convention we follow? Any documentation for it?"

🤝 Ask Designers: “What are our core user journeys?”

🔄 4. Shadow the Process: Releases, Bugs & Incidents

Not everything lives in a doc — real understanding often comes from observation. By shadowing key workflows like releases or incident handling, you'll get an inside look at how the team reacts under pressure, makes decisions, and collaborates. This hands-on exposure is invaluable for leveling up fast. I would say it’s tribal knowledge. Learn it by:

Shadowing a release or pairing on a hotfix
Asking what happens when a P1 bug comes in
Attending a postmortem or retro session

Tip: Join relevant Slack channels like #<releases>, #<bugs>, or #<incidents>. Just observing can teach you a lot.

⚙️ 4. Learn the Development Process

To become an effective contributor, it's crucial to understand how the team ships software. From how branches are managed to how features are released and bugs are tracked, learning these workflows early will help you navigate the codebase and collaborate efficiently with your team.

Understand the branching strategy (feature branches, etc.).
Learn the release cycle (weekly, bi-weekly, feature flags?).
Check how code reviews are done — are there PR templates, guidelines?
Figure out how bugs, tasks, and features are tracked (Jira, Linear, etc.)

📅 Ask: “What’s our process from task creation to deployment?”

✍️ Final Thoughts

Onboarding is a two-way street: you’re learning, but you can also provide value quickly by asking good questions, spotting gaps, and documenting what you learn. If you're intentional about it, you can go from new hire to high-impact team member in record time.

Let curiosity lead the way — and don’t be afraid to ask. The faster you understand how the business, product, and code fit together, the faster you'll build things that matter. Happy onboarding!

Quality Quest: The Importance of Reviewing Merge Request

MJ Dashtaki — Tue, 25 Apr 2023 22:22:52 +0000

I recall having a team lead when I was at my first job, and my revision control was showing the changes with red font color (I think it was Hg Tortoise 😄 ), and at some point, he told me,

You should see the red lines of the code that you changed as blood; they should be taken seriously. Do not commit your changes till you make sure".

I still remember those words vividly, and they have stayed with me ever since. Quality is essential when it comes to software development, and it should never be taken lightly.

Why reviewing merge requests carefully is important

Reviewing merge requests is a critical step in ensuring that the codebase remains high-quality, consistent, and reliable. Without proper review, code changes could introduce bugs (even by fixing a bug) or other issues that could lead to crashes, security vulnerabilities, or other problems. Reviewing merge requests helps catch these issues early on before they become bigger problems down the road.

It is not enough to only check the code quality

When it comes to reviewing merge requests, it is crucial to take a comprehensive approach. One purpose of reviewing is to make sure the changes are consistent with the overall codebase's architecture and style however It is not enough to only check the code quality; there are several other aspects to consider, such as functionality, performance, security, documentation, and testing. Check out the feature/fix/hotfix/... branch and try to test it in action and ensure it's working as expected based on what's described in the ticket. Ensure that the changes are consistent with the overall codebase's architecture and style.

The MR checklist is a blast

Create a checklist of all the aspects that need to be considered when reviewing a merge request. This checklist will help ensure that every aspect that we are concerned about is tested by the reviewer, even technical details.
As an example:

* [ ] By adding this feature the payment information show still work
* [ ] It MUST be reviewed by Zsolt
* [ ] Preview mode should be handled in this case
- Technical writer review items:
    - [ ] Test coverage should be still more than 90%
    - [ ] Cache invalidation should be fine
    - [ ] Ensure a release milestone is set

Different View, Different Perspective

Ask for review from someone outside of your team/squad for some cases that you think [s]he has some insight in regard to the MR, as they can provide a fresh perspective and help identify issues that the team may have missed.

Mandatory reviewers

Make it mandatory that the merge request must be approved by someone who is working with you on the same feature, who might have some ideas around your approach, or who has a reputation for maintaining high-quality code.

Merge request template

Actually, they come in handy in order to explain what the reason was for creating this merge request. Basically, it leads you to guidelines, instructions, and a checklist that developers can follow to ensure that their merge requests are of high quality, and they should provide all of the necessary information upfront.

Conclusion

In conclusion, quality is a crucial aspect of software development, and it should never be taken lightly. Reviewing merge requests and using testing tools can help improve code quality, test coverage and identify potential issues before they become problems. By following best practices and continually striving to improve quality, we can create more stable and reliable software systems.

Unknown, any and never types in Typescript

MJ Dashtaki — Tue, 28 Mar 2023 19:18:02 +0000

Intro

TypeScript is an open-source programming language that adds optional static typing to JavaScript. It is widely used for developing large-scale applications and has several types that help developers to write better code. In this article, we will discuss the differences between the unknown, any, and never types in TypeScript.

Difference

Let's take a look at a simple code example to understand the difference between unknown and any types:

function getValue(): unknown {
  return "Hello, world!";
}

const value: any = getValue();

console.log(value.toUpperCase()); // No error at compile-time, but can throw runtime error

In this example, the getValue function returns a value of type unknown, which means that the type of the value is not yet known during the execution of the program. When we assign the value to a variable value of type any, we tell TypeScript to allow any type of value to be assigned to that variable, including the value returned by getValue.

Now, when we call the toUpperCase method on the value variable, TypeScript does not throw an error at compile-time, but it can still throw a runtime error if the value is not a string. This is because the any type does not provide any type safety, and the developer needs to ensure that the value is of the correct type before using it.

On the other hand, if we change the type of the value variable to unknown, TypeScript will require us to perform a type check before using the value, like this:

function getValue(): unknown {
  return "Hello, world!";
}

const value: unknown = getValue();

if (typeof value === "string") {
  console.log(value.toUpperCase()); // No error
}

In this example, we perform a type check to ensure that the value variable is a string before calling the toUpperCase method. This provides better type safety and prevents runtime errors.

The never type is different from unknown and any types, as it represents values that will never occur. Here's an example:

function throwError(): never {
  throw new Error("Something went wrong!");
}

const result: never = throwError(); // No error

In this example, the throwError function always throws an error, so it will never return a value. We can use the never type as the return type of the function to communicate this to the compiler. This helps in improving the overall code quality and maintainability, as it clearly communicates the intent of the function.

Usecase:

The unknown type in TypeScript should be used when the type of a value is not known at the time of declaration. It is particularly useful when working with dynamic data, such as data from API responses, as it provides better type safety and prevents runtime errors.

The any type should only be used as a last resort, when it is not possible to determine the type of a value. It should be avoided as much as possible, as it can lead to runtime errors and make the codebase difficult to maintain.

The never type should be used as a return type for functions that will never return or throw an error. This helps in making the code more readable and maintainable, as it clearly communicates the intent of the function.

Conclusion:

In conclusion, TypeScript has several types that help developers to write better code. The unknown type provides better type safety and is useful when working with dynamic data. The any type should be avoided as much as possible, as it can lead to runtime errors and make the codebase difficult

Methods of solving a problem!

MJ Dashtaki — Mon, 06 Feb 2023 17:42:57 +0000

It is very important for programmers/developers to be able to find a quick and at the same time optimal and good solutions for a problem/issue, which can be improved by experiencing and seeing programming solutions or best practices. However, there are a series of methods that generally help the programmer to find a quick and optimal solution to any problem, as I said. Basically, the first step to finding the best solution you have to understand and comprehend the problem well, It became a bit philosophical :) You should know comprehending and understanding are different from each other.

When you understand the problem you will find several solutions however when you comprehend the problem you will choose the best solution for it.

To solve a problem, you have to understand and comprehend the problem well. Perhaps the example is that if you understand the problem well, you may have several solutions to it, and when you comprehend it well, you can choose the best solution.

Now, How do we know that we understood it well?!?

The solution that I highly recommend is that you use the Rubber Ducking technique, that is, in order for you to realize that you understand the problem well or not. Let’s explain the problem to your colleague if he understands your problem, it means you understand the problem well and correctly so far. Otherwise, it means that you still need to understand the problem well. In fact, it may be an idea that this step may be very time consuming however it is very important because if you understand and comprehend the problem you can solve it better and faster.

How to understand and comprehend?

Well, now what do we do to understand the issue well? Somebody like Valinda Chan here recommends reading the issue at least three times, here the word "at least" is very important.
Mr. John Sonmez who is the author of the book Soft Skills Here said he believes that if you want to get the best answer you should spend 70% of your time on the stage of understanding the problem. It brings you the importance of this.
The next thing to do is solve the problem with three test data. In fact, you are trying to understand the behavior of your problem with this data, also it will make you pay more attention to Edge Conditions and Corner Conditions.

Finally

You should write your steps that you have solved the problem in the form of pseudo-code, and since you are writing in the steps in pseudo-code, it is much easier to understand at first glance, and besides, you are more involved in logic than code and for instance, you do not think about What should I use for looping now. In the next step, you should convert it to real code and the last step is optimizing and refactoring the code that you have written to get to the minimum code.

Conclusion

Until you don't know what the problem is exactly, you should not jump over it. It is like an algorithm to solve a problem, So you have to move further step by step.

Smart use of “if/else”

MJ Dashtaki — Mon, 06 Feb 2023 17:38:49 +0000

Actually, this article is not against the if/else but tries to show how following an anti-if pattern will improve your code quality. First thing first, I think we have to know how to use if/else could be improved your code quality in terms of reading(readability) and hard to debug(maintainability)
There are pretty many articles on the internet that lead you to prevent using if/else and being an Anti-If developer.

In some cases using shorthand if/else might also be helpful because it avoids branching your code which costs more in terms of complexity.
For instance in this case you can get rid of else just by return there is no code branching too:

Ternary Operator (?:)

If you want to shorten If/else and in this case else part is mandatory, you can use ?: operator as:

condition ? action-on-true : action-on-false(else)
// For instance
const gender = isMale ? 'Male' : 'Female';

I see this kinda short hand format used for null/undefined checking like:

const avatarName = user.firstname ? user.firstname : user.lastname;

However in this case you can simply use:

const avatarName = user.firstname ?? user.lastname
// or depends on your case you can use  "||"
const avatarName = user.firstname || user.lastname

Logical Operator (&&)

In another case, if you have only if condition you can use && operator as:

condition && action;
// For instance
!this.settings && (this.settings = new TableSettings());

You can also use polymorphism to avoid using if/else like as an example below which is really more readable/maintainable, Here is the code :

And then it can be implemented by polymorphism:

Conslusion:

I hope it did help but anyway in order to write a code that is reliable we have to apply best practices.