Claude on Margrop Blog

Superpowers 6: What Actually Changed, and Why Your Agent Got Harder to Fool

Mon, 13 Jul 2026 15:30:00 +0800

The short answer

If you already write code with Claude Code, OpenCode, or Codex, you have probably heard of Superpowers. It is not another “magic prompt.” It is a skill framework that makes your agent work by process — turning the habits of a good engineer (“think before you act”, “write the test before the code”, “collect evidence before fixing the bug”) into operating procedures the agent must follow.

From v6.0.0 to the latest v6.1.1, Superpowers shipped a dense run of upgrades: Subagent-Driven Development (SDD) lost half its reviewers but got stricter; plans gained a Global Constraints block and per-task Interfaces; the brainstorming companion got a one-time key; Codex can install from the marketplace; and Gemini CLI was dropped after Google EOLed it.

This article unpacks the wave, what you actually get, and why it makes your agent’s output steadier.

One sentence let Claude upgrade Ubuntu 22.04 to 24.04: a near-zero-screen-time cross-LTS run

Fri, 19 Jun 2026 10:58:00 +0800

TL;DR

A remote home-lab box had been sitting on Ubuntu 22.04.4 LTS (jammy, kernel 5.15) for a long time. After one sentence — “upgrade the box at 192.168.103.182 to Ubuntu 24.04” — Claude opened a tmux session to babysit the run, brought up a fallback sshd on port 1022 so a mid-upgrade sshd restart would not strand me, then drove do-release-upgrade -f DistUpgradeViewNonInteractive end to end. Twenty-five minutes later the host came back: kernel 6.8.0-124, every service still listening.

This is not a tutorial on do-release-upgrade; the Ubuntu docs already cover that. This is about what an Agent does once it gets an SSH handle on a box, why it does each step, and which pitfalls you have to clear out of the way before letting it loose.

Stop Letting Agents Guess UI: Installing and Using UI UX Pro Max the Right Way

Fri, 22 May 2026 22:50:00 +0800

The short version

UI UX Pro Max is not a magic prompt that suddenly gives an agent taste. It is a searchable UI/UX design intelligence Skill for AI coding assistants such as Claude Code, Codex, Cursor, Windsurf, Gemini, OpenCode, and similar tools. It packages product patterns, UI styles, color palettes, typography pairings, landing page structures, chart recommendations, UX guidelines, and stack-specific implementation advice into files and scripts that an agent can actually query.

The right way to use it is not to install it and keep asking for “a beautiful page.” The right way is to make the agent generate a design system first, then query UX, chart, web, or stack-specific guidance, and only then implement the page. That workflow reduces generic AI gradients, weak contrast, crowded mobile layouts, decorative dashboards, missing focus states, and many other common agent-generated UI problems.

This article uses only public references, a public repository, and a clean temporary verification directory. Commands, paths, project names, and examples are generic. No private addresses, credentials, internal project names, account names, or personal configuration are included. Screenshots are taken from public reference pages and sanitized verification work.

Upgrading PVE 8 to 9 Without Brute Force: Let an Agent Drive It, or Follow This Manual Checklist

Tue, 12 May 2026 19:00:00 +0800

Short version

Upgrading Proxmox VE 8 to 9 is not just copying a few commands. It is a major system upgrade from Debian Bookworm to Trixie, from PVE 8.4 to PVE 9.x, with kernel, storage, networking, Ceph, and HA behavior in the blast radius. The fastest practical path is to let Codex, Claude, OpenClaw, HermesAgent, or a similar Agent handle checks, command sequencing, logging, and post-upgrade verification. The human operator still needs to approve repository changes, package removals, configuration prompts, reboot timing, and recovery decisions. If you prefer doing everything by hand, the second half of this article gives a concrete manual checklist.

This article is for two groups of operators. The first group already uses Agents over SSH and wants a scoped one-sentence task for upgrading PVE. The second group prefers typing every command manually and wants a clear, ordered procedure with the main risk points called out.

All hostnames, addresses, repositories, tokens, and accounts in this article are placeholders. Replace values such as <PVE_NODE>, <BACKUP_TARGET>, and <ADMIN_CONSOLE> with your own environment. Before touching a production host, read the official Proxmox documentation and verify that your backups are restorable.

Ubuntu 26.04 Upgrade Guide: Let an Agent Do It, or Run It by Hand

Tue, 12 May 2026 07:30:00 +0800

The short version

Upgrading Ubuntu 22.04 or 24.04 to Ubuntu 26.04 is not about memorizing one command. It is about following the supported upgrade path. Ubuntu 22.04 LTS should not be jumped directly to Ubuntu 26.04 LTS. Upgrade 22.04 LTS to 24.04 LTS first, then move from 24.04 LTS to 26.04 LTS. As of 2026-05-12, Ubuntu 26.04 LTS has already been released, but the normal LTS-to-LTS upgrade prompt from 24.04 LTS to 26.04 LTS is typically enabled after the first point release. The official 26.04 schedule lists the 26.04.1 point release on 2026-07-09. Production systems should usually wait for the regular upgrade path; test systems can evaluate an early upgrade only with explicit risk acceptance.

If you already use agents such as Code, Claude, OpenClaw, HermesAgent, Codex, or OpenCode, this is a good task to delegate. But do not just say “upgrade Ubuntu.” Give the agent a bounded job: inspect first, back up, follow the supported path, keep logs, ask before risky choices, reboot, verify services, and report evidence. This article gives both a ready-to-copy agent prompt and a manual procedure.

All examples in this article are generic. No private hostnames, internal addresses, accounts, credentials, tokens, business system names, or personal paths are included. Replace placeholders such as <HOST>, <SERVICE>, and <BACKUP_DIR> with values from your own environment.

Small Models Make Agents Drift. Superpowers Gives Them Rails.

Thu, 07 May 2026 16:43:10 +0800

The short version

When an agent powered by a smaller or weaker model behaves unpredictably, the problem is not always solved by writing a longer prompt. Smaller models often struggle with long-horizon consistency, tool discipline, evidence tracking, and multi-step execution. Superpowers does not turn a weak model into a frontier model. What it does is more practical: it gives the agent an external engineering workflow made of reusable Skills, checkpoints, testing habits, debugging rules, review steps, and completion verification.

For agents such as OpenClaw, HermesAgent, Codex, Claude, Gemini, OpenCode, Droid, Cursor, and similar tools, Superpowers is best understood as an engineering-discipline layer. It makes the agent less dependent on improvisation and more likely to follow a repeatable process.

This article is about a very common failure mode in modern agent workflows: the model can talk fluently, but the agent does not behave reliably once the task becomes long, stateful, tool-heavy, or distributed across multiple agents.

The issue becomes more visible when using smaller domestic models, local models, quantized models, or cost-optimized models. They may answer normal questions well enough, but once they need to read a repository, follow a constraint, modify files, run tests, interpret logs, preserve privacy, and report only verified results, the instability becomes obvious.

All examples in this article are generic. No private hostnames, internal addresses, credentials, project names, or personal paths are included.

How to Prompt OpenClaw, HermesAgent, Codex, Claude, Gemini, OpenCode, and Droid to Write Articles and Publish WeChat Drafts

Tue, 05 May 2026 16:00:00 +0800

Short version

If you want an agent such as OpenClaw, HermesAgent, Codex, Claude, Gemini, OpenCode, or Droid to write an article, prepare a Hugo blog post, convert the Chinese version into WeChat-compatible HTML, preview it, fix layout issues, and create a WeChat Official Account draft, the prompt cannot simply say “write and publish an article.” A useful prompt must define the goal, source material, paths, account constraints, fixed-IP requirements, conversion steps, preview checks, failure recovery, privacy boundaries, and final verification evidence.

This post describes a reusable prompting pattern for article automation. It explains how to prepare the WeChat draft API, why a Linux machine with a fixed public IP is often required, how to tell an agent to try local API access first and then fall back to a fixed-egress host, how to use a Markdown-to-WeChat-HTML converter, and how to make the agent check for invisible white text, strange indentation, broken images, and accidental leaks before declaring the job done.

All examples are privacy-safe. They use placeholders rather than real secrets, private IP addresses, hostnames, repository URLs, tokens, cookies, or personal paths. Replace placeholders with your own values only in a protected runtime environment, never in a public article, public repository, or screenshot.

Using WoClaw to Solve Shared Memory for Multi-Agent Workflows: OpenClaw, Codex, Claude, and Gemini on the Same Table

Sun, 05 Apr 2026 20:10:00 +0800

What matters most in a multi-agent system is often not “which model is smarter”, but “which agent still remembers what happened five minutes ago”.

When I put OpenClaw, OpenAI Codex, Claude, and Gemini into the same workflow, the most painful problem was not raw answer quality. It was context fragmentation:

OpenClaw remembered scheduling decisions, Codex remembered implementation details, Claude remembered review conclusions, and Gemini remembered external references, but none of them knew what the others knew.
Each tool had its own session lifecycle, so yesterday’s discussion was often gone by tomorrow.
As soon as a project entered a multi-round, multi-tool stage, repeating the same background became more expensive than solving the problem itself.
Without a shared memory layer, the final result was not collaboration, but several partial answers that looked similar and still failed to line up.

This post is about how I used WoClaw to place all of those tools on the same shared memory layer, so they could stop talking past each other and start working from the same state.

To avoid leaking private information, all examples below are abstracted. They do not include real hostnames, account names, addresses, tokens, or internal project codes.

Adding Proxy Support to Antigravity and Claude on macOS: Safely Wrapping Electron Apps Without Patching Them

Wed, 25 Mar 2026 10:00:00 +0800

Before You Start This post documents a pattern that has already been validated in a real macOS environment: do not patch the original application bundle, and do not publish your real proxy endpoint. Instead, place a tiny wrapper app in front of the original Electron application. That wrapper becomes the stable place where proxy settings, launch flags, and Node-side bootstrap logic live.

When people first hit this problem, the instinct is usually to edit /Applications/Claude.app or /Applications/Antigravity.app directly. That can work once, but it is a poor long-term operational choice for three reasons:

You may break code signing behavior and make future launches or permission prompts more fragile.
Auto-updates can overwrite your local modifications at any time.
If you hardcode a real proxy endpoint into the app bundle, screenshots, scripts, or a public post, you can leak private infrastructure details that never needed to be exposed.

The approach that proved much more stable was:

Leave the original Claude.app and Antigravity.app untouched.
Create Claude (Proxy).app and Antigravity (Proxy).app under ~/Applications.
Let each wrapper app do only three things: load a private proxy.env, export upper/lower-case proxy variables, and launch the original Electron binary with --proxy-server.
If the target app also uses Node/undici fetch, inject a very small NODE_OPTIONS=--require=... bootstrap so Node-side requests follow the same proxy path.

All proxy endpoints in this article are intentionally redacted and replaced with placeholders such as:

http://127.0.0.1:PORT

Replace that value with your own local proxy entrypoint. Do not publish real proxy hosts, internal IP addresses, usernames, passwords, tokens, or internal domains in a public article, repository, or screenshot.