~iany/ Automation

My AI-Assisted Development Workflow

me@iany.me (Ian Yang) — Mon, 10 Aug 2026 12:45:09 +0800

AI agents write code fastest when the work is sliced small and a human stays on judgment. My workflow runs a four-step loop: plan the feature into units, hand the branch stack to the agent, review each PR myself, then let the agent address my comments.

I wrote a separate guide on the branch-management mechanics: ♯ A Practical Guide to gh-stack for AI-Assisted Development. That post covers worktrees, rebase habits, and JSON sync. This post is the loop around that tool.

1. Plan and split into units

Start with a written plan, not “build the feature.” The plan names the goal, records the product decisions already made, and breaks work into Implementation Units: U1, U2, U3, and so on.

Each unit is small enough to fit one agent session and one human review. Specific, not vague. “Design the data model for board columns” is a unit. “Do the backend” is not. Dependencies between units are explicit – U3 depends on U2 because it queries the schema U2 defines.

Before any code, I do a quick plan review across three axes: product (is this the right thing?), feasibility (can we build it this way?), and scope (are the units the right size?). Fixing a bad unit boundary in a markdown file takes a minute. Fixing it across five stacked PRs takes an afternoon.

When the plan turns out to be wrong mid-implementation, I stop and revise it before writing more code. The plan is the source of truth, not the branches.

2. Let AI manage branches with gh-stack

Once the units are stable, I give the agent one prompt to build the stack:

Implement U1 and U2 from the plan. Use gh-stack to add a branch per unit. Include the Jira ticket number in branch names.

The agent creates branches, writes scoped commits, opens stacked PRs with each PR based on the unit below, and runs gh stack rebase --upstack when a lower layer changes. I do not hand-manage the branch chain day to day.

One worktree per stack, one branch per unit. The gh-stack guide has the full setup for worktrees, branch naming, and how to keep the JSON in sync.

3. Review the PR and leave comments

This step belongs to me.

I read each stacked PR as a focused slice. Small units mean the diff is narrow enough to actually read. I leave inline comments or a review summary – whatever makes the problem clear. I do not fix code during the review pass.

Good review comments say what is wrong, what I want instead, and which layer owns the change. Ambiguous comments waste the next agent session. The review is the quality gate; I treat it like one.

4. Let AI address the review comments

I hand the PR back with a prompt:

Address review comments on PR #42. Stay on the matching stack branch. Add new commits; don’t amend unless I ask.

The agent reads the threads, fixes issues on the correct layer, replies to comments, and resolves what it can. Anything that requires a product call comes back to me. After fixes on a lower layer, it rebases upstack.

Then I re-review or approve and merge bottom-up. One loop per unit. Repeat.

Why this shape works

Step	Owner
Plan and units	Human + agent
Branches and PRs	Agent + gh-stack
Review	Human
Address comments	Agent

Agents do well with bounded units and explicit comment lists. They do worse at deciding where one unit ends and another begins, or at choosing between two product directions. The plan and the review are where those decisions happen – both belong to the human.

The loop: plan → stack → review → fix.

A Practical Guide to gh-stack for AI-Assisted Development

me@iany.me (Ian Yang) — Thu, 30 Jul 2026 07:19:53 +0800

Stacked pull requests let you review a feature in logical slices rather than one enormous diff. The challenge is managing the branches, synchronizing PRs, and surviving rebases without breaking the chain. gh-stack handles the scaffolding. It tracks your branch stack in a local JSON file, generates PRs that base each one to its parent, and works on any GitHub repo regardless of whether your organization has enabled native stacked PR support.

This is the workflow I use, including how an AI coding agent fits into it.

Start with a Worktree

Before creating any branches, set up a dedicated Git worktree for the stack.

git worktree add ../project-login-stack login-stack-base
cd ../project-login-stack

It’s not required but my personal preference. Stacks and worktrees map one-to-one. This matters for a few reasons:

You can switch between stacks by switching directories, not branches.
Your shell’s working directory tells you exactly which stack you’re in.

Using an Agent to Build the Stack

Stacked PRs only work well if the individual branches are focused. Broad, unfocused branches defeat the point. This is where AI agents help.

When starting a feature, describe it to the agent and ask it to divide the work into discrete units. A typical breakdown might look like:

Database layer – schema and migrations
Service layer – business logic and data access
API layer – endpoints and serializers
UI layer – frontend components

The agent creates a branch for each, makes commits scoped to that layer, and stacks them in order. You end up with four focused PRs instead of one that mixes migrations, API code, and React components in the same diff.

Rebasing Without Breaking the Stack

For day-to-day stack updates, use gh stack rebase --upstack. Switch to any branch in the stack using gh stack up/down/switch, add new commits, and gh stack rebase --upstack to reorganize the branch chain. Avoid git commit --amend in this workflow – gh-stack cannot track amended commits.

When you need to manually rebase the stack such as moving commits between branches in the stack, check out the topmost branch and rebase from there. With rebase.updateRefs enabled, Git updates every intermediate branch ref as it replays commits down the chain. Starting from a middle branch leaves the branches above it with stale refs.

# ~/.gitconfig or repo .gitconfig
[rebase]
updateRefs = true

gh stack top # top of the stack
git rebase -i develop

Prefer gh stack rebase --upstack for the common case. Reserve manual git rebase from the top for when you need to move commits between branches in the stack.

The JSON Sync Problem

gh-stack records branch metadata in .git/gh-stack. When you squash or amend commits, or rebase from a middle layer, the SHA that gh-stack recorded no longer matches the branch’s actual HEAD. The JSON goes stale and breaks most features of gh-stack

The fix is to sync the JSON with the current state of your branches. Doing this manually means running git log --oneline for each branch, reading the current SHAs, and editing the JSON to match. Not difficult, but tedious – especially across a deep stack.

An AI assistant handles this well. Give it access to the repository and ask:

Read the current HEAD of each branch in my gh-stack and update .git/gh-stack so each entry’s recorded SHA matches.

Putting It Together

Stacked PRs reduce review friction. gh-stack makes stacking practical without requiring GitHub-side configuration. The four habits that make it work:

One worktree per stack. Isolation by directory, not branch.
Agent-planned stacks. Focused units make PRs reviewable.
gh stack rebase --upstack for routine updates. Manual git rebase from the top when moving commits between branches in the stack.
AI-assisted JSON sync. Fast recovery after a squash or amend.

Build an MCP with OAuth on Cloudflare Workers

me@iany.me (Ian Yang) — Fri, 24 Jul 2026 19:48:12 +0800

I wanted MCP clients to create Google Tasks for me. The Google Tasks API requires a Workspace-style setup I don’t have. IFTTT already bridges webhooks to Google Tasks—but a Maker webhook URL is itself the credential. Storing that key in local MCP config is a bad idea.

The fix is a thin Cloudflare Worker plus Cloudflare Access Managed OAuth:

Worker holds the IFTTT key as a secret and speaks MCP over HTTP
Access sits in front, handles OAuth login with your IdP
Worker verifies the Access JWT (Cf-Access-Jwt-Assertion) before running tools

The full example: doitian/google-task-ifttt-webhook-mcp. Most of it was scaffolded by AI; the interesting part is the structure, not the TypeScript.

The problem

Piece	Constraint
Google Tasks API	Needs a Workspace-style setup I don’t want to pay for
IFTTT Maker webhook	Works, but the URL is the credential
MCP clients	Expect remote HTTP tools with OAuth

MCP Client
→ Cloudflare Access (OAuth)
→ Worker (JWT)
→ IFTTT
→ Google Tasks

Clients never see IFTTT_MAKER_TASK_KEY. They only hold a short-lived Access token after login.

IFTTT side

One applet:

If: Maker Webhooks → Receive a web request, event name task
Then: Google Tasks → Create a task (title / notes / due from the payload)

The Worker posts to:

https://maker.ifttt.com/trigger/task/json/with/key/{KEY}

with { "title", "notes?", "due?" }. The key never leaves Cloudflare.

Three secrets

npx wrangler secret put IFTTT_MAKER_TASK_KEY
npx wrangler secret put CF_ACCESS_TEAM_DOMAIN
npx wrangler secret put CF_ACCESS_AUD

Secret	Role
`IFTTT_MAKER_TASK_KEY`	Maker webhook key
`CF_ACCESS_TEAM_DOMAIN`	Zero Trust team domain (e.g. `myteam.cloudflareaccess.com`)
`CF_ACCESS_AUD`	Access application audience tag (validates JWT `aud`)

No custom authorize page, no signing keys you mint yourself. Access is the authorization server.

Cloudflare Access

In the Zero Trust dashboard:

Access → Applications → Add → Self-hosted
Point the app at your Worker hostname (*.workers.dev or a custom domain)
Pick an IdP (Google, GitHub, email OTP, …) and an allow policy for yourself
Enable Managed OAuth (Beta)—this is what MCP clients need for the OAuth dance
Copy the team domain and Application Audience (AUD)

Access issues JWTs; MCP clients send them as Cf-Access-Jwt-Assertion. The Worker verifies with the team’s JWKS:

const JWKS = createRemoteJWKSet(
new URL(`${issuer}/cdn-cgi/access/certs`),
);
await jwtVerify(token, JWKS, {
issuer,
...(env.CF_ACCESS_AUD ? { audience: env.CF_ACCESS_AUD } : {}),
});

(jose on Workers with nodejs_compat.)

Worker: just MCP + verify

The business logic is small:

POST / or POST /mcp—JSON-RPC (initialize, tools/list, tools/call)
One tool: create_google_task (title required; notes, due optional)
Reject anything without a valid Access JWT

No OAuth endpoints in the Worker. Access owns login; the Worker only checks the assertion header.

Client config

Point the client at the Worker URL and enable OAuth. Example structure (keys vary by client):

{
"mcp": {
"google-tasks": {
"type": "remote",
"url": "https://google-task-mcp.yourdomain.com"
}
}
}

The client discovers OAuth via Access, opens the browser for your IdP, then attaches the Access JWT on MCP calls.

Why this structure works with AI

The task decomposes cleanly:

MCP handler—fixed JSON-RPC + one tool schema
IFTTT fetch—secret from env
Access JWT verify—JWKS + aud
Wrangler secrets—nothing in git

Describe the constraints (“don’t expose the IFTTT URL”, “Cloudflare Access OAuth”, “Worker MCP”) and get a deployable skeleton. Review JWT verification and secret handling; treat the tool body as glue.

Takeaways

Skip the official Tasks API if IFTTT already has the integration.
Keep Maker keys in Worker secrets, not client config.
Cloudflare Access Managed OAuth turns IdP login into MCP-friendly OAuth without requiring custom authorize/token endpoints.
The Worker only needs to verify Cf-Access-Jwt-Assertion and call IFTTT.

Source: github.com/doitian/google-task-ifttt-webhook-mcp.

Fix Claude Desktop PATH with CLAUDE_ENV_FILE

me@iany.me (Ian Yang) — Wed, 01 Jul 2026 21:27:36 +0800

Claude Code runs tools and shell commands on your behalf. Launched from a terminal, the CLI inherits your shell environment and everything just works. But under Claude Desktop, Claude Code is spawned from a GUI/desktop session that never sourced your interactive shell config—so if you rely on version managers like mise, asdf, or nix, the tools they install may not be on Claude’s PATH. The fix is a single setting: CLAUDE_ENV_FILE.

How it works

Set CLAUDE_ENV_FILE in .claude/settings.local.json to point at a shell file. Claude sources it before running any command.

{
"env": {
"CLAUDE_ENV_FILE": ".claude/mise.env"
}
}

That file is a plain shell snippet—export statements, one per line:

export PATH="/home/ian/.local/share/mise/shims:/home/ian/project/node_modules/.bin:$PATH"
export DATABASE_URL="postgres://localhost/db"

The path can be relative—it’s resolved from the project root—so .claude/mise.env works on any machine and can be committed alongside the project. Write both, and the next Claude session picks up everything.

Why not just put PATH in settings.json?

You can set env.PATH directly in settings.local.json, but there’s a catch: Claude does not support variable substitution like ${env:PATH}. You’d have to hardcode the full PATH, which breaks the moment dependencies change or you move between machines.

With CLAUDE_ENV_FILE you get full shell semantics—$PATH expands at runtime, conditionals work, and subshells are fair game.

Why shell init doesn’t help either: the snapshot

There’s a deeper reason the obvious fixes fail. At session start, Claude Code freezes a shell snapshot to ~/.claude/shell-snapshots/snapshot-zsh-*.sh, and the Bash tool sources that file before every command it runs.

The snapshot’s final line is export PATH=<frozen value>, and that value is Claude Code’s own process PATH captured at startup—not re-derived from your shell config. (You can spot it: it contains directories no rc file adds, like Claude’s own plugin and session bin paths.) Because this export PATH is the last thing sourced before each command, it clobbers anything your shell init did:

mise activate in .zshenv/.zshrc runs, prepends the shims—then the snapshot’s trailing export PATH overwrites it, burying the shims back where they started.
Even setting env.PATH in settings.json as a plain subprocess variable loses, because the snapshot is sourced after the process environment is set up.

CLAUDE_ENV_FILE wins because it’s sourced after the snapshot. Its export PATH="…/shims:$PATH" is the last word, so the shims land first for every Bash tool call. That’s the whole trick: it’s not just convenient shell semantics—it’s the one hook that runs late enough to survive the snapshot.

Generating the env file automatically

Writing the env file by hand gets tedious. If you use mise, you can generate both files with a task—I vibe-coded preset-claude.js for exactly this (it’s a custom mise task, not a built-in). It:

Reads env._.path from mise.toml (so per-project node_modules/.bin directories land on PATH).
Expands {{config_root}} to absolute paths.
Writes .claude/mise.env with shims, extra paths, and all mise env vars.
Sets CLAUDE_ENV_FILE in .claude/settings.local.json.

mise run preset:claude

One command, and Claude sees the exact same tools you do.

What about other version managers?

The pattern works for anything that can write a shell env file:

asdf: asdf direnv envrc > .claude/asdf.env
nix: nix print-dev-env | grep ^export > .claude/nix.env
direnv: direnv export json | jq -r 'to_entries[] | "export \(.key)=\"\(.value)\""' > .claude/direnv.env

Then point CLAUDE_ENV_FILE at it and you’re set.

Caveats

The file is sourced, not executed—shebang lines are ignored.
Changes to settings.local.json take effect on the next Claude session.
If CLAUDE_ENV_FILE is a relative path, it’s resolved from the project root.

A small config file saves you from fighting invisible PATH issues. Set it once, and Claude runs the same tools you do.

Backup Ignored Files with Git Remote Branch

me@iany.me (Ian Yang) — Fri, 12 Dec 2025 03:22:58 +0800

When working with Git repositories, there are often files that need to be backed up but shouldn’t be committed to the main branch. These might include local development settings, IDE configuration files, personal notes, or development scripts that are specific to your workflow. The challenge is finding a way to back up these ignored files without polluting the main repository history.

The Original Solution

My original approach was to use a separate repository to store backup files for all repositories and create symbolic links. This worked, but had several drawbacks:

Backup files were disconnected from their source repositories, making it harder to track what belongs where
Backing up new files required moving them to the backup repository and then creating symbolic links

A Better Approach: Remote Branch

Instead of using a separate repository, we can use a remote branch within the same repository. This approach offers several advantages:

Everything stays in one repository
When you clone the repository, the backup branch comes with it
Backup files are stored in a separate branch, keeping the main branch clean
Full Git history for backup files, just like any other branch

The Script

With AI assistance, I developed git-store-file, a tool for managing ignored files by storing them in a remote branch (default: origin/_store). This keeps backup files separate from your working branch without interfering with regular development. The script is available in Python.

Installation

Download the script and make it executable:

curl -o ~/bin/git-store-file https://raw.githubusercontent.com/doitian/dotfiles-public/master/default/bin/git-store-file
chmod +x ~/bin/git-store-file

Usage

The script has four main commands: store, status, restore, and ls.

Store Files

Store one or more files to the remote branch, including files that are ignored by Git:

# Store a single file
git-store-file config.local.json
# Store multiple files
git-store-file config.local.json secrets.env
# Use a custom branch name
git-store-file --branch backup config.local.json
# Use a custom remote
git-store-file --remote upstream config.local.json

When you run the store command, the script will:

Create a temporary Git index to avoid conflicts with your working directory
Load the target branch’s current state into the temporary index
Add the specified files using git add -f to include ignored files
Create a commit with the changes
Display commit statistics and prompt for confirmation
Push the commit to the remote branch

Check Status

Check which files stored in the remote branch have been modified in your local working directory:

# Check status
git-store-file status
# Show diff for modified files
git-store-file status --diff

Restore Files

Restore files from the remote branch to your working directory:

# Restore a specific file
git-store-file restore config.local.json
# Restore all files from the branch
git-store-file restore

List Files

List all files stored in the remote branch:

git-store-file ls

Options

-b, --branch BRANCH: Specify the branch name (default: _store)
-r, --remote REMOTE: Specify the remote name (default: origin)
-h, --help: Show help message

Examples

# Store local configuration
git-store-file .env.local
# Check what's changed
git-store-file status -d
# Restore after cloning
git-store-file restore .env.local
# List all backed up files
git-store-file ls

How It Works

The script uses Git’s low-level plumbing commands to manipulate the repository without affecting your working directory:

Temporary Index: Uses the GIT_INDEX_FILE environment variable to create a temporary index, completely isolated from your working directory
Read Tree: Loads the target branch’s tree structure into the temporary index
Force Add: Uses git add -f to add files even if they’re listed in .gitignore
Commit Tree: Creates a commit object directly using git commit-tree, bypassing the normal commit workflow
Direct Push: Pushes the commit hash directly to the remote branch reference

This low-level approach ensures that:

Your working directory remains unchanged
The main branch is never affected
Ignored files can be stored without modifying .gitignore
The backup branch maintains full Git history

Conclusion

The git-store-file script solves the problem of backing up ignored files in a clean, Git-native way. By leveraging a remote branch, it keeps everything in one repository while maintaining clear separation between your main codebase and backup files. Whether you’re managing local configurations, IDE settings, or personal development scripts, this tool provides a simple and reliable backup solution that integrates seamlessly with your existing Git workflow.

Hosting Static Site on Cloudflare R2

me@iany.me (Ian Yang) — Wed, 22 Oct 2025 18:46:38 +0800

This post explains how to set up a static site on Cloudflare R2.

I recently migrated my blog to Cloudflare R2, and the process went smoothly until I encountered R2’s lack of native support for rewriting URLs to index.html files. This post explains how I resolved this issue.

Setting Up

Create the bucket.
Add the custom domain blog.iany.me. To redirect iany.me and www.iany.me to the blog, add these as custom domains as well. Since I host the domain in Cloudflare, the DNS record is automatically configured.

Publishing

I use rclone to deploy the site to R2. Below is the GitHub workflow I employ. Noting that the fetch-depth option for actions/checkout retrieves the complete repository history. This works with Hugo’s --enableGitInfo flag to accurately determine article creation dates.

name: Deploy Hugo Site to Cloudflare R2
on:
push:
branches:
- master
workflow_dispatch:
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install latest Hugo
run: |
TAG=$(curl -s https://api.github.com/repos/gohugoio/hugo/releases/latest \
| grep '"tag_name":' \
| head -1 \
| sed -E 's/.*"([^"]+)".*/\1/')
curl -L "https://github.com/gohugoio/hugo/releases/download/${TAG}/hugo_${TAG#v}_Linux-64bit.tar.gz" \
-o hugo.tar.gz
tar -xzf hugo.tar.gz hugo
sudo mv hugo /usr/local/bin/
hugo version
- name: Install rclone
run: |
curl https://rclone.org/install.sh | sudo bash
- name: Build site with Hugo
run: hugo --minify --enableGitInfo
- name: Configure rclone for Cloudflare R2
env:
R2_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
R2_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}
R2_ENDPOINT: ${{ secrets.R2_ENDPOINT }}
run: |
rclone config create r2 s3 \
provider Cloudflare \
access_key_id "${R2_ACCESS_KEY_ID}" \
secret_access_key "${R2_SECRET_ACCESS_KEY}" \
endpoint "${R2_ENDPOINT}" \
--quiet
- name: Deploy to Cloudflare R2
env:
R2_BUCKET: ${{ secrets.R2_BUCKET }}
run: |
rclone copy public/ r2:"${R2_BUCKET}" \
--checksum \
--no-traverse \
--verbose

Rules

Go to the dashboard of the domain iany.me and go to the section Rules.

Redirect Rules

I have added 3 redirect rules:

When incoming requests have a hostname iany.me or www.iany.me, redirect to concat("https://blog.iany.me", http.request.uri.path).
Redirect https://blog.iany.me/*/index.html to https://blog.iany.me/${1}/.
Redirect http://* to https://${1}

Although the Redirect Rules manual says if multiple rules make the same modification, the last executed rule wins, I have to put rule 2 before 3.

URL Rewrite Rules

I added 2 rewrite rules for index.html:

When the request URL is https://blog.iany.me or https://blog.iany.me/, rewrite the URL path to /index.html.
When the request URL matches https://blog.iany.me/*/, rewrite the path to ${1}/index.html

Cache Rules

I added 2 cache rules for images and static content:

Set cache TTL to 1 month for png, jpg, jpeg, and svg files.
Set cache TTL to 1 year for files in /js, /fonts, /css, and /uploads.

Write to Any iOS Files Location via Working Copy

me@iany.me (Ian Yang) — Fri, 24 Apr 2020 21:14:17 +0800

I use file system to manage my knowledge base. The repository has a well defined directory structure. I have a bunch of scripts to help me creating these directories on the laptop. But in iOS, I have to create them manually. Recently, I have found out a way to work around it via Working Copy.

The trick uses two features of Working Copy:

2-way synchronized repository with any iOS Files location.
The shortcut Write Repository File.

The shortcut allows writing file into any path in a repository, and the synchronized repository synchronizes changes back to the target iOS Files location.

Write to Files via Working Copy

In the following I’ll show how to create a shortcut which saves files into an iCloud folder and sorts them into sub-directories by date.

First create the target directory and set up the synchronized repository. I use Desktop/Inbox.

Set Up Sync Repo in Working Copy

Then create the shortcut. It accepts the file from Share Sheet and saves it into the synchronized repository sorted by date. It is important to check the option “Create” in the Write Repository File step.

Shortcut: Save Files by Date

Now give it a try. Share a text file using the new created action.

Test Shortcut

And the file appears in the Desktop/Inbox.

File Sorted into Inbox

This solution is not perfect and has two major drawbacks:

It duplicates the files.
It requires opening Working Copy to synchronize files.

However, it also has a bonus. I can backup the directory by git now.

Save Web Articles via Inoreader

me@iany.me (Ian Yang) — Sat, 14 Mar 2020 17:02:25 +0800

One of my favorite features of Inoreader is saving the article to external services, such as Evernote, OneDrive or Google Drive. I can archive the articles I liked for future references.

Inoreader even supports automatically fetching full text for truncated RSS feed. This is awesome to work with other web services. Many bookmarking and reading later services, such as Diigo, Instapaper and Pinboard, all provide RSS feed but without full text.

Automatically Fetch Full Content

The Inoreader Pro subscribers can save the articles automatically by creating rules. For example, I have saved all of my bookmarks into Evernote.

Automatically Save Articles

Saved Articles

Vim iTerm Launcher

me@iany.me (Ian Yang) — Sat, 08 Feb 2020 16:48:30 +0800

I prefer using Vim in a terminal. I can switch to the shell with Ctrl-Z and back with fg. However it is hard to integrate a terminal command with other GUI tools, such as editing a file in Vim from Finder.

In macOS, the default Terminal app and iTerm both supports automation. It’s easy to write a script to open a new terminal window and run a command like “vim file” in it. But I want to close the window after Vim quits. A quick work around is running the following command:

vim file; exit 0

Now the problem is that if I suspend Vim via Ctrl-Z, the terminal window is closed, because shell will continue to execute the next command when the process is suspended.

After research and reading a StackOverflow answer, I wrote two scripts to launch Vim in iTerm. I also added features in iterm-vim-wrapper to edit clipboard and empty scratch file in temporary directory.

This is an example which uses the scripts to create File Action in Alfred.

How to Download Only Gmail Inbox

me@iany.me (Ian Yang) — Sun, 02 Feb 2020 12:15:10 +0800

I prefer reading my mails in the Gmail web client directly. I rarely send new mails or replies. But when I do, I want to use PGP to encrypt or sign the mail. I have tried two extensions to use PGP in Gmail, FlowCrypt and Mailvelope. But both of them are far from a competent solution for me. GPG Mail in the GPG Suite for macOS is still my preferred way. However, GPG Mail is an Apple Mail plugin, which requires downloading mails first. Based on my scenarios, I only need to download the mails I left in the inbox. But the basic setup of Gmail in Apple Mail will download many mails in the background.

I tried POP3. It has two issues:

The status is not synchronized with the server. I can configure Gmail to archive the mails which have been downloaded via POP3, but that means once I have downloaded mails, I must process them locally. This is a burden, since I only want to reply several mails in the client.
POP3 does not observe the filter which auto archives new mails. The filtered emails still occur in the client.

IMAP is still the better choice. The real issue is indeed that Apple Mail uses remote IMAP mail boxes for Drafts, Sent, Junk, Trash and Archive by default. If it uses local mail boxes instead, the client will no longer try to synchronize this mail boxes.

Following is the detailed instructions to setup a Gmail IMAP client which only downloads mails in the inbox.

First go to the Gmail label settings. Disable all the “Show in IMAP” options except the one for inbox.

Since Apple Mail does not allow configuring mailboxes for a Google account, I have to generate an app password to add the Gmail as an IMAP account. Open Mail app, add account and choose IMAP from “Other mail account…”.

After adding the new account, use local mail boxes in the Mailbox Behaviors settings pane. Leave the Archive mail box remote, since we cannot change it.

Apple Mail Mailboxes Behaviors Settings Pane

Now Apple Mail will only download mails in the inbox. There is one last thing, if I archive a mail in the client, it will be labeled [Imap]/Archive in Gmail, you may want to hide it from the label list and message like me in the labels settings.

Capture Anything using macOS Javascript automation

me@iany.me (Ian Yang) — Sun, 19 Mar 2017 17:54:08 +0800

I have written many scripts to automate the work in macOS. This one is the most frequently used one. The script can capture the current selection in frontend most app in OmniFocus, and I can jump back to the app using URL.

It only supports apps I frequently use. New app support can be added in capturers map.

var tasks = [];
var app = null;
// Uncomment following line to debug a specific app.
// var app = Application("Evernote");
(function(app, tasks) {
var bundleIdentifier;
if (app === null || app === undefined) {
var systemEvents = Application("System Events");
var bundleIdentifier = systemEvents.processes.whose({ frontmost: true })[0].bundleIdentifier();
app = Application(bundleIdentifier);
} else {
bundleIdentifier = app.id();
}
if (tasks === null || tasks === undefined) {
tasks = [];
}
var capturers = {
Safari: function(app, tasks) {
var tab = app.windows[0].currentTab();
tasks.push({ name: tab.name(), note: tab.url() });
},
Chromium: function(app, tasks) {
var tab = app.windows[0].activeTab();
tasks.push({ name: tab.title(), note: tab.url() });
},
Finder: function(app, tasks) {
app.selection().forEach(function(file) {
var name = file.name();
var url = file.url();
var directory = file.container().url();
tasks.push({ name: "[File] " + name, note: url + " in directory " + directory });
});
},
Contacts: function(app, tasks) {
app.selection().forEach(function(contact) {
tasks.push({ name: "Contact " + contact.name(), note: "addressbook://" + contact.id() });
});
},
Evernote: function(app, tasks) {
app.selection().forEach(function(note) {
var url = note.noteLink();
var title = note.title();
tasks.push({ name: "[Evernote] " + title, note: url });
});
},
Mail: function(app, tasks) {
app.selection().forEach(function(mail) {
var url = encodeURI("message://<" + mail.messageId() + ">");
var title = mail.sender() + ": " + mail.subject();
tasks.push({ name: title, note: url });
});
}
};
capturers["Google Chrome"] = capturers.Chromium;
var fluidCapturer = function(app, tasks) {
var tab = app.browserWindows[0].selectedTab();
var name = "[" + app.name() + "] " + tab.title();
tasks.push({ name: name, note: tab.url() });
};
var defaultCapturer = function(app, tasks) {
app.includeStandardAdditions = true;
var url = encodeURI("file://" + app.pathTo().toString());
tasks.push({ name: app.name(), note: url })
};
var capture = capturers[app.name()];
if (capture === undefined) {
if (bundleIdentifier.startsWith("com.fluidapp.FluidApp.")) {
capture = fluidCapturer;
} else {
capture = defaultCapturer;
}
}
capture(app, tasks);
return tasks;
})(app, tasks);
// Then send tasks to OmniFocus or other app which supports Applescript automation.
var of = Application("OmniFocus");
var inbox = of.quickEntry().inboxTasks;
tasks.forEach(function(task) {
inbox.push(of.Task(task));
});
of.quickEntry().open();

I use Keyboard Maestro to invoke the script using keyboard shortcut.

Convert Web Page to Markdown using Ulysses or Bear

me@iany.me (Ian Yang) — Sun, 27 Nov 2016 00:00:00 +0000

Updates

2017-05-09: The bear current version made clipper easier to use.

Ulysses way:

Select content in browser and copy.
Open Ulysses and use menu Edit > Paste from > Rich text to paste
Select pasted text and use menu Edit > Copy as > Markdown to copy

Bear way:

Copy page URL.
Use /grab-url x-callback-url
After the article is grabbed, use menu Edit > Markdown to copy

Auto Toggle MacBook Internal Keyboard

me@iany.me (Ian Yang) — Fri, 17 Jan 2014 00:00:00 +0000

I prefer using external keyboard with my MacBook. When no external monitors are used, a typical setup is placing the keyboard above the internal one, so I can still use the internal touchpad.

But sometimes the external keyboard may press some keys of the internal keyboard. There is a solution to disable the internal keyboard, but it is tedious to run the command manually.

# Disable, ignore the warning
sudo kextunload /System/Library/Extensions/AppleUSBTopCase.kext/Contents/PlugIns/AppleUSBTCKeyboard.kext/
# Enable
sudo kextload /System/Library/Extensions/AppleUSBTopCase.kext/Contents/PlugIns/AppleUSBTCKeyboard.kext/

Fortunately, Keyboard Maestro supports executing scripts when a USB device is attached or detached.

I have created two macros to enable and disable internal keyboard.

Before the macros can be used, you must setup sudoers to allow running the command without password.

$ sudo visudo

And append following line to the file and save it.

%admin ALL = NOPASSWD: /sbin/kextunload /System/Library/Extensions/AppleUSBTopCase.kext/Contents/PlugIns/AppleUSBTCKeyboard.kext, /sbin/kextload /System/Library/Extensions/AppleUSBTopCase.kext/Contents/PlugIns/AppleUSBTCKeyboard.kext

Then restart sudo session

$ sudo -K