DEV Community: Nick Taylor

Stop Shipping Broken Env Config

Nick Taylor — Tue, 10 Mar 2026 14:28:56 +0000

I first hung out with the Varlock team back in late August 2025, so this is not brand new to me. But while wiring it into an Astro project recently, I had the same reaction I always have after cleaning up env handling: I should have done this sooner.

Most teams start with .env files and a few runtime checks. That works for a while, until it does not. Someone forgets a key in CI. A value is malformed in production. A secret accidentally gets logged. Then you are debugging config problems instead of shipping.

Varlock gives you a schema-first workflow for environment variables, with validation and safer defaults. In Astro projects, the integration is clean and built on top of the Vite plugin.

dmno-dev / varlock

AI-safe .env files: Schemas for agents, Secrets for humans.

Varlock

AI-safe .env files: Schemas for agents, Secrets for humans.

🤖 AI-safe config — agents read your schema, never your secrets
🔍 proactive leak scanning via varlock scan + git hooks
🔏 runtime protection — log redaction and leak prevention
🛡️ validation, coercion, type safety w/ IntelliSense
🌐 flexible multi-environment management — auto .env.* loading and explicit import
🔌 plugins to pull data from various backends (1Password, Infisical, AWS, Azure, GCP, HCP Vault, more!)

Unlike .env.example, your .env.schema is a single source of truth, built for collaboration, that will never be out of sync.

# @defaultSensitive=false @defaultRequired=infer @currentEnv=$APP_ENV
# ---
# our environment flag, will control automatic loading of `.env.xxx` files
# @type=enum(development, preview, production, test)
APP_ENV=development # default value, can override
# @type=port
API_PORT=8080 # non-sensitive values can be set directly

# API url including _expansion_ referencing another env var
# @type=url
API_URL=http://localhost:${API_PORT}

# sensitive api key,

…

View on GitHub

TL;DR

Use Varlock to define your environment contract in .env.schema.
Add the Astro integration with @varlock/astro-integration.
Validate locally and in CI with npx varlock load.
If you work with other Vite-based apps, @varlock/vite-integration is the foundation.
You catch config mistakes earlier and avoid expensive deploy churn.

Where `.env` workflows usually break

The usual pattern is familiar:

Keep secrets in .env.local
Keep a partial .env.example
Add manual checks in app startup
Hope .env.example stays in sync

The cracks show up quickly:

Drift between docs and reality
.env.example gets stale the minute someone adds a new variable and forgets to update it.
Validation is scattered
One variable is checked in server startup, another in a route handler, another not at all.
Bad feedback timing
You often learn about missing config at runtime, not at build/startup when you can fix it fast.
Risk of secret leaks
People print env values while debugging. It happens.

What got better right away

Varlock centers everything around a schema so your config has a single source of truth. Instead of treating env as untyped key-value noise, you define expectations up front.

In practice, that means:

Required values are explicit
Types and rules are explicit
Validation happens before your app gets far enough to do damage
Sensitive values can be redacted from logs/output

This is the part I like most: it moves config errors from "mystery bug in prod" to "clear error in dev/CI."

Setting it up in Astro

If you're in an Astro project, this is the fastest path:

npx astro add @varlock/astro-integration

That wires in the integration and updates your Astro config.

Then initialize Varlock:

npx varlock init

If you already have existing env files, init can help bootstrap your schema from what is there.

If required values are missing, you get actionable errors immediately. Here is a real fail-fast example from my build logs for my personal site when a required env var was missing:

🚨 🚨 🚨 Configuration is currently invalid 🚨 🚨 🚨
Invalid items:
❓ TURSO_AUTH_TOKEN* 🔐sensitive
└ undefined
- Value is required but is currently empty
💥 Resolved config/env did not pass validation 💥
🚨 initVarlockEnv failed 🚨

This was the biggest win for me. I hit missing env vars during setup, and Varlock made those failures obvious early instead of letting them turn into runtime bugs. It also let me delete a bunch of defensive "does this env var exist" checks in app code because the schema and validation now handle that upfront.

I also opened a PR on my personal site while doing this migration. If you want a concrete implementation reference, here it is:

chore: add environment configuration and integrate varlock #22

nickytonline posted on Aug 21, 2025

This pull request introduces environment variable management using the Varlock library and its Astro integration. It standardizes how environment variables are accessed throughout the codebase, improves type safety, and updates configuration files and dependencies accordingly.

Related Live Stream:

Environment variable management and configuration:

Added .env.schema file with Varlock annotations to define and document required environment variables, their types, and defaults. This enables type generation and validation for environment variables.
Added .env.development with a URL variable referencing the PORT variable for local development.

Dependency and integration updates:

Added @varlock/astro-integration and varlock to package.json dependencies to enable Varlock environment management.
Updated astro.config.mjs to use the Varlock Astro integration and set the server port from the ENV.PORT variable.

Codebase refactoring for environment variable usage:

Replaced direct usage of import.meta.env with ENV from varlock/env in both src/pages/feed.ts and src/pages/index.astro, ensuring consistent and type-safe access to environment variables. [1] [2]

View on GitHub

That is exactly the behavior I want. Stop immediately, show me what is wrong, and do not let a bad config sneak into a deploy.

Quick note on Astro + Vite

Astro uses Vite under the hood, and Varlock leans on that.

I like this approach. @varlock/astro-integration stays thin, most of the logic lives in @varlock/vite-integration, and that usually means fewer weird bugs and less maintenance.

So even if you start with Astro, you are learning a model that transfers well.

The setup flow I recommend

Here is a workflow I would recommend for personal projects and teams.

Define your schema first. Treat .env.schema like API contract documentation for your app config.
- Mark required values as required
- Add validation constraints where obvious
- Keep non-sensitive defaults where appropriate
Keep local secrets local. Be explicit about your current setup. Right now, I still keep local secrets in a plaintext .env file 🙈 (on my TODO list to move to 1Password), and in deploys those values come from Netlify environment configuration.
Run validation early. Run npx varlock load locally.
Fail fast in CI. If config is broken, the build should fail before deploy.
Use typed env access when available. Where it fits your codebase, use Varlock’s typed env access instead of reading raw process.env values everywhere.

Example CI step

If your build/check already initializes Varlock (like Astro config loading does), you do not need a separate npx varlock load in that same job.

Use npx varlock load as an explicit precheck when you want to fail fast before heavier steps, or when another job/step needs validated env without running your full app init path.

# Option A: rely on your normal build if it already initializes Varlock
- name: Build
  run: npm run build

# Option B: explicit precheck before build (optional)
- name: Validate environment with Varlock
  run: npx varlock load
- name: Build
  run: npm run build

One Astro config gotcha this fixes

In many setups, using env values inside config files is awkward because loading order can get weird. With Varlock integrated, that experience is much cleaner because env loading and validation are already part of the flow.

That can reduce the number of one-off workarounds in astro.config.* and keep configuration logic more predictable.

This is not just a convenience thing

Varlock is a productivity win, but it is also a security and reliability win.

It reduces accidental secret exposure during debugging
It encourages explicit handling of sensitive values
It lowers the chance of deploying with bad or partial config

I think a lot of env tooling gets treated like "nice to have." I disagree. Configuration bugs can take down production just as effectively as code bugs.

Astro integration or Vite plugin?

Use @varlock/astro-integration when you are in an Astro app and want the smoothest native setup.
Use @varlock/vite-integration for non-Astro Vite projects.

If your stack includes multiple frameworks, it is good to know they can share the same core model.

Final thoughts

If your current env strategy is "it mostly works," Varlock is worth trying. It feels like a small upgrade until it prevents the next deployment headache.

In my opinion, schema-first env management should be the default for modern JavaScript projects, especially where AI tools and automation are involved and you want strong guardrails around secrets.

When would I skip this? Tiny throwaway scripts with no real deploy surface. For anything that ships, this is worth it.

If you want to see the walkthrough that motivated this post, here is the video:

Also give them some love over on the Syntax YouTube channel, they were on there recently too!

One thing worth calling out from their broader direction is that they are working on better support for other languages, including automatic type generation from your schema for various languages. That is a big deal if your stack is not purely JavaScript.

Useful links

Varlock: https://varlock.dev
@varlock/astro-integration: https://www.npmjs.com/package/@varlock/astro-integration
@varlock/vite-integration: https://www.npmjs.com/package/@varlock/vite-integration
Other language support roadmap: https://varlock.dev/integrations/other-languages/

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Want to stay updated with tech tips? Check out my newsletter:
OneTipAWeek.com

Clawspace: A Browser-Based File Explorer for OpenClaw

Nick Taylor — Mon, 09 Mar 2026 00:09:36 +0000

I've been working with OpenClaw for a while now. If you're not familiar, it's a self-hosted personal AI assistant that answers you on the channels you already use: WhatsApp, Telegram, Discord, Slack, iMessage, and a lot more. Local, fast, and always-on. One thing that kept coming up for me personally was the need to inspect and edit workspace files without jumping into an SSH session or opening a terminal. It's my own friction point, but if you're an OpenClaw user I suspect I'm not alone.

So I built Clawspace.

nickytonline / clawspace

Clawspace is a browser-based file explorer/editor for an OpenClaw workspace.

Clawspace

Clawspace is a browser-based file explorer/editor for an OpenClaw workspace.

It gives you:

File and directory browsing (/workspace)
Timeline view (/timeline) with folder filters and pagination
Configurable default home view for / (Files or Timeline)
Monaco editor for text files
Save/revert/copy actions
Auto-format on blur (supported file types)
Basic hardening for writes (path checks, blocked files, audit log)

Why this exists

OpenClaw users often want a fast, authenticated UI to inspect and edit workspace files without opening SSH/terminal sessions.

Clawspace is designed to run on your LAN, or behind a trusted auth proxy (for example Pomerium + OpenClaw trusted-proxy mode).

Install

git clone https://github.com/nickytonline/clawspace
cd clawspace
npm install

Quick start

npm run build
npm run clawspace:serve

Default port is 6789.

Development

npm run dev

Configuration

Clawspace uses the parent of the app directory as the workspace root by default If you install it elsewhere,…

View on GitHub

Clawspace is a browser-based file explorer and editor for an OpenClaw workspace.

It runs as a lightweight server, gives you a Monaco editor (the same editor that powers VS Code) for text files, and handles the basics you'd want: browsing directories, saving, reverting, deleting, and copying files, and auto-formatting on blur for supported file types. Internal OpenClaw files like SOUL.md are protected and can't be deleted or modified.

Why not just use SSH?

You could. But if you're already running OpenClaw and you want to make a quick edit to a config file or peek at a log, having a UI that loads in your browser is faster than reaching for a terminal. It also fits nicely into situations where the person using the workspace isn't a developer who wants to context-switch into a shell. I find this super handy on my phone.

For my setup, I run it with Pomerium in front of it. Pomerium is an open core identity-aware proxy that handles the authentication layer, so Clawspace never has to think about it. I actually implemented Trusted Proxy Auth mode in OpenClaw to make this work cleanly. (The hardening guide was written before Trusted Proxy Auth mode existed, so I'm in the process of updating it.)

feat(gateway): add trusted-proxy auth mode #15940

nickytonline posted on Feb 14, 2026

Summary

Adds a new trusted-proxy auth mode that delegates authentication to a reverse proxy (Pomerium, Caddy, nginx + OAuth, etc.). This allows Clawdbot to run behind identity-aware proxies or reverse proxies without requiring token auth in WebSocket payloads.

Closes #1560 Relates to #1710

Changes

Types & Schema

Add trusted-proxy to GatewayAuthMode union
Add GatewayTrustedProxyConfig type with userHeader, requiredHeaders, allowUsers
Update zod schema with validation

Auth Logic

Add authorizeTrustedProxy() helper function
Update authorizeGatewayConnect() to handle trusted-proxy mode
Validate proxy source IP against gateway.trustedProxies
Support required headers and user allowlist

Runtime Guards

Allow non-loopback bind with trusted-proxy mode
Reject trusted-proxy + loopback combination
Require trustedProxies to be configured

Security Audit

Add critical finding when trusted-proxy auth is enabled
Flag missing trustedProxies or userHeader configuration
Warn when allowUsers is empty

Tests

10 new auth tests covering all trusted-proxy scenarios
4 new security audit tests

Documentation

New doc page: /gateway/trusted-proxy-auth
Examples for Pomerium, Caddy, nginx, Traefik
Security checklist and troubleshooting guide

Example Config

{
  gateway: {
    bind: "lan",
    trustedProxies: ["10.0.0.1"],
    auth: {
      mode: "trusted-proxy",
      trustedProxy: {
        userHeader: "x-pomerium-email"
      }
    }
  }
}

Screenshots and Recordings

CLI in Action

https://github.com/user-attachments/assets/e500cef8-988c-459e-8e9e-16af8a33dc9e

Overview page when trusted proxy mode is enabled

Removed the Gateway Token field entirely when trusted proxy mode is active
Updated the helper text next to the Connect/Refresh buttons - when in trusted proxy mode it now shows "Authenticated via trusted proxy."

Security Considerations

Per maintainer guidance, this is an explicit opt-in feature with:

Strict trust boundary (only accepts headers from configured trustedProxies IPs)
No silent fallback (rejects if proxy headers missing)
Audit warnings to ensure users understand the security implications
Clear documentation about when to use and when NOT to use

Testing

npm test -- src/gateway/auth.test.ts
npm test -- src/security/audit.test.ts

All 20 auth tests and 40 security audit tests pass.

Greptile Overview

Greptile Summary

Adds trusted-proxy authentication mode that delegates authentication to reverse proxies (Pomerium, Caddy, nginx + OAuth). The implementation correctly handles the security boundaries with IP-based trust validation, required header checks, and user allowlists. All auth flows validate that requests originate from configured trustedProxies before trusting proxy headers.

Key changes:

Added trusted-proxy to GatewayAuthMode union with comprehensive type definitions and zod validation
Implemented authorizeTrustedProxy() helper with multi-layered validation (source IP, required headers, user allowlist)
Added runtime guards preventing dangerous configurations (rejects loopback binding, requires trustedProxies config)
Implemented CIDR notation support in isTrustedProxyAddress() for flexible subnet matching
Added comprehensive security audit checks (critical severity for trusted-proxy mode with detailed remediation)
Updated UI to hide token/password fields when trusted-proxy mode is active
Extensive test coverage (10 auth tests, 4 audit tests, net.ts CIDR tests, runtime config tests)
Well-documented with examples for Pomerium, Caddy, nginx, and Traefik

Security posture: The implementation follows defense-in-depth principles with strict validation at multiple layers. The trusted-proxy auth bypasses rate limiting (returns early at src/gateway/auth.ts:314-332), which is appropriate since the proxy handles auth. All validation happens before processing requests, and failure modes are explicit with clear error reasons.

Confidence Score: 5/5

This PR is safe to merge with minimal risk.
The implementation demonstrates excellent security engineering with defense-in-depth validation, comprehensive test coverage (20+ tests across auth, net, audit, and runtime config), proper error handling, and clear documentation. The trusted-proxy auth logic correctly validates source IPs before trusting headers, preventing header injection attacks. Runtime guards prevent dangerous misconfigurations. The CIDR implementation has edge case validation. All changes follow the repository's coding standards and include appropriate security audit warnings.
No files require special attention. The implementation is production-ready.

Last reviewed commit: a1e1c19

View on GitHub

Getting started

The only real requirement is that Clawspace has access to the root of your OpenClaw workspace. How you get there is up to you: npm scripts or the Docker image both work fine.

Via npm:

git clone https://github.com/nickytonline/clawspace
cd clawspace
npm install
npm run build
npm run clawspace:serve

Default port is 6789.

Or via Docker, mounting your workspace volume:

clawspace:
  image: ghcr.io/nickytonline/clawspace:latest
  environment:
    CLAWSPACE_ROOT: /claw/workspace
    CLAWSPACE_IGNORE: ".pnpm,dist,logs"
    SHOW_INTERNAL_CLAW_FILES: "false"
  volumes:
    - ./openclaw-data/workspace:/claw/workspace
  ports:
    - "6789:6789"

I currently run Clawspace inside my workspace rather than as a separate container, mostly because it lets me iterate on it in real time while pairing with OpenClaw. Since it's built with Astro, running npm run dev gives you instant updates via Vite, so I can make changes and see them immediately without an editor, just me and OpenClaw going back and forth. For most people though, the container approach is probably cleaner.

Configuration

By default, Clawspace uses the parent of the app directory as the workspace root. You can override that with an environment variable.

# .env (see .env.example)
CLAWSPACE_ROOT=/absolute/path/to/workspace
CLAWSPACE_IGNORE=".pnpm,dist,logs"
SHOW_INTERNAL_CLAW_FILES=false

The CLAWSPACE_IGNORE variable takes comma-separated patterns, and those get merged with hardcoded defaults (.git, node_modules, etc.), your .gitignore, and a .clawspace-ignore file if you have one at the workspace root.

SHOW_INTERNAL_CLAW_FILES controls whether things like SOUL.md, MEMORY.md, and .env show up in the file browser. Default is false, which is what you want most of the time.

Security

Clawspace assumes network-level auth is handled externally. It's not trying to be a multi-user app with roles and admin checks. File writes are restricted to the workspace root, internal and sensitive files are blocked, and all writes get audited to /claw/workspace/logs/clawspace-edit-audit.log.

If you're exposing it beyond your LAN, put it behind a proxy you trust. I expose mine to the internet using Trusted Proxy Auth mode, with Pomerium as the identity-aware proxy in front of it, so authentication is handled before a request ever reaches Clawspace.

It's meant to be tweaked

Clawspace is intentionally hackable. The README says it plainly: clone it, edit the UI and guardrails, make it yours. It's a starting point for the kind of workspace tooling that fits how you work, not a finished product trying to cover every case.

Fun fact: the look and feel is based on nickyt.co, my personal site. I paired with OpenClaw to build it, which felt like a nice proof of the thing I was building the tool for in the first place.

If you give it a try or have ideas for it, I'd love to hear what you think.

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Let Dependabot Merge Its Own PRs

Nick Taylor — Sun, 08 Mar 2026 18:16:29 +0000

Dependabot opens PRs automatically. That part most people have set up. But then those PRs just sit there until you get around to reviewing and merging them. I had 6 open across one of my repos recently. None of them were risky. I just didn't feel like giving a review and approving, then merging.

If your CI passes and the update is a patch or minor version bump, there's not much to review. You're going to merge it. So why not let it happen automatically?

I've added this to two repos now and it's one of those small things that quietly removes friction from your day.

First, enable auto-merge on your repo

Before the workflow can do anything, you need to allow auto-merge in your repository settings. Go to e.g. https://github.com/yourorg-username/your-repo/settings/actions and scroll down to the Pull Requests section, and check Allow auto-merge.

This isn't Dependabot-specific, but it is required for this to work. Without it, the gh pr merge --auto command in the workflow will fail. In fact this is what I do to automate using dev.to as a headless CMS for my blog!

Nick Taylor

Nov 6 '22

Automate and Auto-Merge Pull Requests using GitHub Actions and the GitHub CLI

#github #githubcli #githubactions #git

Comments

5 min read

The workflow

Create .github/workflows/auto-merge-dependabot.yml in your repo:

name: Auto-merge Dependabot PRs

on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  auto-merge:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Approve PR
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Enable auto-merge
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The if: github.actor == 'dependabot[bot]' condition makes sure this only runs on Dependabot PRs, not every PR that comes in.

The two steps do exactly what they say: approve the PR, then enable auto-merge with squash. GitHub handles the actual merge once all your required checks pass.

Here's an example of it not auto-merging after auto-approval because checks failed.

chore(deps-dev): bump eslint from 9.39.2 to 10.0.3 #809

dependabot[bot] posted on Mar 08, 2026

Bumps eslint from 9.39.2 to 10.0.3.

Release notes

Sourced from eslint's releases.

v10.0.3

Bug Fixes

e511b58 fix: update eslint (#20595) (renovate[bot])

f4c9cf9 fix: include variable name in no-useless-assignment message (#20581) (sethamus)

ee9ff31 fix: update dependency minimatch to ^10.2.4 (#20562) (Milos Djermanovic)

Documentation

9fc31b0 docs: Update README (GitHub Actions Bot)

4efaa36 docs: add info box for eslint-plugin-eslint-comments (#20570) (DesselBane)

23b2759 docs: add v10 migration guide link to Use docs index (#20577) (Pixel998)

80259a9 docs: Remove deprecated eslintrc documentation files (#20472) (Copilot)

9b9b4ba docs: fix typo in no-await-in-loop documentation (#20575) (Pixel998)

e7d72a7 docs: document TypeScript 5.3 minimum supported version (#20547) (sethamus)

Chores

ef8fb92 chore: package.json update for eslint-config-eslint release (Jenkins)

e8f2104 chore: updates for v9.39.4 release (Jenkins)

5cd1604 refactor: simplify isCombiningCharacter helper (#20524) (Huáng Jùnliàng)

70ff1d0 chore: eslint-config-eslint require Node ^20.19.0 || ^22.13.0 || >=24 (#20586) (Milos Djermanovic)

e32df71 chore: update eslint-plugin-eslint-comments, remove legacy-peer-deps (#20576) (Milos Djermanovic)

53ca6ee chore: disable eslint-comments/no-unused-disable rule (#20578) (Milos Djermanovic)

e121895 ci: pin Node.js 25.6.1 (#20559) (Milos Djermanovic)

efc5aef chore: update tsconfig.json in eslint-config-eslint (#20551) (Francesco Trotta)

v10.0.2

Bug Fixes

2b72361 fix: update ajv to 6.14.0 to address security vulnerabilities (#20537) (루밀LuMir)

Documentation

13eeedb docs: link rule type explanation to CLI option --fix-type (#20548) (Mike McCready)

98cbf6b docs: update migration guide per Program range change (#20534) (Huáng Jùnliàng)

61a2405 docs: add missing semicolon in vars-on-top rule example (#20533) (Abilash)

Chores

951223b chore: update dependency @eslint/eslintrc to ^3.3.4 (#20553) (renovate[bot])

6aa1afe chore: update dependency eslint-plugin-jsdoc to ^62.7.0 (#20536) (Milos Djermanovic)

v10.0.1

Bug Fixes

c87d5bd fix: update eslint (#20531) (renovate[bot])

d841001 fix: update minimatch to 10.2.1 to address security vulnerabilities (#20519) (루밀LuMir)

04c2147 fix: update error message for unused suppressions (#20496) (fnx)

38b089c fix: update dependency @eslint/config-array to ^0.23.1 (#20484) (renovate[bot])

Documentation

5b3dbce docs: add AI acknowledgement section to templates (#20431) (루밀LuMir)

6f23076 docs: toggle nav in no-JS mode (#20476) (Tanuj Kanti)

b69cfb3 docs: Update README (GitHub Actions Bot)

Chores

... (truncated)

Commits

bfce7ea 10.0.3
d44ced8 Build: changelog update for 10.0.3
e511b58 fix: update eslint (#20595)
ef8fb92 chore: package.json update for eslint-config-eslint release
e8f2104 chore: updates for v9.39.4 release
5cd1604 refactor: simplify isCombiningCharacter helper (#20524)
9fc31b0 docs: Update README
70ff1d0 chore: eslint-config-eslint require Node ^20.19.0 || ^22.13.0 || >=24 (#20586)
f4c9cf9 fix: include variable name in no-useless-assignment message (#20581)
4efaa36 docs: add info box for eslint-plugin-eslint-comments (#20570)
Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

View on GitHub

Note: GITHUB_TOKEN is automatically available in every GitHub Actions workflow, no setup needed on your end.

What it looks like

Once it's set up and a Dependabot PR comes in, you'll see the github-actions bot approve the PR and enable auto-merge. The PR then waits for your required checks to complete and merges itself when everything is green.

A note on safety

This setup is only as safe as your CI. If you don't have required checks configured, the PR can auto-merge the moment the workflow approves it. At a minimum you want a build check required, tests if you have them. Branch protection rules still apply. If a required check fails, the PR won't merge. The workflow isn't bypassing anything, it's just handling the approval and queuing up the merge for you.

Being more selective

This workflow approves and enables auto-merge on every Dependabot PR regardless of whether it's a patch, minor, or major update. If you want to be more selective, you can use the dependabot/fetch-metadata action to check the update type and only proceed for patch and minor updates. The GitHub docs on automating Dependabot cover that in more detail.

If you want to see a PR that went through this whole flow check out the PR below.

chore(deps): bump rollup from 4.54.0 to 4.59.0 #790

dependabot[bot] posted on Feb 28, 2026

Bumps rollup from 4.54.0 to 4.59.0.

Release notes

Sourced from rollup's releases.

v4.59.0

4.59.0

2026-02-22

Features

Throw when the generated bundle contains paths that would leave the output directory (#6276)

Pull Requests

#6275: Validate bundle stays within output dir (@lukastaegert)

v4.58.0

4.58.0

2026-02-20

Features

Also support __NO_SIDE_EFFECTS__ annotation before variable declarations declaring function expressions (#6272)

Pull Requests

#6256: docs: document PreRenderedChunk properties including isDynamicEntry and isImplicitEntry (@njg7194, @lukastaegert)

#6259: docs: Correct typo and improve sentence structure in docs for output.experimentalMinChunkSize (@millerick, @lukastaegert)

#6260: fix(deps): update rust crate swc_compiler_base to v47 (@renovate[bot], @lukastaegert)

#6261: fix(deps): lock file maintenance minor/patch updates (@renovate[bot], @lukastaegert)

#6262: Avoid unnecessary cloning of the code string (@lukastaegert)

#6263: fix(deps): update minor/patch updates (@renovate[bot], @lukastaegert)

#6265: chore(deps): lock file maintenance (@renovate[bot])

#6267: fix(deps): update minor/patch updates (@renovate[bot])

#6268: chore(deps): update dependency eslint-plugin-unicorn to v63 (@renovate[bot], @lukastaegert)

#6269: chore(deps): update dependency lru-cache to v11 (@renovate[bot])

#6270: chore(deps): lock file maintenance (@renovate[bot])

#6272: forward NO_SIDE_EFFECTS annotations to function expressions in variable declarations (@lukastaegert)

v4.57.1

4.57.1

2026-01-30

Bug Fixes

Fix heap corruption issue in Windows (#6251)

Ensure exports of a dynamic import are fully included when called from a try...catch (#6254)

Pull Requests

#6251: fix: Isolate and cache process.report.getReport() calls in a child process for robust environment detection (@alan-agius4, @lukastaegert)

... (truncated)

Changelog

Sourced from rollup's changelog.

4.59.0

2026-02-22

Features

Throw when the generated bundle contains paths that would leave the output directory (#6276)

Pull Requests

#6275: Validate bundle stays within output dir (@lukastaegert)

4.58.0

2026-02-20

Features

Also support __NO_SIDE_EFFECTS__ annotation before variable declarations declaring function expressions (#6272)

Pull Requests

#6256: docs: document PreRenderedChunk properties including isDynamicEntry and isImplicitEntry (@njg7194, @lukastaegert)

#6259: docs: Correct typo and improve sentence structure in docs for output.experimentalMinChunkSize (@millerick, @lukastaegert)

#6260: fix(deps): update rust crate swc_compiler_base to v47 (@renovate[bot], @lukastaegert)

#6261: fix(deps): lock file maintenance minor/patch updates (@renovate[bot], @lukastaegert)

#6262: Avoid unnecessary cloning of the code string (@lukastaegert)

#6263: fix(deps): update minor/patch updates (@renovate[bot], @lukastaegert)

#6265: chore(deps): lock file maintenance (@renovate[bot])

#6267: fix(deps): update minor/patch updates (@renovate[bot])

#6268: chore(deps): update dependency eslint-plugin-unicorn to v63 (@renovate[bot], @lukastaegert)

#6269: chore(deps): update dependency lru-cache to v11 (@renovate[bot])

#6270: chore(deps): lock file maintenance (@renovate[bot])

#6272: forward NO_SIDE_EFFECTS annotations to function expressions in variable declarations (@lukastaegert)

4.57.1

2026-01-30

Bug Fixes

Fix heap corruption issue in Windows (#6251)

Ensure exports of a dynamic import are fully included when called from a try...catch (#6254)

Pull Requests

#6251: fix: Isolate and cache process.report.getReport() calls in a child process for robust environment detection (@alan-agius4, @lukastaegert)

#6252: chore(deps): update dependency lru-cache to v11 (@renovate[bot])

#6253: chore(deps): lock file maintenance minor/patch updates (@renovate[bot], @lukastaegert)

#6254: Fully include dynamic imports in a try-catch (@lukastaegert)

... (truncated)

Commits

ae84695 4.59.0
b39616e Update audit-resolve
c60770d Validate bundle stays within output dir (#6275)
33f39c1 4.58.0
b61c408 forward NO_SIDE_EFFECTS annotations to function expressions in variable decla...
7f00689 Extend agent instructions
e7b2b85 chore(deps): lock file maintenance (#6270)
2aa5da9 fix(deps): update minor/patch updates (#6267)
4319837 chore(deps): update dependency lru-cache to v11 (#6269)
c3b6b4b chore(deps): update dependency eslint-plugin-unicorn to v63 (#6268)
Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

View on GitHub

This has taken a whole category of busywork off my plate for my personal site and my Clawspace project.

nickytonline / nickytdotco

Source code for my web site nickyt.co

Nick Taylor's Personal Website

This is the source code for nickyt.co, Nick Taylor's personal website and blog.

Tech Stack

Astro - Modern web framework for building fast, content-focused websites
React - For interactive UI components
MDX - For blog posts and content with embedded components
Tailwind CSS - Utility-first CSS framework
TypeScript - Type-safe JavaScript
Expressive Code - Syntax highlighting for code blocks
Netlify - Hosting and deployment platform
Node.js 22+ - Runtime environment

Terminal commands

Install the dependencies first

npm install

Run in dev mode

npm run dev

Build a production version of the site

npm run build

Test the production site locally

npm run preview

Styling

Tailwind v4 is configured in tailwind.config.cjs and postcss.config.cjs.
Global styles are loaded from src/styles/tailwind.css, which imports src/styles/legacy.css for bespoke rules.

Licensing

This project contains two separate licenses:

Code License: The website's source code (in the project root and…

View on GitHub

nickytonline / clawspace

Clawspace is a browser-based file explorer/editor for an OpenClaw workspace.

Clawspace

Clawspace is a browser-based file explorer/editor for an OpenClaw workspace.

It gives you:

File and directory browsing (/workspace)
Timeline view (/timeline) with folder filters and pagination
Configurable default home view for / (Files or Timeline)
Monaco editor for text files
Save/revert/copy actions
Auto-format on blur (supported file types)
Basic hardening for writes (path checks, blocked files, audit log)

Why this exists

OpenClaw users often want a fast, authenticated UI to inspect and edit workspace files without opening SSH/terminal sessions.

Clawspace is designed to run on your LAN, or behind a trusted auth proxy (for example Pomerium + OpenClaw trusted-proxy mode).

Install

git clone https://github.com/nickytonline/clawspace
cd clawspace
npm install

Quick start

npm run build
npm run clawspace:serve

Default port is 6789.

Development

npm run dev

Configuration

Clawspace uses the parent of the app directory as the workspace root by default If you install it elsewhere,…

View on GitHub

For work projects there would probably be some push back on this potentially, but if you have a really great CI/CD pipeline with checks, definitely consider doing this or at least having a discussion with your team.

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Stop using cat

Nick Taylor — Mon, 02 Mar 2026 02:08:25 +0000

If you use cat in your daily workflow, this is a tiny upgrade with lots of upsides and honestly, no downsides aside from you need to install it as it’s not native.

What is bat?

bat is a cat alternative with syntax highlighting and line numbering to name a few features while being a drop in replacement to workflows you have that use regular cat.

Install

# macOS
brew install bat

# Ubuntu / Debian
sudo apt install bat

# via installation script
curl -s https://sh.rustup.rs | bat

Just FYI, once it’s installed, on some Linux distros, the binary is named batcat.

Six practical ways to use `bat`

By default you get all the bat goodness when you don’t specify any flags. Syntax highlighting, line numbering etc. Here’s some common use cases.

Read config files quickly

bat ./astro.config.mjs

With cat:

With bat:

You get visual structure without opening an editor.

Show line numbers while debugging

bat -n src/server.ts

Line numbers make it much easier to point teammates to exact spots in a file.

Use plain mode for logs or scripts

bat -p logs/app.log

-p strips the decorations when you want cleaner output.

Focus on a line range

bat --line-range 40:120 src/index.ts

Great when you only need one section of a file.

Quickly review changed files

git diff --name-only | xargs bat

Useful for a quick scan of touched files before a commit or review.

Navigate large files with a pager

bat large-file.log

bat automatically pipes output through a pager like less when the file is longer than your terminal window. No need to manually pipe to less like you would with cat.

Should you alias `cat` to `bat`?

I alias it, because YOLO, but if you do run into issues, just alias it to something other than cat, or not at all.

alias c='bat'

TL;DR

bat is one of the easiest terminal upgrades you can make. If you read code, logs, or config files in the terminal every day, switching from cat to bat is a no brainer.

If you want to stay in touch, all my socials are on nickyt.online

Until the next one!

Five Git Config Settings Every Dev Needs

Nick Taylor — Tue, 10 Feb 2026 02:19:13 +0000

You've probably added some settings to your Git Configuration, but here are some you might not have configured. If you haven't set these up yet, you're doing more manual work than you need to.

Rebase on pull instead of merge

git config --global pull.rebase true

Every time you pull without this, Git creates a merge commit. Do that a few times a day across a team and your git log turns into a mess of "Merge branch 'main' into main" entries that tell you nothing. With rebase, your commits stay on top of the latest changes and your history actually reads like a coherent timeline.

Bonus: I do this a lot, g pull -r origin main (g is my shell alias for git) to keep my branch up to date with main. You can also add

git config --global branch.main.rebase true

and now I just do g pull origin main. Sure it's only two less characters, but one less thing for me to think about.

Auto set upstream on push

git config --global push.autoSetupRemote true

You create a new branch, do your work, push, and Git hits you with this:

fatal: The current branch my-branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin my-branch

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

Every single time. This setting makes that whole thing go away. Git sets the upstream automatically on your first push to a new branch.

Auto prune on fetch

git config --global fetch.prune true

Stale remote branches pile up silently. Someone merged and deleted their branch weeks ago, but your local still shows it when you run git branch -r. This cleans out those dead references every time you fetch so your branch list reflects what actually exists on the remote.

I had this alias in my shell to prune local and remote branches.

rmmerged() {
  git branch --merged | grep -Ev "(\*|master|main)" | xargs -n 1 git branch -d && git remote prune origin
}

Now, it's simplified to only pruning local branches since the fetch prune setting handles remote ones.

rmmerged() {
  git branch --merged | grep -Ev "(\*|master|main)" | xargs -n 1 git branch -d
}

A better diff algorithm

git config --global diff.algorithm histogram

The default diff algorithm works, but histogram produces cleaner diffs when there are lots of similarly structured lines, think repeated return statements, closing braces, or blank lines. The default algorithm can get confused about which identical lines to match and produces diffs that interleave additions and deletions in ways that are hard to follow. Histogram handles that better. The bigger the file and the more repetitive the structure, the more noticeable the improvement. It's a drop-in upgrade with no downside.

Here's a fictitious example since I had a hard time finding a good example in my own recent commits showing the difference.

Myers Algorithm (Default)

diff --git a/tmp/example_before.js b/tmp/example_after.js
index 30d9ab3c..8ec95ef5 100644
--- a/tmp/example_before.js
+++ b/tmp/example_after.js
@@ -8,15 +8,10 @@ function validateUser(user) {
    if (!user.name) {
      return { error: 'Name is required' };
    }
-  return { valid: true };
-}
-
-function processData(data) {
-  const result = transform(data);
-  if (!result) {
-    return { error: 'Transform failed' };
+  if (!user.id) {
+    return { error: 'ID is required' };
    }
-  return result;
+  return { valid: true };
  }

  function validateProduct(product) {
@@ -26,13 +21,28 @@ function validateProduct(product) {
    if (!product.price) {
      return { error: 'Price is required' };
    }
+  if (!product.name) {
+    return { error: 'Name is required' };
+  }
    return { valid: true };
  }

+function processData(data) {
+  const result = transform(data);
+  if (!result) {
+    return { error: 'Transform failed' };
+  }
+  return result;
+}
+
  function saveToDatabase(item) {
    const connection = getConnection();
    if (!connection) {
      return { error: 'Database connection failed' };
    }
+  const validated = validateItem(item);
+  if (!validated) {
+    return { error: 'Validation failed' };
+  }
    return connection.save(item);
  }

Histogram Algorithm

diff --git a/tmp/example_before.js b/tmp/example_after.js
index 30d9ab3c..8ec95ef5 100644
--- a/tmp/example_before.js
+++ b/tmp/example_after.js
@@ -8,6 +8,22 @@ function validateUser(user) {
    if (!user.name) {
      return { error: 'Name is required' };
    }
+  if (!user.id) {
+    return { error: 'ID is required' };
+  }
+  return { valid: true };
+}
+
+function validateProduct(product) {
+  if (!product) {
+    return { error: 'Product is required' };
+  }
+  if (!product.price) {
+    return { error: 'Price is required' };
+  }
+  if (!product.name) {
+    return { error: 'Name is required' };
+  }
    return { valid: true };
  }

@@ -19,20 +35,14 @@ function processData(data) {
    return result;
  }

-function validateProduct(product) {
-  if (!product) {
-    return { error: 'Product is required' };
-  }
-  if (!product.price) {
-    return { error: 'Price is required' };
-  }
-  return { valid: true };
-}
-
  function saveToDatabase(item) {
    const connection = getConnection();
    if (!connection) {
      return { error: 'Database connection failed' };
    }
+  const validated = validateItem(item);
+  if (!validated) {
+    return { error: 'Validation failed' };
+  }
    return connection.save(item);
  }

Rerere

git config --global rerere.enabled true

Rerere stands for "reuse recorded resolution." When you resolve a merge conflict, Git remembers how you resolved it. The next time the same conflict comes up, Git applies your previous resolution automatically. If you've ever rebased a long-lived branch and had to resolve the same conflict over and over, this is the fix. It won't silently merge things for you in a way you can't review. It records your resolutions and replays them so you don't have to redo the same work.

Want to see what you currently have set? Run git config --global --list and see what's missing.

If you enjoy tips like this, I have a newsletter, OneTipAWeek.com. One developer tip a week. Short & valuable. That's it!

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Photo by Yancy Min on Unsplash

BenQ RD280UG Review: 28-Inch 4K Programming Monitor for Developers

Nick Taylor — Tue, 20 Jan 2026 12:48:00 +0000

This is a sponsored post, but it's an honest review.

BenQ sent me their new RD280UG monitor to review. They've sent me monitors in the past, and I've been a fan of their programming-focused lineup.

Nick Taylor

Apr 13 '25

BenQ RD280U Review: A 28" 4K Monitor Built for Developers

#review #benq #programmingmonitor #officesetup

Comments

4 min read

The 3:2 Aspect Ratio Thing

These monitors use a 3:2 aspect ratio instead of the standard widescreen format. When I got my first BenQ programming monitor about a year ago, the 28-inch 3:2 dimensions seemed odd. The aspect ratio was a little weird at first, but honestly, after a few days of using it, I was already used to it. I keep mine in the normal horizontal position, though you can rotate these monitors vertically if that's your thing.

What's New

The RD280UG is a 28-inch 4K monitor with a 3:2 aspect ratio, running at 3840 x 2560 pixels with a 120Hz refresh rate, up from the RD280U model's 60Hz. It works with both Mac and PC. I'm using it with my Mac for development and live streaming, and the aspect ratio hasn't caused any issues with streaming setups.

The new monitor keeps the features I liked from previous models. The moon halo lighting on the back is still there, and you can quickly switch display settings using the front button. Dark mode, light mode, and custom user settings are all available. You can also adjust blue light levels.

The big addition is the paper color mode. I've been testing it out and it's solid. It's designed to reduce eye strain and blue light. One caveat though: if you're doing UI development, you'll want to switch back to your regular settings since the colors won't be as vibrant. When I'm working on UI stuff, I just flip back to my normal dark theme.

I haven't noticed any eye strain while using this monitor, and the paper color mode seems to be doing its job well.

Assembly is straightforward, just like the previous model. No screwdriver needed. You flip open a thing, turn to tighten the base to the stand, and the monitor clicks into place.

There's a leather cable management piece that snaps together on the back to keep things tidy.

Small thing, but they include a cleaning cloth with the monitor. I've always been paranoid about what to use on monitors. I usually grab my glasses cloth and hope for the best, so having a dedicated one is appreciated.

Port Upgrades

This is where I discovered something cool. The ports are located to the right of the monitor settings button, just under the screen. You get a USB-C port, two USB-A ports, and a headphone jack if you're still into the wired world.

Funny thing is, I didn't even know my old monitor had ports there too. Turns out it did - just 3 USB-A ports, no USB-C. The RD280UG swaps one of those USB-A ports for USB-C. Right now I've got my watch charging via USB-C, my mic in one USB port, and my USB hub in the other.

I have the monitor connected via USB-C, though you can also use HDMI or DisplayPort if that's your preference. The port placement on the back is way more accessible than before and you can daisy chain monitors if you want multiple displays connected to your laptop or desktop.

The monitor also has built-in KVM functionality like previous models. I don't use it normally, but it's there if you need to switch between multiple computers with one set of peripherals. I'll probably use it when I connect my mini PC if I'm not SSHing into it or booting into Windows on it.

The Verdict

I've been using this for a week now. The 28-inch 3:2 aspect ratio continues to be great for programming work. The improved port accessibility, new paper color mode, and 120Hz refresh rate (up from 60Hz on the RD280U) are solid upgrades. The higher refresh rate makes scrolling through code noticeably smoother and the text is super clear on this monitor as well. A picture probably can't do that justice though. 😅

The RD280UG is priced at $759.99 (MSRP). You can check it out on Amazon or learn more on the BenQ website. If you're a dev and in the market for a new monitor, BenQ has got you set.

Thanks again BenQ for the monitor!

If you want to stay in touch, all my socials are on nickyt.online

From Fresh Mac to Productive in 30 Minutes

Nick Taylor — Sat, 03 Jan 2026 16:20:20 +0000

I've been hearing developers talk about their dotfiles for years. "Oh yeah, I just clone my dotfiles repo and I'm set up in minutes." I had some semblance of a setup script at one point, but I kinda just went with manual mode for fresh Mac setups.

Even if I had most apps installed with a script, weeks later when I needed a tool, I realized I forgot to install it. Also, macOS settings that I had are missing and I forget where to find them. One big hot mess of a fresh install.

I recently decided to wipe my Mac for a clean slate. I didn't want to spend days piecing my setup back together app by app, so I finally committed to creating a proper dotfiles repo. With a dash of AI, I was on my way to making a great install setup.

nickytonline / dotfiles

Dotfiles

My personal dotfiles and system configuration for macOS.

Brewfile - Homebrew packages, casks, and Mac App Store apps
shell/ - Shell configuration files (.zshrc, .zshenv, .zprofile, .bashrc, .profile)
git/ - Git configuration
ssh/ - SSH configuration (not keys!)
config/ - Application configs (starship, gh, atuin, etc.)
.npmrc - npm configuration
install.sh - Bootstrap script to set up a new machine
macos-defaults.sh - macOS system preferences and settings

Fresh macOS Installation

Prerequisites

Before starting, make sure you have:

Signed into your Apple ID
Installed pending macOS updates

Installation Steps

Clone this repository:

git clone https://github.com/nickytonline/dotfiles.git ~/dotfiles
cd ~/dotfiles

Run the install script:
```
chmod +x install.sh
./install.sh
```
The install script will:
- Install Xcode Command Line Tools
- Install Homebrew
- Create symlinks for all dotfiles
- Install Rust via rustup
- Install all packages from Brewfile (brew, casks, Mac App Store apps)
- Install Node.js LTS via fnm
- Install OpenAI Codex CLI via…

View on GitHub

Dotfiles to the Rescue

The concept is simple. All those configuration files that start with a dot (.zshrc, .gitconfig, etc.) can be version controlled and shared across machines.

A dotfiles repository is not macOS specific, but I wanted to go further, my whole Mac setup or most of it.

Here's what I ended up with:

~/dotfiles/
├── Brewfile              # Every app I use
├── install.sh            # One script to rule them all
├── macos-defaults.sh     # macOS system preferences
├── shell/                # Shell configs (.zshrc, etc.)
├── git/                  # Git configuration
├── ssh/                  # SSH config (no keys!)
└── config/               # App configs (starship, gh, atuin, etc.)

Brewfile's Got Your Apps' Backs

If you're on macOS and not using Homebrew, you're missing out. It's basically apt or yum for macOS.

What I didn't fully appreciate until this project was Homebrew's Brewfile feature. I knew it existed but never bothered to create one. If you already have Homebrew installed, you can generate a Brewfile from everything you currently have installed:

brew bundle dump

This creates a Brewfile in your current directory with all your brew packages, casks, Mac App Store apps.

Instead of running brew install commands one by one, you declare everything in a single file:

# CLI tools
brew "git"
brew "ripgrep"
brew "fnm"  # Node version manager - https://github.com/Schniz/fnm
brew "starship"  # Beautiful shell prompt - https://starship.rs
# ...

# Desktop apps (casks)
cask "visual-studio-code@insiders"
cask "raycast"
cask "1password"
# ...

# Rust crates
cargo "oha"
# ...

Once you have your Brewfile, you can use it to install all your apps:

brew bundle --file=Brewfile

Here's my Brewfile if you wanna check it out.

Look mas!

I always thought Mac App Store apps couldn't be automated. Turns out, there's a tool called mas (Mac App Store CLI) that allows you to automate installation of Mac App Store apps.

# In your Brewfile
brew "mas"

# Then add Mac App Store apps
mas "Dato", id: 1470584107
mas "Keynote", id: 409183694
mas "Numbers", id: 409203825
mas "TestFlight", id: 899247664
# ...

When you run brew bundle, it installs mas first, then uses it to download and install Mac App Store apps automatically.

To find app IDs, just search on the Mac App Store website and grab the ID from the URL, e.g. 1470584107 is the app ID for Dato, https://apps.apple.com/us/app/dato/1470584107.

Or just run mas list to see all the apps you currently have installed and snatch the app IDs from there.

My Install Script

Here's my install.sh that I orchestrates the whole setup. The script is idempotent and prompts for each major step.

#!/usr/bin/env bash

# Install Xcode Command Line Tools first
if ! xcode-select -p &> /dev/null; then
    xcode-select --install
    read -n 1 -s -r  # Wait for completion
fi

# Install Homebrew
if ! command -v brew &> /dev/null; then
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
fi

# Symlink all dotfiles
create_symlink "$DOTFILES_DIR/shell/.zshrc" "$HOME/.zshrc"
create_symlink "$DOTFILES_DIR/git/.gitconfig" "$HOME/.gitconfig"
# ... and more

# Install Rust (before brew bundle, so cargo packages work)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y

# Install everything from Brewfile
brew bundle --file="$DOTFILES_DIR/Brewfile"

# Install Node.js LTS via fnm
fnm install --lts
npm install -g @openai/codex

# Apply macOS system preferences
./macos-defaults.sh

Automating macOS Preferences

Like I mentioned in the beginnging, this is more than a dotfiles repository. It also covers macOS settings like Dock position and size, Finder settings, keyboard repeat rate, menu bar clock settings etc.

All of these can be automated with defaults write commands:

# Position Dock on the right
defaults write com.apple.dock orientation -string "right"

# Show hidden files in Finder
defaults write com.apple.finder AppleShowAllFiles -bool true

# Fast keyboard repeat
defaults write NSGlobalDomain KeyRepeat -int 2

# Show analog clock with day of week
defaults write com.apple.menuextra.clock IsAnalog -bool true
defaults write com.apple.menuextra.clock ShowDayOfWeek -bool true

...

Here's my macOS settings with both recommended defaults for devs and my personal preferences, commented so I can pick and choose.

What Not to Commit to Your Dotfiles Repo

A lot of devs showcase their dotfiles as a public repository on GitHub, so do not add:

API tokens or credentials
SSH private keys
.npmrc files with auth tokens
Work-related hostnames or company names
Personal email addresses (if you care about that)
etc.

To prevent this, use your .gitignore file to prevent certain files from being committed to the repository:

.npmrc
**/*_token
**/*_key
*.local
.ssh/config_local
.env
.env.*
*.env
.env.*.local

Git Setup

My install script creates a symlink for my Git config, and from there I just need to set up my signing key and access key
If not already configured.

Modern Git Signing with SSH

While setting this up, I learned you can sign git commits with SSH keys instead of GPG, which is what I was previously doing. So the SSH key you use for getting git access via SSH can also be used for signing your commits. No more dealing with GPG key expiration or complex setup:

# Tell git to use SSH for signing
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Add your SSH key as a "Signing Key" on GitHub
# (not just an authentication key!)

GitHub shows commits as "Verified" just like with GPG, but it's way simpler.

Productive in 30 Minutes

Now when I get a new Mac or when I need to refresh my existing one (that's what prompted me to automate this), the process is:

Clone the repo:

   git clone https://github.com/nickytonline/dotfiles.git ~/dotfiles
   cd ~/dotfiles

Run the install script:

   ./install.sh

Say "yes" to the prompts and watch the magic happen:

Xcode Command Line Tools install
Homebrew installs
My apps download and install automatically
All dotfiles symlink
Rust, Node.js, and CLI tools set up
macOS preferences apply

5 minutes of manual work:

Generate/restore SSH keys
Sign into 1Password
Run gh auth login
Sign into a few apps (Slack, Raycast, etc.)

Boom! All set up.

Try It Yourself

Setting up dotfiles is easier than you think. Start small:

Create a ~/dotfiles directory
Move your .zshrc there and symlink it: ln -s ~/dotfiles/.zshrc ~/.zshrc
Initialize a git repo: git init
Create a Brewfile: brew bundle dump
Build from there

Your future self (and your next Mac) will thank you.

Check out my dotfiles repo if you want to see the full setup or steal parts of it. If you've got your own dotfiles setup or discovered other tools that make Mac automation easier, I'd love to hear about it.

If you want to stay in touch, all my socials are on nickyt.online.

Photo by Ales Nesetril on Unsplash

My 2025 Year in Review

Nick Taylor — Tue, 30 Dec 2025 18:21:13 +0000

2025 was wild. I wrapped up 2024 with OpenSauced getting acquired by the Linux Foundation, which meant I was job hunting in late fall/early winter. My network came through for me and I landed at Pomerium in January.

From App Dev to Infra and Security

January 13th marked my first day at Pomerium as a Developer Advocate. I'd had DevRel tendencies since my days at dev.to, but this was my first official title as a DevRel. They always say you're doing the thing before you're doing the thing and I think that's spot on. People over the past five years have always assumed I was DevRel until I let them know that I was actually full-time on engineering.

Anyway, I went from being an app dev to working at Pomerium, a company whose main product is an identity-aware proxy (IAP). Completely out of my wheelhouse, but I was up for the challenge.

I'd talked to some people who said getting into security was a solid move right now, and they were right. I think the main thing that had me a bit nervous was, what if no one wants to hear a talk from me since this was new territory for me.

Hello MCP

Then in May, everything shifted. I had heard about the Model Context Protocol (MCP) and then I saw Angie Jones mention on LinkedIn that she was speaking at the inaugural MCP Dev Summit in San Francisco. I brought it up internally, saying we should probably attend and I even submitted a talk as the CFP was still open. That conversation kicked off everything that came after.

I think my CEO had also brought up MCPs and then all of a sudden we were securing MCPs as well. For a TLDR: an IAP operates at layer seven in the network stack, commonly known as the application layer, and for the most part that is HTTP, where remote MCP servers live. There were too many talks they wanted to do so they spilt over onto The Context (the MCP Dev Summit's online stream) which is where I gave my talk.

I also suggested we attend the AI World Fair, so we ended up grabbing a booth there and met all kinds of people interested in AI including MCP. I also got to attend a couple workshops including one from the WorkOS people (Nick and Zack), where we dove into Mastra.

And of course it was great to see old co-workers and friends.

Conference Circuit

2025 was my biggest year for talks. I gave somewhere between 15 and 20 talks across different conferences. BlackHat USA was cool as I'd never been to Vegas before. I was a little stressed before my talk as the venue was massive and I was having trouble finding the location for my talk, but in the end, I made it. Maybe a bit sweaty lol.

I also got to meet a friend of mine, Carmen, irl finally!

I had multiple appearances at SREday, wrapping it up at the Microsoft Reactor campus where I think I gave my best version of that talk.

My main talk evolved throughout the year: "Agentic Access: OAuth Gets You In, Zero Trust Keeps You Safe." Different versions for different audiences, but the core message stayed consistent.

One talk that I was a little nervous for was on Zero Trust and Kubernetes (K8s). I'm still very new to K8s, so I wasn't sure I was going to be able to pull it off. I got my demo working at the last minute which definitely helped with stress levels. At the beginning of my talk, I asked if there were any K8s experts in the room to which I think two thirds of the audience raised their hands.

The talk ended up going really well and I asked some of the audience if I explained the concepts well and they said I did, so I felt really good about that. This was at All Things Open and I got roped into co-hosting the Whiskey Web and Whatnot podcast for a couple episodes as well as being a guest myself. Thanks Robbie for having me!

There's no point going through the whole list of talks, but my last in-person talk was the MCP Dev Summit in London which was really cool being there for the second MCP Dev Summit.

Again it was great hanging with some awesome people.

People always say this, but it's 100% true. Getting to meet people in person at all these conferences is the real motivation. Obviously there's speaking obligations, but it's a cheat code to hang with friends as well as people you may have never had the chance to chat with irl.

Community

In early June, I became a GitHub Star. The community nominates people for this, and honestly, I didn't realize how few there were. As of writing this, there are only 88 stars on the planet. Pretty cool.

One of the best perks? GitHub flew me out to GitHub Universe in October. I got to hang with other stars including people I'd known for years but never met in person, like Santosh Yadav and Corbin Crutchley. We grabbed dinner together and it was great finally meeting them face to face.

I also became a Microsoft MVP, which was really cool. It definitely feels great to be recognized.

Aside from that I became a mentor in the Let's Get Technical community where I'm one of the mentors for people new to the tech industry working through a real world project. We wrapped up our Secret Santa Exchange. Great work team!

LetsGetTechnical / elecretanta

An AI-enabled secret santa app to make managing gift exchanges and finding the perfect gift easy

Secret Santa Exchange 🎅

Secret Santa Exchange is an AI-powered Secret Santa platform that makes gift exchanges delightful and effortless. Perfect for organizing gift exchanges between colleagues, friends, and family, Secret Santa Exchange takes the guesswork out of gift-giving with personalized AI suggestions.

🎄 Hackathon Project

This project was created for the Let's Get Technical (LGT) discord community hackathon in December 2024.

Prompt

Greetings Elves! Christmas is around the corner and Santa needs your help. Billions of people participate in Secret Santa and many of them have no idea what they want for Christmas. Vise versa, many gifsters have no clue what kind of gift to give and want to ensure they're buying something valuable for their secret Santa. He needs a web application built that allows users to login and provide what they enjoy in life. This will help the secret Santa individuals narrow down a gift using Elecretanta…

View on GitHub

I don't usually monitor follower counts, but they've all been on the rise including hitting 125K followers on dev.to in early December which I think is pretty cool.

Writing and Building

I published 42 articles in 2025. December alone was 19 articles as I did the Advent of AI 2025 challenge, documenting my daily experiences with Goose.

Here's some of the stuff I built:

dev.to MCP server
Pimp My Ride MCP server
Pomerium's MCP app demo which is essentially an MCP client and it's not really a demo anymore since we use it internally.
TypeScript MCP template - A TypeScript template for building remote Model Context Protocol (MCP) servers with modern tooling and best practices while leveraging the MCP TypeScript SDK.
ChatGPT apps template - A well-architected starter template demonstrating best practices for building ChatGPT apps using the Model Context Protocol (MCP) with React widgets. It leverages TypeScript, Tailwind CSS v4, Pino logging, Storybook, and Vitest for a robust development experience.

Guest Spots and Streaming

I was a guest on some podcasts this year, including the freeCodeCamp podcast where I talked about turning open source into a job.

I also was on CodeTV's Web Dev Challenge with my partner in crime Shashi Lo!

It was another great year of live streaming at nickyt.live. I'm honestly always surprised how I land quality guests.

I also started the Pomerium live stream! This interview with Den (an old co-worker) was one of my favourites.

I also continued doing the 2 Full 2 Stack live stream on the Certified Fresh Events YouTube channel. Brian Rinaldi (@remotesynth) had invited me to do the live stream there a couple years ago, and it was always a blast. Sponsors dried up though, and I think it became less and less fun for Brian as the sponsorships disappeared. It was the right decision, but still sad to see it end.

My Newsletter

My newsletter One Tip a Week had a great year. I started with 122 subscribers at the beginning of the year and ended with 343. Pretty solid steady growth. June was huge, adding 100 new subscribers (shoutout to Cassidy Williams for the boost). Engagement stayed solid: 53.3% open rate, 9.2% click-through rate.

The key was keeping it simple. One tip per week, building up a backlog so there's no weekly pressure. The backlog of issues was key as it doesn't feel like a chore (like my old newsletter did).

Nick Taylor

Dec 15 '25

My Newsletter: Growth, Fun, Slow & Steady

#contentcreation #devtips #webdev

Comments 11

3 min read

Looking Back

2025 was about finding my footing in a completely new domain which I think I did really well. The learning curve was steep and I'm still learning, but it's been a lot of fun. And I gotta say it felt really good being recognized by the community.

Looking Ahead to 2026

Heading into 2026, it's definitely more AI, security, conference talks and good times.

If you want to stay in touch, all my socials are on nickyt.online

Photo by Jametlene Reskp on Unsplash

What Makes Goose Different From Other AI Coding Agents

Nick Taylor — Mon, 29 Dec 2025 05:43:03 +0000

I just finished Goose’s Advent of AI. Everything from CI automation to hand-gesture controlled apps to creating model context protocol (MCP) servers with UI.

I built almost all of these challenges in Goose. Mostly in the GUI at first, shifting to the CLI as I learned more. Occasionally by I’d jump to Claude to finish something, but Goose was my primary development environment. My workflow: convert the challenge to a product requirements document (PRD) and sometimes I’d compliment it with an evaluation rubric if the project was more complex, then implement it.

After building with it daily for over two weeks, I can tell you what makes Goose different. But first, the baseline.

The Table Stakes Stuff

Goose does all the things you expect an AI agent to do. A GUI with a chat UI, a CLI, and like some other agents, it’s model-agnostic (works with any LLM provider including local models), and in the case of some CLIs useful in CI/CD too.

It also has first class support for MCPs, chat history, named sessions, subagents for parallel task execution, skills for custom context, and like a lot of great software, it’s open source.

block / goose

an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

goose

a local, extensible, open source AI agent that automates engineering tasks

goose is your on-machine AI agent, capable of automating complex development tasks from start to finish. More than just code suggestions, goose can build entire projects from scratch, write and execute code, debug failures, orchestrate workflows, and interact with external APIs - autonomously.

Whether you're prototyping an idea, refining existing code, or managing intricate engineering pipelines, goose adapts to your workflow and executes tasks with precision.

Designed for maximum flexibility, goose works with any LLM and supports multi-model configuration to optimize performance and cost, seamlessly integrates with MCP servers, and is available as both a desktop app as well as CLI - making it the ultimate AI assistant for developers who want to move faster and focus on innovation.

Quick Links

Quickstart
Installation
Tutorials
Documentation
Governance
Custom Distributions - build your own goose distro with preconfigured providers…

View on GitHub

Most of these features aren’t unique. OpenCode (also open source), Cursor, Copilot, Claude Code, and Windsurf all have most of these capabilities too.

If that’s all Goose offered, this wouldn’t be worth writing about.

What Actually Makes Goose Different

Goose isn’t competing with Cursor’s autocomplete or Copilot’s inline suggestions. It’s a different category. Think build system for agent behavior, not better IDE integration.

After all that daily use, three things stand out. (And apparently I’m not alone: according to Block, 60% of their workforce uses Goose weekly with reported 50-75% development time savings.)

Recipes: Reusable AI Workflows

Most AI tools give you saved prompts or templates. Goose recipes are structured workflow definitions with actual capabilities.

For day 9 and day 15 of Advent of AI, I built projects that used recipes and sub-recipes.

Here’s what recipes actually give you:

Parameter passing between workflow stages - Define {{event_name}} once, use it everywhere
Sub-recipe composition - Call sub-recipes from one parent recipe
Environment extensions - Recipes automatically get access to globally configured MCP servers and built-in extensions
Explicit extension specification - Pin specific MCP servers/tools for a recipe (supported in only YAML at the moment)
Structured inputs - Define parameters with types, requirements, descriptions

Here’s what this looks like using the social media campaign recipe (Advent of AI day 15) that orchestrates three platform-specific sub-recipes:

The full YAML structure:

version: 1.0.0
title: Social Media Campaign Generator
description: Generate complete cross-platform social media campaign using sub-recipes
instructions: |
  You are a social media campaign coordinator creating a comprehensive multi-platform campaign.

  Generate a complete social media campaign for the following event:
  - event_name: {{event_name}}
  - event_date: {{event_date}}
  - event_description: {{event_description}}
  - target_audience: {{target_audience}}
  - call_to_action: {{call_to_action}}

  Campaign Strategy:
  Execute the following sub-recipes to create platform-specific content:

  1. Instagram Content: Run the instagram-post.yaml recipe
  2. Twitter/X Thread: Run the twitter-thread.yaml recipe
  3. Facebook Event: Run the facebook-event.yaml recipe

  [Format and present complete campaign organized by platform]

prompt: Generate complete social media campaign for {{event_name}}

sub_recipes:
  - name: "instagram_content"
    path: "./instagram-post.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
  - name: "twitter_content"
    path: "./twitter-thread.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
  - name: "facebook_content"
    path: "./facebook-event.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"

parameters:
  - key: event_name
    input_type: string
    requirement: required
    description: Name of the festival event
  - key: event_date
    input_type: string
    requirement: required
    description: When the event is happening
  - key: event_description
    input_type: string
    requirement: required
    description: What the event is about
  - key: target_audience
    input_type: string
    requirement: required
    description: Who should attend
  - key: call_to_action
    input_type: string
    requirement: required
    description: What you want people to do

When you run this recipe, Goose executes each sub-recipe with the same parameters. Each sub-recipe handles its platform’s specifics. The parent recipe just coordinates.

You can also pin which MCP extensions a recipe should use. This is currently only available in YAML (not the UI), but it’s powerful for reproducible workflows. This guarantees the recipe runs with specific tools, regardless of what’s in your global config.

A more typical engineering workflow would be generating weekly status updates by querying Linear, GitHub, and Notion. Check out this gist for the recipe.

You can also make a recipe a slash command.

With that set up, if I want to get my weekly status update, all I need to do is run /weekly-status in the GUI or REPL and get a formatted report with links to the issues, pull requests etc.

Why this matters architecturally:

Without recipes, you’d copy-paste prompts and manually pass values between steps. With recipes you get version control (YAML in git means you can diff changes, revert mistakes), team sharing (your team uses the exact same workflow, not “here’s a prompt I used once”), composition (build complex workflows from simple, tested building blocks), and debugging (each sub-recipe runs independently, so you can test in isolation).

This is different from “I saved a good prompt.” This is workflow infrastructure.

How this differs from .cursor/rules or custom instructions:

Most AI coding tools support rules in some form. Cursor has .cursor/rules, Cline has .clinerules, and there’s the AGENTS.md standard that works across tools. These are project-specific prompting guidelines. They improve how the agent understands your codebase and preferences, but they’re not reusable workflows.

The difference: Rules files tell the agent “when you write code in this project, follow these patterns.” Recipes say “execute these specific steps in this order with these parameters.” One is better prompting. The other is workflow orchestration.

Put simply: Rules change how the agent behaves. Recipes change what the agent does.

You can’t compose rules files together, pass parameters between them, or run them as isolated workflows. They’re context for better prompting, not executable infrastructure.

Compare this to slash commands in other tools. Those are saved prompts with placeholders. They can’t orchestrate multi-stage workflows, adjust parameters between stages, or compose with other workflows.

Recipes + Subagents: Parallel Workflows

With Subagents, recipes give you infrastructure to orchestrate them effectively. Here’s a video processing recipe that spawns 4 parallel subagents:

version: 1.0.0
title: Video Tools
description: A set of tools for processing videos
instructions: |
  You are a video processing assistant

  Process {{video_file}} with real-time progress updates.

  STEP 1 - Immediate acknowledgment:
  Run: echo "🎬 Processing video: {{video_file}}" | tee /dev/tty
  STEP 2 - Check dependencies (ffmpeg, ffprobe)
  STEP 3 - Analyze video (duration, resolution, codec, audio presence)
  STEP 4 - Launch parallel subagents:

  === SUBAGENT 1: Smart Compression ===
  - Analyze video type (screencast vs camera footage)
  - Choose optimal CRF value (18-28 range) based on content
  - Adjust resolution if beneficial (4K→1080p for screencasts)
  - Compress with ffmpeg: -c:v libx264 -crf [chosen] -preset medium
  - Output: {{video_file}}_compressed.mp4
  - Report before/after sizes and compression ratio

  === SUBAGENT 2: Intelligent Thumbnails ===
  - Detect video content type
  - For screencasts: extract at 20%, 40%, 60%, 80%, 100% intervals
  - For camera footage: use ffmpeg scene detection for key frames
  - Generate 5 thumbnails at 320px width
  - Output: {{video_file}}_thumb_1.jpg through _thumb_5.jpg

  === SUBAGENT 3: Audio Extraction (ONLY IF AUDIO DETECTED) ===
  - Extract audio using ffmpeg: -c:a libmp3lame -q:a 2
  - Output: {{video_file}}_audio.mp3
  - Report audio file size and bitrate

  === SUBAGENT 4: Transcription & Analysis (ONLY IF AUDIO DETECTED) ===
  - Run: uv run --with openai-whisper whisper {{video_file}} --model base
  - Output: .txt, .srt, .vtt, .tsv, .json caption files
  - Analyze transcript: word count, speaking pace, content type
  - Brief content summary

  STEP 5 - Monitor subagents and report completions immediately
  STEP 6 - Final summary with all generated files

prompt: process {{video_file}}

parameters:
  - key: video_file
    input_type: string
    requirement: required
    description: The video file to optimize

Want to try this directly in Goose?

Click on the recipe share link to import this recipe directly into Goose, no copy-paste needed.

Each subagent runs independently with progress updates via echo | tee /dev/tty. The recipe coordinates them, handles failures gracefully (if compression fails, you still get thumbnails), and provides a unified summary.

Without recipes, you’d have a saved prompt where you manually edit the filename each time: “Process my-video.mp4 by spawning 4 subagents…” Want to process a different video? Find and replace the filename, hope you didn’t miss one. Want to share this workflow with a teammate? Send them your entire conversation.

With recipes, I can process a video in one line /video-tools any-file.mp4. I can also share it as a deeplink that imports the recipe with one click.

Recipes are parameterized, versionable (if you want), and shareable as standalone workflows.

Why infrastructure matters for teams:

Recipes aren’t just about personal productivity. They’re definitely great for that, but they’re also about making agent workflows institutional knowledge instead of undocumented knowledge.

Auditability: Goose sessions can be exported as JSON with full metadata: token usage, model config, working directory, timestamps. You know exactly what a workflow cost and how it executed as well as the conversation history.

Here’s what a session export looks like:

{
  "id": "20251228_72",
  "working_dir": "/Users/nicktaylor/dev/oss/wishlist-mcp",
  "name": "Nike Sales Bar Chart",
  "created_at": "2025-12-28T19:53:24Z",
  "total_tokens": 10297,
  "input_tokens": 10034,
  "output_tokens": 263,
  "provider_name": "anthropic",
  "model_config": {
    "model_name": "claude-opus-4-5-20251101",
    "context_limit": 200000
  },
  "conversation": [...]
}

Compare this to “export all your data” bulk downloads that most cloud models offer. With per-session exports, you can track workflow costs, analyze token usage patterns, and reproduce exact execution environments.

Onboarding: New team members can run /onboarding instead of hunting down the 17-step checklist your senior engineer keeps in a Google Doc.

Consistency: When everyone runs the same recipe with the same pinned extensions, you get fewer “works on my machine” agent outcomes.

Separation of concerns: Recipe authors encode expertise once. Anyone on the team can execute workflows without needing to understand every implementation detail.

Standards-based: Goose is an early contributor to the Linux Foundation’s AI Agent Interoperability Foundation (AAIF), alongside Anthropic and OpenAI. Recipes and MCP integration position you for the emerging standard, not a proprietary lock-in.

Prompts are individual knowledge. Recipes can be institutional knowledge.

MCP-UI Rendering Support

Most MCP client implementations render tool responses as text. Goose’s GUI can also render MCP-UI components as actual interactive widgets.

On Day 17 of Advent of AI, I built a wishlist MCP server that returns UI components.

In Goose, it showed up as an interactive widget. In other MCP clients without UI support, it would just be text.

The auto-visualizer extension leverages this too. Instead of text dumps of data, you get rendered visualizations you can interact with.

Right now, only three clients support MCP-UI properly: Goose, ChatGPT (via their Apps SDK), and LibreChat. Everyone else does text-based responses. Having a client that can also render UI components instead of just text is a better experience.

Terminal Integration Architecture

Goose has two modes: the full REPL (chat back and forth) like other CLIs, and terminal integration (@goose "do this").

Terminal integration is ambient assistance. You’re working in your normal terminal. You invoke Goose for a specific task. It executes. You’re back to your normal workflow.

Example from Day 13:

❯ @goose "continue with the PRD, we were at data organization"

Goose reads the PRD, checks what’s already done in the project, tells you the next step. All from one command. No session management.

This architecture lets you hand off tasks the agent can’t do:

❯ @goose "install this package globally"
# Goose: "You need to run: sudo npm install -g whatever"
❯ sudo npm install -g whatever  # You run it with your privileges
❯ @goose "okay continue"  # Goose sees you ran it, continues

No need to open a separate terminal to do the thing the agent can’t do and then come back to where you left off in your REPL session. Stay in your flow in your current terminal session.

Terminal integration confused me initially, but once but once I had the aha moment thanks to a similar issue I run into with sudo all the time with AI, I realized this is a great flow.

There’s also named sessions which persist across terminal closes:

eval "$(goose term init zsh --session my-project)"

Close your terminal, come back tomorrow, run the same command, you’re back in the conversation.

This is infrastructure for integrating AI assistance into your existing workflow, not replacing it.

When It Works (And When It Doesn’t)

The GUI is better for longer back-and-forth or even the CLI in REPL mode. Terminal integration is better for quick tasks or continuing work.

As mentioned, Goose supports subagents for parallel task execution. Each subagent runs in its own isolated session. If one fails, you only get results from successful ones.

The subagent infrastructure is solid. The only thing I ran into was with GPT-4.1 (switched to it when my tokens were low). Goose wasn't able to spawn subagents with GPT-4.1. Not sure why. Anthropic's Sonnet 4.x and Opus models worked perfectly with subagents.

Recipe YAML validation could be better. When I asked the model to generate recipes during Day 9, it got the format wrong multiple times. I’d included https://block.github.io/goose/llms.txt as reference, so I’m not sure why the model struggled with it. Not necessarily a direct Goose issue, but I'm surprised with access to Goose's llms.txt, the model couldn't generate a valid Goose recipe YAML file.

What I Still Use Claude.ai For

If I’m being honest, I still write my blog posts on Claude.ai, not Goose. Not because Goose is bad at it, but because I already have Claude Projects set up with my DevRel system prompts, evaluation rubrics, and content templates. I’m just used to that workflow.

Maybe that’ll change as I use Goose more. Right now, Goose is where I automate things like weekly status updates. Claude.ai is where I write about them. Different tools for different jobs.

Pick the Right Tool for the Job

Different tools solve different problems.

If you want the best inline autocomplete, go with Cursor or GitHub Copilot in VS Code (their multi-line suggestions and context awareness are excellent). That said I think this kind of workflow is going to go the way of the dinosaur. As someone whose done a lot of frontend work, I'm noticing myself less and less editing in the IDE and more just code reviewing what got generated.

If you need tight VS Code integration, go with GitHub Copilot (native extension with deep editor hooks).

If you want a polished terminal interface, Claude Code or OpenCode are excellent choices.

If you want infrastructure for repeatable workflows, go with Goose.

Goose makes sense if you:

Build the same type of project repeatedly (recipes save you from re-prompting)
Want AI assistance without leaving your terminal (ambient mode)
Work with teams that need reproducible workflows (YAML in git)
Build tools that need interactive UIs (MCP-UI rendering)

And of course it has all the table stakes features you expect in an AI agent which also makes Goose a solid choice.

Getting Started

You can bring your existing AI subscriptions to Goose: GitHub Copilot, Cursor, OpenAI, Anthropic, or any OpenAI-compatible provider. Goose is model-agnostic.

If you don’t have any subscriptions, start with Ollama and local models. Free, private, and runs entirely on your machine.

Try It Yourself

The fastest way to understand Goose is the Advent of AI challenges. Even though it’s over for this year, it’s a great way to wrap your head around what Goose has to offer.

Don’t start by migrating your current workflow. Start by automating one repetitive task as a recipe. Later on, consider migrating your current workflow.

Check out my Advent of AI 2025 repo to see what I built.

Advent of AI 2025 - Day 17: Building a Wishlist App with Goose and MCP-UI

Nick Taylor — Sat, 27 Dec 2025 15:33:49 +0000

I've edited this post, but AI helped. These are meant to be quick posts related to the Advent of AI. I don't have time if I'm doing one of these each day to spend a couple hours on a post. 😅

The advent of AI series leverages Goose, an open source AI agent. If you've never heard of it, check it out!

block / goose

an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

goose

a local, extensible, open source AI agent that automates engineering tasks

Whether you're prototyping an idea, refining existing code, or managing intricate engineering pipelines, goose adapts to your workflow and executes tasks with precision.

Quick Links

Quickstart
Installation
Tutorials
Documentation
Governance
Custom Distributions - build your own goose distro with preconfigured providers…

View on GitHub

For Day 17 of the Advent of AI challenge, I built a Winter Wishlist app using MCP-UI.

What I Built

A wishlist MCP server that renders a visual UI directly in Goose. Users can:

Add wishes with a quick message to Goose
View all their wishes in a nicely formatted UI
Grant wishes when they come true
Delete wishes they no longer want

Check out the repo:

nickytonline / wishlist-mcp

Advent of AI Day 17: Wishlist MCP App

🎄 Winter Fairy's Wishbox

A magical MCP-UI application that brings the Winter Festival's enchanted wishbox to life! Built for Advent of AI 2025 - Day 17, this app lets you make wishes, view them in a beautiful UI, grant them when they come true, and release them when needed - all within your MCP client like goose or ChatGPT.

📖 The Story

In the center of the Winter Festival stands an ancient, frost-covered mailbox known as the Winter Fairy's Wishbox. For generations, children (and adults too!) have written their wishes on paper and dropped them in, hoping the Winter Fairy would see them. This year, the magic has gone digital! Make wishes, watch them appear in a beautiful enchanted interface, and track them as the Winter Fairy grants them!

✨ Features

🌟 Make Wishes - Tell goose your wishes with categories (toy/experience/kindness/magic) and priorities (dream wish/hopeful wish/small wish)
📋…

View on GitHub

The implementation stores wishes in memory based on MCP session ID. Obviously something more robust would make sense for production, but for this challenge it works great.

The ChatGPT App Template Foundation

I based this on a ChatGPT app TypeScript template I had created for work just before the holiday. Having that foundation made spinning up the wishlist server much faster.

pomerium / chatgpt-app-typescript-template

ChatGPT app template using Pomerium, OpenAI Apps SDK and Model Context Protocol (MCP), with a Node.js server and React widgets.

MCP Apps Template

A well-architected starter template demonstrating best practices for building MCP Apps using the Model Context Protocol (MCP) with React widgets. It leverages TypeScript, Tailwind CSS v4, Pino logging, Storybook, and Vitest for a robust development experience.

Features

MCP Server - Node.js server with McpServer and MCP Apps helpers
Echo Tool - Example tool with Zod validation and UI binding
React Widgets - Interactive Echo component with MCP Apps App API demo
Display Modes - Inline, picture-in-picture, and fullscreen with runtime toggling via requestDisplayMode()
App API Demo - callServerTool, openLink, sendMessage, updateModelContext showcased in the Echo widget
UI Capability Negotiation - Server detects host capabilities and falls back to text-only for non-UI clients
Inline Widget Assets - Self-contained HTML mode for hosts that sandbox iframes (e.g. Claude.ai)
Container Dimensions - Responsive widget sizing using host-provided containerDimensions
Mock App - Drop-in createMockApp() helper for testing and…

View on GitHub

One of the best parts of this setup is the development workflow. You can build out your components in Storybook, make live edits to widgets, and see them update in Goose in real-time. This makes iterating on the UI super fast.

The iframe Sizing Battle

The main issue I ran into was iframe sizing. In ChatGPT apps, the iframe sizing seems to handle itself based on content. But in Goose? Not so much. I had to add some JavaScript to handle the sizing properly.

Initially I thought I was doing something silly because all my iframes weren't sizing to my content. There's additional metadata you can add to the UI resource, but that didn't change anything. I even noticed while debugging that my iframe was inside another iframe, which seemed odd.

Then Rizel in a GitHub discussion (@blackgirlbytes) came through with the solution. You need to use a ResizeObserver on your content container and post messages to the parent frame for Goose:

// Auto-resize the iframe to fit content - observe only the container
const container = document.querySelector('.container');
if (container) {
  // Send initial size
  window.parent.postMessage({
    type: "ui-size-change",
    payload: { height: container.offsetHeight + 100 }
  }, "*");

  // Observe container only (not document which snowflakes affect)
  new ResizeObserver(entries => {
    entries.forEach(entry => {
      window.parent.postMessage({
        type: "ui-size-change",
        payload: { height: entry.contentRect.height + 100 }
      }, "*");
    });
  }).observe(container);
}

That fixed it completely.

Key Learnings

MCP-UI is powerful for creating visual interfaces right in your AI chat. Having a solid template to start from made a huge difference. If you're building MCP servers, especially UI-based ones, starting with a good foundation saves a ton of time.

Even if you missed the Advent of AI this year I encourage you to head over to AdventOfAI.dev and jump in.

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Photo by Phil Stanier on Unsplash

Advent of AI 2025 - Day 16: Planning With .goosehints

Nick Taylor — Tue, 23 Dec 2025 15:52:23 +0000

I've edited this post, but AI helped. These are meant to be quick posts related to the Advent of AI. If I'm doing them correctly, they should take me between 30 minutes to 1 hour max to write.

The advent of AI series leverages Goose, an open source AI agent. If you've never heard of it, check it out!

block / goose

an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

goose

a local, extensible, open source AI agent that automates engineering tasks

Whether you're prototyping an idea, refining existing code, or managing intricate engineering pipelines, goose adapts to your workflow and executes tasks with precision.

Quick Links

Quickstart
Installation
Tutorials
Documentation
Governance
Custom Distributions - build your own goose distro with preconfigured providers…

View on GitHub

Advent of AI day 16 is about structuring projects before building them using the .goosehints file.

Here's my day 16 submission.

The Challenge

Up until now, the Advent of AI challenges were pretty open-ended. You'd chat with Goose and build things organically. Day 16 changes that. You're supposed to structure the project first using two components:

.goosehints - tells Goose HOW to work (tech stack, conventions, file structure)
A planning approach - tells Goose WHAT to build

The actual task is building a festival countdown app that shows days/hours/minutes/seconds until next year's festival, has rotating fun facts, an email signup form, and a winter theme. Mobile responsive.

What's .goosehints?

A .goosehints file is project context for Goose. Tech stack choices, coding conventions, file organization, style preferences. It lives in the project root (or subdirectories) and Goose automatically reads it when starting a session.

Quick note on .goosehints vs AGENTS.md: Goose actually supports both, but with different scopes. AGENTS.md is repository-wide context that works across multiple AI tools (Claude, Cursor, Windsurf). You can learn more about the AGENTS.md format at agents.md. .goosehints is directory-scoped and Goose-specific. For most projects, AGENTS.md is sufficient since the entire project context fits in one file and you get cross-tool compatibility. But for Day 16, I used .goosehints since that's what the challenge specifically called for.

Looking at the Goose repo's own .goosehints file, you see patterns like:

Tech Stack:

Language: Rust
Framework: tokio for async
Testing: Standard Rust test framework

For my countdown app, I kept mine simple. HTML/CSS/JavaScript, mobile-first responsive design, vanilla JavaScript (no frameworks), Playfair Display and Poppins fonts to match the festival website from Day 4.

The key is being specific. Not just "use good practices" but actual constraints like "use CSS custom properties for theming" or "create separate files for countdown logic, facts rotation, and form handling."

Planning With TODO Extension

Goose has three planning approaches you can use. I went with the TODO extension because I wanted to see the full breakdown upfront and track progress as Goose worked.

The TODO extension is an MCP server that maintains a task list for your project. You can read and write to it. Goose updates it as it completes tasks.

I started by asking Goose to create a PRD (Product Requirements Document) and break it into stages. Goose generated eight stages with specific tasks for each:

Planning & Setup (create .goosehints, directory structure, initialize TODO)
Core Countdown Functionality (HTML structure, JavaScript logic, handle edge cases)
Fun Facts Rotation (data structure, rotation logic, CSS transitions)
Email Signup Form (validation, localStorage, success/error feedback)
Winter Theme & Styling (color palette, typography, visual elements)
Responsive Design (mobile-first breakpoints, touch targets)
Testing & Polish (accessibility, performance, SEO)
Documentation & Deployment (deployment guide, README)

The TODO list had checkboxes for every task. As Goose completed each one, it marked it done. You could see exactly what was finished and what was left.

Actually Building It

Once the plan was set, I told Goose to start executing. It went through each stage systematically.

Stage 2, it built the countdown. Created js/countdown.js with logic to calculate time difference to December 1, 2026 at 10:00 AM. Updates every second. Handles timezone properly.

Stage 3, it added facts rotation. Created js/facts.js with an array of facts and rotation logic. Fades out the current fact, waits, fades in the next one. Six second intervals.

Stage 4, it built the email form. Created js/form.js with validation and localStorage. Doesn't actually send emails (that would be a bonus feature), but validates and stores them locally.

The styling was interesting. Goose pulled the color palette and fonts from my Day 4 festival website. Blues, whites, purples. Gradient backgrounds. It created separate CSS files for base styles, animations, and responsive breakpoints.

For responsive design, it implemented mobile-first with breakpoints at 768px (tablet) and 1024px (desktop). Adjusted font sizes, spacing, and layout for each screen size.

The Bonus Features

After finishing the core requirements, I tackled four bonus features. Each one got its own conventional commit.

Snowfall animation - Added 20 snowflakes falling at different speeds with left/right drift. Different sizes and delays for a natural effect. Respects prefers-reduced-motion.

Dark mode toggle - Moon/sun icon in the top-right corner. Persists preference in localStorage. Respects system preference on first visit. Smooth CSS variable transitions between themes.

Extended fun facts - Expanded from 5 facts to 16. Added stats about vendors, donations, activities, toy drive, parade, music, skating, lights, maze, Santa photos.

Sound effects toggle - Speaker/mute icon below dark mode. Festive beep sounds on button clicks using Web Audio API. Starts muted by default for accessibility.

.goosehints vs AGENTS.md

I use AGENTS.md (a new standard) in projects now and this is actually the better choice for most projects. It works across multiple AI tools (Claude, Cursor, Windsurf, Goose etc.) and provides repository-wide context. Check out agents.md for the format details.

From what I can tell, .goosehints is more useful when you need directory-scoped context that differs from your repo-wide guidelines. For something like my MCP servers where the entire project context fits in one file, AGENTS.md would be the way to go.

But for this challenge, .goosehints was specifically required, so that's what I used.

The Final Result

The app has all the core requirements working. Real-time countdown to December 1, 2026 at 10:00 AM. Fun facts rotating every 6 seconds with smooth fade transitions. Email signup form with validation and localStorage. Winter-themed design with blues, whites, and purples. Fully responsive on mobile and desktop.

The four bonus features add nice polish. Snowfall animation in the background. Dark mode toggle that persists. 16 fun facts instead of 5. Sound effects you can toggle on and off.

Total files: 14 (6 JavaScript, 3 CSS, HTML, README, deployment guide, etc.) Lines of code: 1,200+ Core features: 6 completed Bonus features: 4 completed

You can check out the complete project in my repo: https://github.com/nickytonline/advent-of-ai-2025/tree/main/day-16

More about .goosehints: https://block.github.io/goose/docs/guides/context-engineering/using-goosehints/

If you want to stay in touch, all my socials are on nickyt.online. Until the next one!

Photo by Mediamodifier on Unsplash

Advent of AI 2025 - Day 15: Goose Sub-Recipes

Nick Taylor — Sun, 21 Dec 2025 17:44:42 +0000

I've edited this post, but AI helped. These are meant to be quick posts related to the Advent of AI. If I'm doing them correctly, they should take me between 30 minutes to 1 hour max to write.

The advent of AI series leverages Goose, an open source AI agent. If you've never heard of it, check it out!

block / goose

an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM

goose

a local, extensible, open source AI agent that automates engineering tasks

Whether you're prototyping an idea, refining existing code, or managing intricate engineering pipelines, goose adapts to your workflow and executes tasks with precision.

Quick Links

Quickstart
Installation
Tutorials
Documentation
Governance
Custom Distributions - build your own goose distro with preconfigured providers…

View on GitHub

Day 15's challenge was all about sub-recipes. If you've been following along, you know recipes are Goose's way of automating workflows.

Nick Taylor

Dec 10 '25

Advent of AI 2025 - Day 7: Goose Recipes

#adventofai #goose #automation #ai

Comments 2

18 min read

Sub-recipes take this further by letting you compose smaller recipes into larger ones.

The Challenge

The scenario: Zara, a social media coordinator, needs to create content for three different platforms for the Grand Ice Sculpture Unveiling event. Each platform needs completely different content styles.

Instagram wants visual captions with hashtags. Twitter/X needs a concise thread. Facebook needs detailed event descriptions. Manually customizing content for each platform is tedious and time-consuming.

The goal: create one main recipe that orchestrates three sub-recipes, one for each platform.

I created four recipe files:

instagram-post.yaml for Instagram content
twitter-thread.yaml for Twitter/X threads
facebook-event.yaml for Facebook event posts
social-campaign.yaml as the main orchestrator

All recipes accept the same core parameters: event name, date, description, target audience, and call to action. The main recipe passes these values to each sub-recipe.

What I Learned

Sub-recipes are powerful for composability. Instead of one massive recipe trying to do everything, you break it into focused pieces. Each sub-recipe has one job and does it well.

The main recipe's job is coordination. It defines the workflow, passes the right data to each sub-recipe, and presents the results in a useful format.

The main recipe's sub_recipes section maps values from the main parameters to each sub-recipe's expected parameters.


yaml
version: 1.0.0
title: Social Media Campaign Generator
description: Generate complete cross-platform social media campaign using sub-recipes
instructions: |

  You are a social media campaign coordinator creating a comprehensive multi-platform campaign.

  Generate a complete social media campaign for the following event:
  - event_name: {{event_name}}
  - event_date: {{event_date}}
  - event_description: {{event_description}}
  - target_audience: {{target_audience}}
  - call_to_action: {{call_to_action}}

  **Campaign Strategy:**
  Execute the following sub-recipes to create platform-specific content:

  1. **Instagram Content**: Run the instagram-post.yaml recipe
  2. **Twitter/X Thread**: Run the twitter-thread.yaml recipe
  3. **Facebook Event**: Run the facebook-event.yaml recipe

  **Output Format:**
  Present the complete campaign organized by platform:



  ```
  # 📱 SOCIAL MEDIA CAMPAIGN: {{event_name}}

  ---

  ## 📷 INSTAGRAM POST

  [Output from instagram-post.yaml recipe]

  ---

  ## 🐦 TWITTER/X THREAD

  [Output from twitter-thread.yaml recipe]

  ---

  ## 👥 FACEBOOK EVENT

  [Output from facebook-event.yaml recipe]

  ---

  ## 📊 CAMPAIGN SUMMARY
  ✅ Instagram: Ready to post
  ✅ Twitter/X: Thread ready (3-5 tweets)
  ✅ Facebook: Event description ready

  **Posting Strategy:**
  - Post to Facebook first (most details, drives event RSVPs)
  - Post to Instagram 2-4 hours later (visual engagement)
  - Post Twitter thread 1-2 hours after Instagram (conversation starter)

  **Engagement Tips:**
  - Monitor comments in first 2 hours for maximum reach
  - Respond to questions quickly
  - Share user-generated content
  - Cross-promote between platforms
  ```



  **Execution Instructions:**
  1. Call each sub-recipe with the provided parameters
  2. Collect all outputs
  3. Format as shown above
  4. Provide strategic posting guidance

  **Rules:**
  - Execute all three sub-recipes
  - Present output in a clear, organized format
  - Include campaign summary and strategy
  - Make it ready for immediate deployment
prompt: Generate complete social media campaign for {{event_name}}
extensions: []
sub_recipes:
  - name: "instagram_content"
    path: "./instagram-post.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
  - name: "twitter_content"
    path: "./twitter-thread.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
  - name: "facebook_content"
    path: "./facebook-event.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
activities: []
parameters:
  - key: event_name
    input_type: string
    requirement: required
    description: Name of the festival event
  - key: event_date
    input_type: string
    requirement: required
    description: When the event is happening
  - key: event_description
    input_type: string
    requirement: required
    description: What the event is about
  - key: target_audience
    input_type: string
    requirement: required
    description: Who should attend
  - key: call_to_action
    input_type: string
    requirement: required
    description: What you want people to do

The Result

Running the campaign generator with event details produces ready-to-post content for all three platforms. Instagram gets its caption with strategic hashtags. Twitter/X gets a 4-tweet thread. Facebook gets a complete event description.

The output even includes posting strategy and engagement tips, which I didn't explicitly ask for but the recipe generated based on the instructions.

Resources

If you want to dive deeper into sub-recipes:

My full solution is on GitHub: Advent of AI 2025 - Day 15

The original challenge is here: Day 15: The Social Media Blitz

That's it for Day 15. Quick post, but sub-recipes are a solid pattern for building reusable workflows.

If you want to stay in touch, all my socials are on nickyt.online.

Until the next one!

Find me on the web at nickyt.online

Photo by hybridnighthawk on Unsplash

DEV Community: Nick Taylor

Stop Shipping Broken Env Config

dmno-dev / varlock

AI-safe .env files: Schemas for agents, Secrets for humans.

Varlock

TL;DR

Where .env workflows usually break

What got better right away

Setting it up in Astro

chore: add environment configuration and integrate varlock #22

Quick note on Astro + Vite

The setup flow I recommend

Example CI step

One Astro config gotcha this fixes

This is not just a convenience thing

Astro integration or Vite plugin?

Final thoughts

Useful links

Clawspace: A Browser-Based File Explorer for OpenClaw

nickytonline / clawspace

Clawspace is a browser-based file explorer/editor for an OpenClaw workspace.

Clawspace

Why this exists

Install

Quick start

Development

Configuration

Why not just use SSH?

feat(gateway): add trusted-proxy auth mode #15940

Summary

Changes

Types & Schema

Auth Logic

Runtime Guards

Security Audit

Tests

Documentation

Example Config

Screenshots and Recordings

Security Considerations

Testing

Greptile Overview

Greptile Summary

Confidence Score: 5/5

Getting started

Configuration

Security

It's meant to be tweaked

Let Dependabot Merge Its Own PRs

First, enable auto-merge on your repo

Automate and Auto-Merge Pull Requests using GitHub Actions and the GitHub CLI

The workflow

chore(deps-dev): bump eslint from 9.39.2 to 10.0.3 #809

v10.0.3

Bug Fixes

Documentation

Chores

v10.0.2

Bug Fixes

Documentation

Chores

v10.0.1

Bug Fixes

Documentation

Chores

What it looks like

A note on safety

Being more selective

chore(deps): bump rollup from 4.54.0 to 4.59.0 #790

v4.59.0

4.59.0

Features

Pull Requests

v4.58.0

4.58.0

Features

Pull Requests

v4.57.1

4.57.1

Bug Fixes

Where `.env` workflows usually break

Six practical ways to use `bat`

Should you alias `cat` to `bat`?