DEV Community: Michael Rewiri-Thorsen

Redesigning My Site Theme in One Evening with Kiro IDE, Astro 7, and AWS Amplify

Michael Rewiri-Thorsen — Mon, 17 Aug 2026 06:03:10 +0000

The following is a build-in-public walkthrough of a full theme redesign. From colour exploration to production deployment, including the deployment issues I hit and how they were solved.

The Setup

My site (mikefromnz.com) runs on Astro, deployed to AWS Amplify, styled with Tailwind CSS.

It had a dark theme the typical near-black background (#0a0a0a), cyan accent (#22d3ee), Inter font at 16px. Functional, but generic.

Every dark-mode dev blog looks like this. (mine still has a way to go)

I wanted something warmer and more distinctive. I use Kiro IDE as my development environment, so the whole process happened as a conversation, describe what I want, iterate on options, apply changes, deploy.

The Design Process- BEFORE

Finding Colours

I went looking for colour palettes and landed on the work of Sanzo Wada, who founded the Japan Standard Color Association in 1927. His six-volume Haishoku Soukan documents over a thousand colour combinations. I browsed them at colors.elwyn.co and pulled out two palettes to explore:

Palette 1: Pomegranate Purple, Cobalt Green, Green Blue, Deep Slate Green

Palette 2: Spectrum Red, Ivory Buff, Rainette Green, Aconite Violet

Generating Mockups

Rather than guessing how colours would look applied to my actual layout, Kiro generated standalone HTML mockups — no dependencies, just open in a browser. Each mockup showed three side-by-side previews of my real site layout (nav, hero, blog cards, footer) with different colour mappings.

I explored three "patterns" for how to assign the colours:

Option A/B: Single bold accent colour
Option C: Calm primary accent with a contrasting "pop" colour on hover/active states

Option C won — the dual-accent approach gives the site personality without overwhelming the reader.

Picking a Font

I like Century Gothic for its clean geometric forms, but it's a proprietary Monotype font — can't load it from Google Fonts. Kiro suggested alternatives and mocked up three:

Outfit — modern, slightly condensed
Nunito — soft rounded terminals, warm (closest to Century Gothic)
Poppins — geometric, crisp, widely used

Nunito won. Then I compared 18px vs 20px base size — 20px gave an editorial feel that suits long-form technical content.

The Final Theme

Role	Value
Background	`#1c2219` (dark mossy green)
Surface	`#272e23`
Text	`#ebd3a2` (Ivory Buff)
Muted text	`#8fa071` (Rainette Green)
Accent	`#ebd3a2` (Ivory Buff)
Hover pop	`#a36aa5` (Aconite Violet)
Font	Nunito, 20px base
Dot-field	Faint Spectrum Red at 12% opacity

The actual code change? Two files:

tailwind.config.mjs — colour tokens and font family
src/layouts/BaseLayout.astro — Google Fonts link, base font-size, dot colour

The Deployment Issues

This is where the "build in public" part gets bumpy, but not impossible to fix. Three problems were hit on the way to production:

Problem 1: Astro 7 + astro-aws-amplify Peer Dependency Conflict

I upgraded from Astro 6 to 7.2.2 at the same time as the theme change. The astro-aws-amplify adapter (v0.4.1) declares peer astro@"^6.0.0", so npm ci in the Amplify build pipeline refused to install.

Fix: Added a .npmrc file to the repo:
legacy-peer-deps=true

The adapter works fine at runtime with Astro 7, it's just the peer dep declaration that's outdated. My solution unblocked the install until the adapter publishes a v7-compatible release.

Problem 2: Build Output Exceeded Amplify's 220MB Limit

The Amplify build completed successfully, but deployment failed:

CustomerError: The size of the build output (243093783) exceeds the max allowed size of 230686720 bytes. DOH!

Astro 7's dependency tree is heavier than v6. The build moves node_modules into .amplify-hosting/compute/default/ for the SSR runtime, and it was 243MB — 23MB over the limit. DOUBLE DOH!

Fix: Added cleanup commands to amplify.yml after npm prune --production:

- find node_modules \( -name '*.ts' ! -name '*.d.ts' -o -name '*.map' -o -name 'CHANGELOG*' -o -name '*.test.*' -o -name '*.spec.*' \) -delete 2>/dev/null || true
- find node_modules -type d \( -name '__tests__' -o -name 'test' -o -name 'tests' -o -name 'docs' \) -exec rm -rf {} + 2>/dev/null || true
- find node_modules -name '*.md' ! -name 'LICENSE*' -delete 2>/dev/null || true

This strips TypeScript source files, source maps, changelogs, test directories, and documentation from production node_modules. Shaved enough to get under the limit.

Lesson: If you're on Amplify with SSR (server output mode), watch your node_modules size after major framework upgrades. The 220MB limit is for the entire compute artifact including your bundled app AND node_modules.

Problem 3: New Routes 404ing Despite Successful Build

The /learn page (and all nested course pages) returned 404 on staging, even though:

The build log showed them prerendering successfully.
The static HTML existed at index.html.
Directly accessing index.html worked fine.

Root cause: Amplify's deploy manifest routes extensionless paths (/learn) to the Compute (SSR) handler.

For prerendered pages to be served at clean URLs, they need app-level custom rewrite rules that map /learn → index.html.

These rules are pushed via the Amplify API in the postBuild step. But:

The existing generate-amplify-rules.mjs script only handled single-depth routes (/about, /cv) and single-level wildcards (/blog/).

The multi-level /learn/aws-aif-c01/aif-exam-overview/exam-format paths were never covered.

The rule-push was restricted to the main branch, so staging deploys never updated the rules.

Fix: Rewrote the script to emit an explicit rewrite for every prerendered index.html regardless of nesting depth, and allowed staging to push rules too:


function toRules(paths) {
  const rules = [{ source: '/', target: '/index.html', status: '200' }];
  for (const p of paths) {
    rules.push({ source: `/${p}`, target: `/${p}/index.html`, status: '200' });
    rules.push({ source: `/${p}/`, target: `/${p}/index.html`, status: '200' });
  }
  return rules;
}

Lesson: If you're using Astro in hybrid mode (some pages prerendered, some SSR) on Amplify, you need rewrite rules for every prerendered clean URL. The astro-aws-amplify adapter's deploy manifest sends all extensionless paths to compute by default.

Without explicit rewrites, prerendered pages at nested paths will 404.

What Worked Well

Kiro IDE kept the full conversation context, and alongside my Obsidian vault, it read my existing Tailwind config, understood the component structure, generated mockups using my actual layout, and applied changes to the right files without touching unrelated code.

Astro prerendered 80+ pages in under a second. The hybrid mode (SSR for admin, static for everything else) is exactly right for a content site with a lightweight CMS.

AWS Amplify gave me staging and production branches with automatic deploys from git push. The staging preview URL meant I could check the theme visually before going live.

The combination meant the feedback loop was measured in minutes:

change colours → build → see it on staging → adjust → push to prod.

Below is the learn page that was having issues, but not anymore!:

The ADR

I documented the decision formally as ADR-001 in the repo, captures the context, options considered, final decision, and consequences.

ALWAYS worth doing even for personal projects when you know you'll forget why you picked that specific shade of green in six months.

Final Thoughts

The whole redesign: from "I want new colours" to live on production, took one evening session and half an hour the next morning to fix deployment issues.

The colour exploration alone (two palettes, six options, three fonts, two sizes) would have taken me days of indecision without the instant visual comparison that the mockup approach gave me.

Sometimes the best part of building in public is showing the problems, not just the polished result.

The site is live at mikefromnz.com. Colours by Sanzo Wada (via colors.elwyn.co).

The MCP Server of You: Building a Personal Knowledge Power for Kiro IDE

Michael Rewiri-Thorsen — Fri, 20 Mar 2026 05:49:32 +0000

In this post I'm going to walk you through how I built kiro-recall,
a Kiro IDE Power that loads your personal knowledge vault into every
session before you type a single word.

We'll cover why I built it, how it works, and how you can install
and test it yourself.

I'm getting old, and as I get older, I find my brain races faster than it ever has, because I have gained more and more knowledge as the years have dragged on ceaselessly.

I needed to go back to filing my thoughts.

I started with a notepad with way too many unsaved tabs. Great. Now I can't remember what I wrote on every single tab, let alone find them on my PC if I closed them down.

I needed a solution - a digital Zettelkasten folder or "second brain" vault seemed to solve that problem, so I built one in Obsidian.

During the development of the Power though, I discovered all I needed
Obsidian for was the inspiration. I needed to see the shape of how
these things were constructed.

Turns out a vault is just a folder. Plain markdown files on your own disk,
organised in a way that makes sense to you. No app required to read
them, no proprietary format locking you in, no cloud sync needed.
Any text editor can open them. Any MCP server can read them.

That realisation is what made kiro-recall possible. If the vault is
just a folder, you can point an MCP server at it, read the files
directly, and inject them into a Kiro session without Obsidian ever
being involved. Obsidian is still great for browsing your notes
visually, the graph view, backlinks, and plugin ecosystem are
genuinely useful. But it's optional. The vault works without it.

What we're building

kiro-recall is the MCP Server of You.

Your decisions, your knowledge, your project context, loaded from your
own machine into every Kiro session automatically before your first
prompt reaches the model.

Kiro's steering files are unreliable.

I found this out the hard way. I had steering files configured with
inclusion: always, the mode that's supposed to load them into every
single interaction. They still got ignored. Kiro would generate code
in broken language causing syntax errors, forget architectural decisions
I'd documented, and ask me to re-explain context I'd already written down.

After a Kiro update introduced Agent Skills, the problem got worse. Users
started reporting on GitHub that project steering files were failing
to load entirely, with the AI ignoring inclusion: always in favour
of generic task instructions.

Every new session I was back to re-establishing who I am, what the
project is, what decisions were already made.

kiro-recall replaces that with a hook-based context injection system.

A session start hook fires on your first prompt. Before your message
reaches the model, it reads your personal knowledge vault from disk
via MCP and injects the relevant notes as context. Not steering files.
Not a prompt you paste in every session. Your actual notes, loaded
automatically, every time.

You do nothing. It just happens.

The difference is architectural. Steering files sit in your workspace
and hope the model reads them. kiro-recall uses a hook - it fires on
the promptSubmit event, which means it runs before Kiro can ignore
anything. The context is already in the session before your first word.

The vault is plain markdown files. No cloud dependency for reading your
own notes. No data leaving your machine.
v0.1.0 ships four hooks:

Hook	Trigger	What it does
Session Start	Every first prompt	Reads vault, injects context
`/recall`	User triggered	Writes a structured note to `00-inbox/`
Vault Scaffold	User triggered	Creates the standard folder structure
`/promote`	User triggered	Reformats an inbox note as a Zettelkasten permanent note

The architecture is intentionally minimal. No compiled code. No runtime
dependencies beyond the MCP server. Every hook is a JSON file with an
askAgent prompt that instructs the model to execute a numbered
procedure using MCP tool calls.

This isn't a new idea. Developers have been pointing Claude Code at
Obsidian vaults for months, and the consensus is consistent: targeted
context beats re-explaining everything from scratch every time.

And apparently, it saves you tokens and credits.

That might seem counterintuitive. You're adding context, so shouldn't
that cost more? The saving comes from what you stop doing.

Before I built kiro-recall, every Kiro session started the same way.
I'd open a workspace, type my first prompt, and immediately hit a wall.
Kiro didn't know what I was building, what decisions I'd already made,
or what stack I was using. So I'd spend the first few exchanges just
getting it up to speed. Sometimes I'd paste in background. Sometimes
I'd answer clarifying questions. Sometimes I'd just watch it confidently
do the wrong thing because it had no context to work from.

That re-establishment isn't free. Every clarification, every correction,
every "no, I already decided to use X not Y" costs tokens. It happens
at the start of every session, every day, across every project.

kiro-recall front-loads a small, targeted context injection once per
session. Atomic permanent notes are concise by design, one idea per
note. The session hook runs once and stops. What it replaces is
typically far more expensive in both credits and time, but that's
one of the things I want testers to actually measure and report back on. I will be conducting my own A/B testing in regards to this.

The difference with kiro-recall specifically is the hook. Every other
approach still requires you to remember to load the context.
kiro-recall makes it impossible to forget.

How it works

The vault structure

The scaffold hook creates this structure on first run, wherever you
point it. Your vault can live anywhere on your machine, a dedicated
folder in Documents, alongside your dev projects, wherever makes sense
for you. You configure the path once in mcp.json and that's it.

vault/
├── 00-inbox/          # /recall writes here
├── 01-projects/       # one file or subfolder per active project
├── 02-job-search/
├── 03-learning/
├── 04-knowledge/
├── 05-community/
├── 06-permanent/      # atomic Zettelkasten notes — loaded every session
└── 07-templates/

This structure is opinionated. It's based on my own workflow as an
AWS Community Builder juggling job applications, learning, and community
work alongside dev projects. The folders that actually drive kiro-recall's
behaviour are only three: 00-inbox/, 01-projects/, and 06-permanent/.
The rest is suggested organisation. Rename them, ignore them, add your own.
The vault is just a folder, it's yours.

Relevance detection

The session start hook runs a four-stage Relevance Detector before injecting anything:

Stage 1 - Primary signal. The hook extracts the workspace folder
name (e.g. kiro-recall from C:\Dev\kiro-recall or
/Users/mike/projects/kiro-recall) and checks whether a matching file
or subfolder exists in 01-projects/. If it finds one, it loads that
project note plus all permanent notes and stops.

Stage 2 - Secondary signal. If no primary match, it scans the paths
of all open files in the workspace. Any path segment that matches a
project folder name in 01-projects/ resolves the project. It also
checks .kiro/steering/ for a project field as a fallback within
this stage.

Stage 3 - Fallback. No project match found. Load all permanent notes
from 06-permanent/ and inject those.

Stage 4 - Cold vault. If 06-permanent/ and 00-inbox/ are both
empty, skip injection entirely and show a warm onboarding message
instead of an error.

A generic name guard runs before Stage 1. Workspace names like src,
dev, app, repo skip primary matching entirely and go straight to
secondary signals. This prevents false matches on common folder names.

The hook files

Each hook is a .kiro.hook JSON file. Here's the structure:

{
  "name": "kiro-recall: Session Start",
  "version": "1.0.0",
  "when": {
    "type": "promptSubmit"
  },
  "then": {
    "type": "askAgent",
    "prompt": "..."
  }
}

The promptSubmit event fires on every prompt, so the session start
hook includes a once-per-session guard. On the first prompt it runs
the full Relevance Detector and injects context. On every subsequent
prompt in the same session it exits immediately. You get context once,
cleanly, at the start.

The capture and promote hooks use userTriggered instead. They sit
quietly until you need them, type /recall mid-session to capture
a note, or /promote to move an inbox note into your permanent
knowledge base.

The MCP dependency

kiro-recall wraps @bitbonsai/mcpvault
for vault access.

The original choice was smithery-ai/mcp-obsidian, but it only exposed
two tools and had no active maintenance. mcpvault ships 14 tools
including write_note, search_notes, read_multiple_notes, and
move_note, everything the hooks need to read, write, and reorganise
your vault. It reads any directory of markdown files directly from disk,
which means no Obsidian install required and no dependency on any
proprietary format.

One configuration line is all it needs:

{
  "mcpServers": {
    "mcpvault": {
      "command": "npx",
      "args": ["-y", "@bitbonsai/mcpvault", "YOUR_VAULT_PATH_HERE"]
    }
  }
}

Replace YOUR_VAULT_PATH_HERE with the path to your vault folder and
you're connected. The vault path is the only configuration required.
Everything else is derived from the folder structure at runtime.

The promote flow

The /promote hook is the most interesting piece of v0.1.0.

/recall is fast and low-friction by design. You dump a rough note
into 00-inbox/ and move on. But rough notes don't load well as
context, they're messy, multi-topic, and hard for the model to use.
Permanent notes need to be atomic. One idea, clearly stated, with
connections to related concepts.

/promote does that reformatting for you. It lists your inbox notes,
you pick one, and the hook rewrites it as a proper Zettelkasten permanent
note with a fixed structure:

# {Idea Title}

## The idea
{single atomic statement, 1-2 sentences}

## Why it matters
{significance or future relevance, 1-2 sentences}

## Connected to
{[[wikilink]] references}

## Source
{project}, {session description}, {YYYY-MM-DD}

The filename is derived from the idea title using kebab-case with no
date prefix. Permanent notes are evergreen, the filename reflects the
idea, not when it was written. A note called
relevance-detection-via-workspace-name.md is still findable and
meaningful in two years. A note called 2026-03-20-session-notes.md
is not.

After writing to 06-permanent/, the hook deletes the original from
00-inbox/. If the write fails, it surfaces the full reformatted note
in a code block so nothing is lost. If the delete fails after a
successful write, it warns you but doesn't roll back. The promoted
note already exists in permanent, so the worst case is a duplicate
in your inbox that you can delete manually.

Installing it

kiro-recall ships as a Kiro Power and is installable right now directly
from GitHub.

Open Kiro IDE and go to the Powers panel
Click Add power from GitHub
Paste https://github.com/mikeartee/kiro-recall
Once installed, open the Powers config and update the power-kiro-recall-mcp-obsidian entry - replace YOUR_VAULT_PATH_HERE with the full path to your vault folder
Restart Kiro or reconnect the MCP server from the MCP Servers panel
Trigger the Vault Scaffold hook once from the Hooks panel to create your folder structure
Start a new session - the session start hook fires automatically on your first prompt

From the next session onwards, context loads automatically.

What it produces

After the session start hook runs, you see exactly one line:

Loaded kiro-recall note (primary match) + 3 permanent notes.

No file paths. No diagnostic output. Just a confirmation of what was loaded and how it was matched.

After /recall:

Note saved: 2026-03-20-kiro-recall-promote-flow-decision.md. It's in your inbox whenever you're ready to review it.

After /promote:

Promoted to `06-permanent/relevance-detection-via-workspace-name.md`.

The vault fills itself as a side effect of your normal dev workflow. Over time it becomes a searchable record of every decision, pattern, and insight across all your projects.

I need testers. Windows and Mac both welcome.

Some things I want feedback on:

Does it work on your machine?
Does the vault context actually change how your sessions feel?
Does it use less credits in Kiro IDE on tasks?
What would you add or change?
Was it easy to install?

Install via Add Power from GitHub in Kiro IDE:
https://github.com/mikeartee/kiro-recall

About the author

Mike Rewiri-Thorsen is an AWS Community Builder in the AI Engineering
track, based in Palmerston North, Aotearoa New Zealand. He builds agentic AI tooling and cloud infrastructure, and shares the work publicly as he goes.

Follow along on GitHub and LinkedIn.

References

bitbonsai. (2026). mcpvault: MCP server for markdown vaults. GitHub. https://github.com/bitbonsai/mcpvault