Forem: Ivan Starkov

Using Opencode as a Copy-Paste Backend for UI Prototyping

Ivan Starkov — Sun, 23 Nov 2025 10:47:55 +0000

Sometimes I use OpenCode (and tools like Claude Code, Codex CLI, etc.) as a copy-paste backend: I prepare context in the browser, then paste it into an AI coding tool.

At its core, most modern AI coding workflows boil down to two operations:

Selecting the relevant context.
Chatting about that selection.

In my setup, a tiny browser script handles the selection: it collects and shapes the context, writes a structured payload to the clipboard, and then I paste it into OpenCode, Claude Code, Codex CLI, or any other AI coding tool just to see how it behaves - without building a real AI backend.

How the selection script works

When you hit Escape in the browser, the selection script grabs:

your prompt (e.g. “Change color to red”)
the current selection (code / text)
some structure around it

and writes a structured payload to the clipboard, like:

<edit>
  prompt: Change color to red
  where:<selection>{context}</selection>
</edit>
...
{ADDITIONAL_PROMPT}

You can try this in the browser here: https://istarkov.github.io/ai-cli-edit/ — press Cmd + E or Ctrl + E to enter editing mode and see the generated payload.

Making it work across different models

Slow, higher-end reasoning models can usually consume this raw structure without extra help.

Smaller or faster models often need the {ADDITIONAL_PROMPT} with more explicit instructions — for example:

how to interpret <selection>…</selection>
what to edit and what to keep identical
formatting rules
which tools to call

Keep editing instructions isolated

You could dump all of this into CLAUDE.md or AGENTS.md, but those files are usually already full of generic rules and global guidelines.

Better approach: keep editing-specific instructions in a separate, dedicated place.

In OpenCode, this is done via Primary Agents. Create a focused file like ./.opencode/agent/edit.md that defines:

your editing rules
model parameters
tools
project-specific context (jargon, naming, edge cases, etc.)

In the Claude ecosystem, the same idea appears as Skills: small, targeted capabilities that encapsulate exactly this kind of task-specific behavior.

Link to repo

Local Development with Public and Private monorepos

Ivan Starkov — Tue, 20 Jun 2023 21:41:32 +0000

In the project I'm working on now webstudio.is, we have 2 mono repositories.

One open and fully public and one closed source.

Projects from the closed repository use libraries from the open one.

So usually working on a closed repository looks like this

we publish libraries from public repository into npm
we update libraries in a closed repository pnpm up -r -L '@webstudio-is/*'

Local development becomes terribly messy with this approach.
Each iteration takes an awful lot of time (15 minutes to 30 minutes on average).
Create PR wait for all checks to be done, wait for all checks to be done and publish.

To avoid all this I tried.

Link protocol

in package.json of the closed packages I replaced all

"dependency": {
  "@webstudio-is/form-handlers": "^0.75.0",
  ...
}

"dependency": {
  "@webstudio-is/form-handlers": "link:/Users/User/webstudio-is/webstudio-builder/packages/form-handlers",
  ...
}

This worked for some of the packages in the closed repository. But some packages got runtime errors like TypeError: Cannot read properties of null (reading 'useContext').
It seemed like some dependencies were duplicated and I didn't manage to get rid of this error.

Soft link packages from one monorepo into another

I plugged the open repository as a workspace into a closed repo. ln -s /Users/ice/webstudio-is/webstudio-designer/packages packages and added into workspaces. The result is the same as with 1.

I guess it's possible to fix it but I failed.

Verdaccio

Valentin Semirulnik gave me an idea to use verdaccio
The idea to use private proxy registry for local development

And it worked.

Briefly how I use it.
Everytime I need to check how an open library will work with a closed one, I do.

# Run verdaccio locally
verdaccio
# build all libs
pnpm run build
# change version of all public libraries from current to exprimental like "0.75.0" => "0.75.1-qawqisps.0" etc
pnpm -r exec pnpm version prepatch --preid $(cat /dev/urandom | LC_ALL=C tr -dc 'a-z' | fold -w 8 | head -n 1)
# Publish all to verdaccio registry
pnpm -r publish --access public --no-git-checks --registry http://localhost:4873
# Reset version changes I made to package.json (DANGEROUS! as can remove changes you made)
git restore --source=$(git branch --show-current) '**/*/package.json

And now in a closed project I can just run

pnpm up -r -L '@webstudio-is/*' --registry http://localhost:4873

Now it takes me 1-2 minutes to check something. This is still a lot but I have not found a better solution.

JS defer or how to free resources at the end of code block (fun way).

Ivan Starkov — Thu, 27 Oct 2022 20:40:26 +0000

Interesting feature of the Go language is to delay the execution of a function until the current function returns - defer keyword.

It allows to declare resource cleanup near the place it created i.e.

file, err := os.Create(fileName)
if err != nil {
  return err
}
defer file.Close()
...
file.Close will be called at the end of function
...

The similar feature in js is finally keyword. The issue with finally that you open resource in one place but need to close it far far away from opening position.

easy to make mistake
in case of dependent resources easy to break order etc.

In js we can have similar behavior like defer using generators, see example:

async function* createResource<T>(open: () => T, close: (a: T) => void) {
  let r: T | null = null;
  try {
    r = open();
    yield r;
  } finally {
    if (r != null) {
      close(r);
    }
  }
}

const open = () => {
  console.log('open');
  return 'somehandle';
};

const close = (handle: string) => {
  console.log(handle, 'closed');
};

for await (let x of createResource(open, close)) {
  console.log(1);
  await new Promise(x => setTimeout(x, 1000));
  console.log(2);
  // throw new Error();
}

Output will be: 'open', 1, 2, 'somehandle closed'

Now our resource lifecycle is bounded to "for" block. We declared open, close in same place and it's somehow looks like defer.

PS: createResource should rethrow Error so its just small simple version to show the idea.

PPS: All above is just for fun to show generators power.

Simple and fast way to run various devops workflows on your servers

Ivan Starkov — Sun, 23 Oct 2022 15:29:08 +0000

We periodically need to run different workflows on different servers. For example stop replication, do a vacuum or global database update, start replication.
I don't want to give everyone ssh access to the servers. In addition some workflows need to be run by non-developers.
So to solve this problem I need some simple UI to run workflows, the ability to see logs and the ability to easily and quickly create complex workflows.
Recently I found what I think is the perfect and simple solution. This is github actions + self-hosted runners

I roll out github action runner on each of my servers in addition to the usual set of software. (The code to install via terraform, namely the key generation is taken from here https://github.com/myoung34/docker-github-actions-runner)

Next I write the workflow:

name: Tasks

on:
  workflow_dispatch:
    inputs:
      DEPLOYMENT:
        type: choice
        description: 'Database is production or test'
        options:
        - production
        - test
        default: test
        required: true

      task:
        type: choice
        description: 'Select task'
        options:
        - stop-replication
        - start-replication
        - ps
        - restart
        default: ps
        required: true

      country:
        type: choice
        description: 'Select country'
        options:
        - ch
        - fr
        required: true

jobs:
  main:
    runs-on: [self-hosted, clickhouse-runner, linux, "${{ github.event.inputs.DEPLOYMENT }}"]
    steps:
      - if: ${{ github.event.inputs.task == 'restart' }}
        run: docker compose restart

      - if: ${{ github.event.inputs.task == 'ps' }}
        run: docker compose ps

      - if: ${{ github.event.inputs.task == 'stop-replication' }}
        run: |
          docker compose stop clickhouse-replication-updater clickhouse-init
          docker compose exec -iT clickhouse clickhouse-client --query="DROP DATABASE IF EXISTS some_db"
          echo Stopped

      - if: ${{ github.event.inputs.task == 'start-replication' }}
        run: |
          docker compose start clickhouse-replication-updater clickhouse-init

Here workflow_dispatch.inputs gives nice UI at github

And you can use steps/jobs etc to generate any workflow depending on inputs.

With runs-on: [self-hosted, clickhouse-runner, linux, "${{ github.event.inputs.DEPLOYMENT }}"] section you are able to select any server where you need to execute workflow.

Since now everyone with access to repositary can execute server workflows with beautiful UI, logs etc.

Use docker image tagging to speedup the builds.

Ivan Starkov — Mon, 22 Nov 2021 12:19:15 +0000

From the beginning, we did a review deployment of each commit of each pull requst.
Initially it was two builds/deploys and accordingly you could not think about caching.
Over 4 years this has grown to 15+ builds/deploys and only the build time has become 20+ minutes.

After some reading we came across docker buildx and decided to use the features it provides,
namely cache-from and cache-to

Idea was to create some checksum for every subproject, then use that checksum for cache-from, cache-to source/destination.
Like it's described here

In our case it worked but did not give a very significant advantage. Given the number of different builds, we got that the time to download all the cache was comparable to the build time.

Also having that we use yarn based monorepo to reuse docker layering we created internal prune util which is not that simple and adds additional steps to the build. (about prune you can read at amazing turborepo)

Our builds are very simple, +-fast and consist of one step, there are a lot of them and so we did not get the significant advantage we expected.

We decided not to use the cache, but to take advantage of the fact that a developer only works on one or two projects in one pull request. So we don't need to rebuild everything, but only the projects that have changed.

And thanks to docker it allowed to do everything we need.

Single docker image can have mutiple tags.
We can add tag to docker image without pulling it and gcloud even have ready command for this gcloud container images add-tag
We already had workspace checksum util from our previous work iteration with cache layers.

Now in pseudocode our build process for each subproject on every commit (yarn workspace) looks like.

CHECKSUM=$(generate-workspace-checksum ${WORSPACE_NAME})
if gcloud container images describe ${IMAGE_NAME}:${CHECKSUM}; then
  gcloud container images add-tag --quiet ${IMAGE_NAME}:${CHECKSUM} ${IMAGE_NAME}:${SHORT_SHA}
else
  docker buildx build . \
    --file=universal.Dockerfile \
    --tag=${IMAGE_NAME}:${SHORT_SHA} \
    --tag=${IMAGE_NAME}:${CHECKSUM} \
    --progress=plain ${BUILD_ARGS} \
    --push
fi

We generate workspace checksum, check if image with tag equal to checksum exists, and if yes we add commit sha tag to existing image. This is really fast operation.
In case if image is not exits we just rebuild workspace and tag image with 2 tags - checksum and commit sha.

Deploys were already fast and executed in parallel so doing 2 or 15 deploys in our case doesnt matter a lot.

Trick above allowed us to significantly reduce build times, sometimes to seconds (like documentation has changed) instead of 20+ minutes for every commit.

For projects with mutibuild steps, various dependency installs etc above solution could not work, and caching would be the best solution. For us just image retagging works the best, removes the need of some external KV storage (sha => checksum), significantly removed build times and simplified builds.

Fast and easy way to setup web developer certificates

Ivan Starkov — Sat, 13 Nov 2021 21:00:22 +0000

Modern days having that cookies auth etc depends on https we need to have https local web environment.

Before to generate local certificates I used minica.

The main issue that you need a big readme for osx, linux and windows users, how to regenerate keys,
how to add minica certificate to Keychain, how to change hosts file.

Having that we use vscode remote for development it was 2x more work to register all that keys on local and remote machines.

The solution below doesnt need any setup from developers.

Solution in short

A blabla.devdomain.com 127.0.0.1

Then using letsencrypt certbot for your provider just generate needed certificates.

They are already trusted and the only issue is 3 month expiration period, what can be easily fixed with cron.

Full solution.

In our case we use cloudflare as DNS.
Generation certificates for few domains on cloudflare looks:

Create cloudflare API token https://support.cloudflare.com/hc/en-us/articles/200167836-Managing-API-Tokens-and-Keys#12345680

TF_VAR_CLOUDFLARE_API_KEY={YOURAPITOKEN}

mkdir -p /tmp/certbot/
mkdir -p /tmp/letsencrypt/

cat > /tmp/certbot/cloudflare.ini <<-DOCKERFILE
  dns_cloudflare_api_token = ${TF_VAR_CLOUDFLARE_API_KEY}
DOCKERFILE

docker run -it --rm --name certbot  \
-v "/tmp/letsencrypt/data:/etc/letsencrypt" \
-v "/tmp/certbot:/local/certbot" \
certbot/dns-cloudflare:v1.15.0 certonly \
-m istarkov@gmail.com \
--dns-cloudflare \
--dns-cloudflare-credentials /local/certbot/cloudflare.ini \
--agree-tos \
--noninteractive \
-d subdomain.mydomain.com \
-d other.mydomain.com \
-d blabla.hello.com

# subdomain.mydomain.com, other.mydomain.com, blabla.hello.com must have A records on cloudflare pointing to 127.0.0.1

cp /tmp/letsencrypt/data/live/subdomain.mydomain.com/* ./
cat ./fullchain.pem ./privkey.pem > ./haproxy.pem

thats all, now for nodejs apps use following https options

key: fs.readFileSync('./privkey.pem'),
cert: fs.readFileSync('./fullchain.pem'),

for haproxy use haproxy.pem like in simple config below

# haproxy -f ./playground/haproxy-http-2.cfg -db

frontend rgw-https
  bind *:3009 ssl crt /root/realadvisor/https-dev-keys/haproxy.pem alpn h2,http/1.1
  default_backend rgw


backend rgw
  balance roundrobin
  mode http
  server  rgw1 127.0.0.1:3000 check

This is fast and simple way I prefer now to have development certificates, which doesnt need any additional documentation for developers.

Google cloud build webhooks on specific commit SHA.

Ivan Starkov — Tue, 02 Nov 2021 23:03:06 +0000

The gcloud build has webhook triggers that allow you to trigger the build using a simple http api.
How to create such a trigger can be found here

The disadvantage for me was that the web trigger cannot be applied to a specific commit, but only to a branch such as master,
moreover the branch name is fixed.

Today I found an interesting way to trigger a build using a webhook trigger for any commit.

Briefly, I create a normal push branch trigger using a branch name that can't exist. Then I create a webhook trigger which
using the command gcloud alpha builds triggers run --sha={COMMIT_SHA} to run the first trigger with the commitSha of specific commit.

Now the pictures.

This is push branch trigger.

This is the webhook trigger.

with following substitutions

and following inline source

steps:
  - name: 'google/cloud-sdk'
    args:
      - '-c'
      - |
        set -eou pipefail
        shopt -s inherit_errexit

        if [[ "${COMMIT_SHA}" ]]; then
          echo "HERE ${COMMIT_SHA}"
          gcloud alpha builds triggers run ${_TRIGGER_NAME} --sha ${COMMIT_SHA}
        else
          echo "MASTER"
          gcloud alpha builds triggers run ${_TRIGGER_NAME} --branch=master
        fi
    id: aggregator-custom-build
    waitFor:
      - '-'
    entrypoint: bash
tags:
  - webhook-trigger

Finally

To invoke webhook trigger you need just.

    curl -X POST -H "application/json" \
    "https://cloudbuild.googleapis.com/v1/projects/${PROJECT}/triggers/webhook-invoke-trigger:webhook?key=${API_KEY}" \
    -d '{"COMMIT_SHA": "${COMMIT_SHA}", "TRIGGER_NAME": "webhook-invoke-agg-custom-update"}'

That allows me to run specific build steps like periodic data updates using "sha fixed" scripts.